誰もが一度は「差分だけバックアップできたらな」と思うところですが、なんとXtraBackupには差分バックアップがあるのです。Backups巨大に膨れ上がったデータベースの更新分だけを抽出して、別サーバで完全体に戻しておく、といったことができるため、より効率的なバックアップを行うことができます。少なくともバイナリログによる差分バックアップとかダサいことはやる必要がなくなります。メリットとデメリットメリット差分バックアップの処理時間は全体バックアップより短くなります差分バックアップは容量が変更分だけのためかなり小さくなりますベースバックアップから好きな差分のところまで復元できますデメリットリストアのために差分の適用処理が必要になりますベースと差分のバックアップ世代管理が複雑になります差分バックアップバックアップ取得まるごと取得したバックアップに対して、差分だけを別のディレクトリに保存していきます。拡張子がついたデータが保存されます。差分を取る前に数回更新クエリを実行しただけですが、ベースが1GBに対して、差分は1MBに満たないサイズになっています。ファイルにはLSNの値が記録されています。差分として記録した範囲です。値が大きくなることがあります。してから、ベースに対して、差分を適用していきます。仕上がったベースディレクトリが完成品となり、続きは通常のリストアと同じ手順になります。差分で取得してベースに適用したデータが、本当に正しいデータとなっているかを確認します。以下のような手順でバックアップ取得とクエリ実行を行い、最初のベースに差分を適用したデータと、最後に再取得したベースをmd5で比較します。極小にして実験しています。--target-dir=/backup/base_after/比較ibdataと更新したテーブルの.ibdをmd5で比較してみます。/backup/base_after/sbtest/sbtest.ibd634a684b05f5df2325a6ebd00215a6ac差分3まで適用したバックアップと、新規バックアップのハッシュ値が一致したので、差分システムに問題ないことが判明しました。使いどころ普通のバックアップは、1日に1回の全体バックアップで、別サーバに転送しておいて、最新何日か分と月初めなど特定の日にちを除いて間引きする、といったものだと思います。それに対して差分バックアップはどう使うべきか考えてみます。極端に、最初の1回を除いて残り全て差分で保存したらどうなるか。1年後にバックアップを必要とした時、365個の差分を割り当ててからリストアすることになります。これだと数が多いし、1年間の差分が全て正常かなんて自信がもてないでしょう。差分を取得するたびに別サーバで差分を適用して常に完成版を作っておくべきと思いますが、それでもその完成版が正常なバックアップであることを定期的に証明したいだろうし(※1)、世代管理という機能を失うのであまり上手くありません。日曜日だけ全体バックアップにして、他は差分にするといった落とし所もありますが、本番サーバで全体バックアップを実行してしまうとあまり通常の方法と変わりありません。差分の正常性を疑うなら、通常の全体バックアップも疑うべきで、逆に考えると差分も信じるしかないのですが・・・差分だとやはり心理的に怖さがあるので大丈夫だと確認できる仕組みを用意したいところです重要なポイントとして、差分のウマ味は、本番サーバでの処理時間と容量が激減し、別サーバへの転送時間も短くなることなので、その部分は常に固定にしたいと考えます。本番サーバでは常に差分のみ取得して転送し、別サーバでは適用を行いつつ日曜には完成版のコピーを保管しておき、3ヶ月以上経過したものは削除する。これだと12個の完成版と、3ヶ月分の差分ファイルで済み、特定の日にちのデータが欲しい時用の世代管理にもなります。あとはディスク容量に応じて間引きやコピー頻度を調整するだけです。なると、あとは差分適用バックアップの正常性のみが問題になります。いえ、データの中身を照会しての完全一致確認など不可能ですから、信頼してしまうのも1つの手だと思います。一致しなかったら新規に全体バックアップ取り直しそれからメンテ作業へとオペレーションを増やせば定期的に確認できます。この方法は、作業量増加により人災が起こる可能性も増えますが、それよりもバックアップに対する姿勢と質が強固になるメリットがあると思います。落とし所が難しいですが、サービスが大きくなると必須な仕組みにもなりうるので、お試ししておくと良いのではないでしょうか。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。