innobackupexecが実行された直後にapply-logを実行する必要がありますか？
他の質問を読んでみましたが、自分に合う答えが見つかりませんでした。ですから、すでに質問されていることを聞いたら失礼します。
私は自分を整理し、すべてのmysqlサーバーをinnobackupexecでバックアップしようとしています（Percona Mysqlのみを使用しているため）。 perconaのドキュメントと他のいくつかのブログ/投稿を読みましたが、完全バックアップが実行された直後に--apply-logを実行する必要があるかどうかわかりません。スクリプトを毎日のバックアップとしてスケジュールする必要がある場合、これだけをスクリプト化する必要がありますか？
innobackupex /data/backups
と私は使用する必要があります
innobackupex --use-memory=4G --apply-log /data/backups/2010-03-13_02-42-44/
データベースを復元する必要がある場合のみ？
私はかなり混乱しています、ここでいくつかの説明を得たいと思います。
ありがとうございました
Percona Xtrabackupのクイック101：
基本的に、ツールが行うことはデータのコピーを一貫性のない方法で実行することですが、コピー時に発生する必要なすべての変更を確実に取得し、データを適切な状態に戻すことができます。つまり、カスタムのInnoDBインスタンスを使用して「クリーンでないフルコピー」を実行し、次に「制御されたクラッシュリカバリ」を実行します。これが、2つのフェーズが必要な理由です（最初にコピーしてから、ログの適用。コミットされた変更が再適用され、コミットされていない変更が破棄されます）。
その2番目の部分は、データベースに接続せずに別のマシンで実行できます。そのため、これは別のコマンドです。
したがって、2つのオプションがあります。コピーが終了した直後、または復元の直前に--apply-logを実行します。
- 最初のケースの利点：緊急の場合に備えて、コピーは100％復元できます（
--copy-backだけ）。保存したトランザクションログは不要になったため、削除できます。 - その欠点：コミットされていない変更を削除すると、次の増分でフルバックアップをロールフォワードできなくなります。また、部分的なインポートに必要になる可能性のある追加情報は生成されません。
将来的に完全バックアップを作成して完全復元を実行するだけの場合は、コピーが完了した直後に安全に実行できます。 apply-logフェーズが高速である（またはトランザクションログの余分な時間とスペースを気にしない）場合、（部分的/増分バックアップの場合）柔軟性を高めたい場合は、リカバリの開始まで待つだけです。 。
本番データベースがミッションクリティカルであり、復元時間が最も重要でない限り、バックアップが必要になるまで、apply-logの実行を待つことをお勧めします。
バックアップを作成した直後にapply-logを実行する利点：
- バックアップはすぐに使用できる状態になり（--move-back/--copy-backを使用）、緊急事態の貴重な時間を節約できます
バックアップが必要になるまでapply-logを実行しないことの利点：
- あなたができるようになります テーブルレベルの回復 （適切なサーバーバージョンで）
- InnoDBログファイルがまだ作成されていないため、多くの書き込みがないサーバーでは、各バックアップmightが小さくなる可能性があります。
- ストリーミングバックアップ を取得して、ディスクまたはネットワーク経由で圧縮できます。
- 実行しないたびに、CPUサイクルとメモリを節約できます
どちらを選択するかに関係なく、バックアップフォルダーのどこかに自分自身にメモを入れて、バックアップを取るために何が行われたか、およびそれを復元するために実行する必要がある手順について言及することは価値があるかもしれません。