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
