EBS ボリュームに MySQL を使用して EC2 インスタンスをセットアップし、レプリケーション用のスレーブとして機能する別のインスタンスをセットアップしました。レプリケーションのセットアップは問題ありませんでした。私の質問は、これらのボリュームのスナップショットの作成についてです。スナップショット プロセスのためにテーブルをロックする必要があることに気付きました。これにより、ユーザーに不便が生じる可能性があります。したがって、私の考えは、マスター インスタンスをそのままにして、スレーブとして機能するインスタンスのスナップショットを作成することです。これは良い考えですか？同様の設定をしていて、正しい方法で私を導くことができる人はいますか?
また、スレーブ インスタンスのスナップショットを作成するには、テーブルをロックする必要があります。それは、レプリケーションが壊れることを意味しますか?
前もって感謝します。
スナップショットを開始するときにデータベースをロックしてファイル システムをフリーズすることをお勧めしますが、スナップショットを開始するための実際の API 呼び出しには数分の 1 秒しかかからないため、データベースとファイル システムが長時間ロック/フリーズされることはありません。
そうは言っても、言及しなかった他のいくつかの考慮事項があります。
データベースにロックを作成しようとすると、ロックが付与される前に、他のステートメントが完了するまで待機する必要がある場合があります。この間、保留中のロックは、ロックを取得して解放するまでさらにステートメントを待機する場合があります。これにより、実動データベースでのステートメントの流れが中断される可能性があります。
スナップショットの作成を開始すると、アプリケーション/データベースはボリューム上のファイル システムを自由に使用できますが、書き込みが多い場合は、iowait が高くなり、アプリケーションの速度が著しく低下することがあります。これは、アクティブ ボリューム上のブロックへの書き込みを許可する前に、バックグラウンド スナップショット プロセスでブロックを S3 にコピーする必要があるためです。
最初の問題は、ロックを要求し、すぐに許可されない場合はタイムアウトすることで解決します。次に、少し待って、ロックを取得するまで再試行を続けます。適切なタイムアウトと再試行の遅延は、データベースの負荷によって異なる場合があります。
あなたが提案したように、マスターではなくスレーブで頻繁に一貫したスナップショットを実行することで、2番目の問題を解決します。マスター固有の耐久性 (深い EBS プロパティ) を改善するためだけに、マスターに対して時折スナップショットを実行することを引き続きお勧めしますが、これらのスナップショットは、バックアップに使用しないため、ロックまたはフリーズで実行する必要はありません。
また、フラッシュとフリーズ (XFS) をサポートするファイル システムの使用をお勧めします。そうしないと、MySQL でロックされたテーブルのスナップショットを作成していて、そのテーブルのすべてのブロックが EBS ボリュームにまだないか、ファイル システムの他の部分が変更され、スナップショットで一貫性がない可能性があります。
興味があれば、MySQL と XFS (どちらもオプション) で一貫性のある EBS スナップショットを作成するために収集したベスト プラクティスを実行するオープン ソース ソフトウェアを公開しました。
最後の質問に答えると、マスターでテーブルをロックしてもレプリケーションは中断されません。私のスナップショット ソフトウェアでは、読み取りロックを使用してテーブルをフラッシュし、すべてがスナップショットされるディスク上にあることを確認し、キーワード「LOCAL」を追加して、フラッシュが潜在的なスレーブに複製されないようにします。
スレーブのスナップショットを確実に取ることができます。
あなたの説明から、スレーブが操作上使用されているようには見えません。
この場合、信頼できるボリューム スナップショットを取得する最も安全な方法は次のとおりです。