現在、Perconaのエクストラバックアップを研究しています。 「レプリケーション環境でのバックアップの作成」の段落のマニュアルには、--safe-slave-backup
オプションの使用が常に推奨されていると記載されており、その背後にある理由を理解しています。
このオプションを使用しない場合、実際に結果に違いがあるかどうか、今疑問に思っています。バックアップにログを適用した後、このオプションを使用した場合と使用しない場合のバックアップに違いがある理由がわかりません。
私たちの実稼働環境ではこのオプションを使用していないので、私は尋ねています。バックアップは深夜に実行されますが、今夜は失敗しました。バックアップはスレーブで行われるので、バックアップを取るためにSQLスレッドを停止するのは気が引けるでしょう。
として マニュアルによると :
このオプションは、スレーブSQLスレッドを停止し、
Slave_open_temp_tables
のSHOW STATUS
がゼロになるまでバックアップの開始を待ちます。 [...] SQLスレッドは、開いている一時テーブルがなくなるまで開始および停止されます
これは、Percona Xtrabackupが基本的にサーバーの制御されたクラッシュ/シャットダウンを模倣し、一時テーブルによってスレーブの一貫性が失われる可能性があるためです MySQLマニュアルで確認できます 。これは一貫性の問題ではありませんそれ自体(バックアップは指定されたタイムスタンプ/ビンログと一致します)が、マスターと再同期するとスレーブが一部のトランザクションを失う可能性があります(通常使用法-別のスレーブを作成するためのスレーブのクローン作成)。
ROWベースのレプリケーションを使用している場合、これは発生しないため、これを使用することをお勧めします。しかし、それを使用できない、または使用したくない人もいるので、これは新しいスレーブがうまく機能することを100%確信する方法です。一般的なレプリケーションシナリオでは、作成されている一時テーブルが少ないと仮定すると、--safe-slave-backup
の使用はそれほど問題にはならないかもしれませんが、それが回避策です(通常、これらのオプションは、過去に問題が発生したために追加されます)。
GTIDレプリケーションを使用している場合を除き、常に--slave-info
を使用することをお勧めします。
独自のマニュアルにあるように、バックアップをテストするためにpt-table-checksum
を使用することは良いアドバイスです。