技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL（以下：Aurora MySQL）の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに
MySQLによるオンラインバックアップについて。バックアップにはmysqldumpコマンドを使いますが、単純にバックアップといえども、リストア(復元)する時のことも考えてないといけません。 バイナリログがどこまでかかれているかバックアップをとったとしても、実際にリストアする際には、時間差があります。例えば今日の朝バックアップをとったとして、夜にデータが壊れてリストアする場合、朝から夜までに保存されたデータは復旧できません。そこで、バイナリログが重要になります。バイナリログには実行されたSQL文が記録されていますので、バックアップデータ＋このバイナリログで補填できます。 ですので、バックアップをとる際に、その時点でバイナリログがどこまでかかれているか記録しておきます。これは–mastar-data=2オプションをつけます。 共有ロックをかけるバックアップとっている際中に更新が行われないようロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
