Aurora のスナップショット（デフォルトKMSキーで暗号化されてる）を別アカウントに共有する 1 - Qiita
弊社では会社全体で１つのアカウントを共有していましたが「管理が面倒！どの部署がどれを使っているのかさっぱり分からん！」という苦情が増えてきたため、部署ごとにアカウントを分ける事になり Aurora 移行の作業を振られたため手順をまとめました。 AWS マニュアルを確認 マニュアル見てると手動スナップショットを共有するだけっぽいので簡単だな！と思っていましたが当然そんなに上手く行かず…デフォルトKMSキーで暗号化されていたため、別アカウントへの共有が不可になっていました。あと KMS キーも別途発行して別アカウントに共有しておく必要があるっぽい。 デフォルトの Amazon RDS 暗号化キーを使用しない、暗号化された手動スナップショットは共有できます。ただし、まず AWS Key Management Service (AWS KMS) キーを、スナップショットを共有するアカウントと共有す
Aurora（MySQL互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使う - Qiita
Aurora（MySQL互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使うMySQLAWSAurora 今更ながら、Aurora（MySQL 5.6 互換）上のデータをutf8からutf8mb4に変換することになったので、タイトルの通りSELECT INTO OUTFILE S3とLOAD DATA FROM S3を使ってテストしてみました。 この方法を選んだ理由 端的に言えば「他に思いついた方法に問題点があったから」です。 ALTER TABLEで文字コードを変える→長時間更新ロックが掛かる（db.r4.2xlarge で 300GiB 未満でも 10 時間！）・不意に失敗することがある（実際にエラーが出た） pt-online-schema-change を使う→ロック競合で詰まるのが怖い・トリガで拾えない更新が
AWS Backupを使い始める前に覚えておきたいこと - Qiita
AWS Backup is 何 AWS上のバックアップを一元的に管理できるAWS Backupが利用可能になりました。 AWS Backup – Automate and Centrally Manage Your Backups https://aws.amazon.com/jp/blogs/aws/aws-backup-automate-and-centrally-manage-your-backups/ ※以降は2019/1/17 時点の情報です。 2019/6/27 に東京リージョンで利用可能になったため情報を更新しました 2020/1/14 時点の情報に更新しました 2020/6/11 Aurora に対応したため追記しました バックアップ取得可能なリソース 2020/11/11時点 EFSファイルシステム DynamoDBテーブル EC2インスタンス(EBS-backedのみ)
Aurora小ネタ／MySQLレプリケーションでのしくじりポイント - Qiita
先に、オンプレMySQL～RDS for MySQL／Aurora間のレプリケーションにおけるタイムゾーン設定という記事を書きましたが、それ以外にもAuroraでのMySQLレプリケーションでいくつか問題に遭遇しましたので、書き残しておきます。 しくじり1. そもそもレプリケーションが開始できない Auroraがマスターになるケースで、 バイナリログの出力をON（MIXEDまたはROW）にした バイナリログの保存期間も設定した（mysql.rds_set_configurationプロシージャで） スレーブに対してREPLICATION SLAVE・REPLICATION CLIENT権限を付与した スレーブ側でCHANGE MASTER TOコマンドはエラーにならずに通った にもかかわらず、スレーブ側でSTART SLAVE後にレプリケーションが開始されない場合、セキュリティグループやN
AuroraとRDS MySQL 5.7のsysbench - Qiita
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【AWS】それぞれのDBの特徴を簡単にまとめました(備忘録) - Qiita
Amazon AuroraのフェイルオーバーとRailsのコネクションプーリング - Qiita
