レプリケーションに使用されるEBSボリュームのスナップショット

スナップショットを開始するときにデータベースをロックしてファイルシステムをフリーズすることをお勧めしますが、スナップショットを開始する実際のAPI呼び出しには数分の1秒かかるため、データベースとファイルシステムが長時間ロック/フリーズされることはありません。

そうは言っても、あなたが言及しなかった他のいくつかの考慮事項があります：

1. データベースにロックを作成しようとすると、ロックが付与される前に、他のステートメントが終了するのを待つ必要がある場合があります。この間、保留中のロックは、ロックを取得して解放するまで待機するステートメントをさらに追加する可能性があります。これにより、本番データベースのステートメントのフローが中断される可能性があります。

2. スナップショットの作成を開始すると、アプリケーション/データベースはボリューム上のファイルシステムを自由に使用できますが、書き込みが多い場合は、高いiowaitが発生する可能性があり、アプリケーションの速度が著しく低下する場合があります。これは、バックグラウンドスナップショットプロセスがアクティブボリューム上のそのブロックへの書き込みを許可する前に、ブロックをS3にコピーする必要があるためです。

最初の問題は、ロックを要求し、すぐに許可されない場合はタイムアウトすることで解決します。次に、少し待って、ロックを取得するまで再試行し続けます。適切なタイムアウトと再試行の遅​​延は、データベースのロードによって異なる場合があります。

私は、あなたが提案したように、マスターではなくスレーブで頻繁に一貫したスナップショットを実行することによって、2番目の問題を解決します。本来の耐久性（深いEBSプロパティ）を向上させるために、マスターに対して不定期のスナップショットを実行することをお勧めしますが、バックアップに使用しないため、これらのスナップショットをロックまたはフリーズして実行する必要はありません。

また、フラッシュとフリーズ（XFS）をサポートするファイルシステムの使用をお勧めします。そうしないと、MySQLでロックされたテーブルのスナップショットが作成され、EBSボリュームにまだすべてのブロックがないか、ファイルシステムの他の部分が変更されてスナップショットで一貫性がない可能性があります。

興味があれば、MySQLとXFS（両方ともオプション）を使用した一貫性のあるEBSスナップショットの作成に関連して収集したベストプラクティスを実行するオープンソースソフトウェアを公開しました。

最後の質問に答えるために、マスターでテーブルをロックしてもレプリケーションは中断されません。スナップショットソフトウェアでは、テーブルを読み取りロックでフラッシュして、スナップショットが作成されるディスク上にすべてがあることを確認し、フラッシュが潜在的なスレーブに複製されないようにキーワード「LOCAL」を追加します。