毎日22 GBのMySQLデータベースをバックアップする

現在、mysqldumpを使用してバックアップを行うことができます。しかし、Webサーバーを停止する必要があり、バックアップに約5分かかります。Webサーバーを停止しないと、永久に終了し、終了することはありません+バックアップ中にWebサイトにアクセスできなくなります。

22 GBの成長中のデータベースをより速く/より良くバックアップする方法はありますか？

すべてのテーブルはMyISAMです。

はい。

2番目のマシンへの複製をセットアップします。バックアップを行う必要がある場合は、セカンダリマシンをロックし、mysqlhotcopyまたはmysqldumpを実行してからロックを解除できます。マスターに追いつき、マスターをオフラインにする必要はありません。

書き込みI / Oを2倍にすることを気にしないのであれば、同じマシン上でこれを行うこともできますが、理想的にはリアルタイムで2番目の物理サーバーにバックアップし、必要に応じてスナップショットのバックアップをとってください。実稼働サーバーを妨げることなく。

理論的には、既知の状態とbinlogを使用してデータベースを復元することもできます。私はそれをやったことがないので、最初に調査してください。ただし、データベースの既知の状態をバックアップしてから、すべての新しいbinlogをバックアップして、復元が必要になった場合に再生できます。binlogは線形に書き込まれるため、新しいbinlogをリモートコンピューターにrsyncするのは非常に高速です。

編集：確かに、バックアップにbinlogを使用することが文書化されているようです。

この質問は非常に関連しています

OSがLinuxであると仮定してください。LVMを使用していない場合は、使用する必要があります。もしそうなら、スナップショットを介してバックアップを作成する非常に簡単な方法を以下に示します。

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

これにより、スレーブサーバーを追加せずに夜間バックアップを作成できます。私は高可用性のためのスレーブサーバーを持つことを非常に支持していますが、そのスレーブを作成できるまであなたが動けなくなると思わないでください。

読み取りロック付きのフラッシュテーブルは、運用システムで定期的（または半定期的）に実行したいことではありません。最後の手段に過ぎないはずです。

少なくとも2つのレプリケーションスレーブをセットアップします（もちろん、これには読み取りロック付きのフラッシュテーブルが必要です）。一度セットアップすると、もう一方を予備のマスターとして同期させながら、一方をバックアップすることができます。

また、スレーブの1つに障害が発生した場合、そのスナップショットを使用して、2番目（または3番目）のスレーブを再構築できます。すべてのスレーブに障害が発生した場合は、読み取りロック付きフラッシュテーブルに戻ります。

定期的にデータが同期していることを定期的にチェックするプロセスがあることを忘れないでください-これを行うにはmk-table-checksumのようなものを使用してください（これは設定するのは簡単です。詳細についてはMaatkitのドキュメントを参照してください）。

22 GBは比較的小さいため、これを実行しても問題はありません。大規模なデータベースでこれを行うと、さらに問題が生じる可能性があります。

上記のように、ここでの解決策は2つあります。

1. オフラインにできるスレーブへのサーバーのレプリケーションをセットアップします。これを行う最良の方法は、mysqldumpおよび--master-dataパラメーターを使用してデータベースのダンプを取ることです。
2. スレーブで夜間バックアップをセットアップします。--master-data --flush-logsおよび--single-transactionフラグを使用してmysqldumpを使用するか、mysqlサーバーを停止し、ディスク上のデータファイルをコピーして再起動することができます（レプリケーションは、中止しました）。
3. スレーブでスクリプトを実行し（5、10、20分など）、mysqlがまだ複製されていることを確認します。私はそれを行う簡単なpythonスクリプトを書きました。

テーブルにInnoDBを使用している場合は、--single-transactionフラグを使用して、テーブルロックを行わずに、マスター上でもデータベースの一貫したダンプを取得し、バックアップなしでバックアップを実行できることに注意してください。サーバーを停止します。ただし、上記のソリューションの方が優れています。

また、LinuxでLVMを使用している場合は、パーティションのLVMスナップショットを作成してからバックアップできます。LVMスナップショットはアトミックであるため、「読み取りロックでテーブルをフラッシュ」し、スナップショットを取得してロックを解除すると、一貫したスナップショットが取得されます。

I / Oの競合によりダンプの時間がかかりすぎることが心配な場合は、3台目のマシンを追加し、ネットワーク上でmysqldumpを実行してディスクのスラッシングを回避できます。

環境によっては、スナップショットは通常優れた方法です。特に何らかの理由でマスターをバックアップする必要がある場合。マスターとスレーブのペアを実行し、両方でスナップショットバックアップを使用します。

1. FLUSH TABLES WITH READ LOCK;
2. データベースとログファイルシステムのスナップショットを取得します。
3. UNLOCK TABLES;
4. 自由にスナップショットからデータファイルをコピーします。

InnoDBテーブルではSET AUTOCOMMIT=0;、読み取りロックを実行する前に実行する必要があります。

「実稼働MySQLデータベースをバックアップするためのベストプラクティス？」をご覧ください。Stack Overflowに関する同様の投稿です。

段階的なバックアップを行うことができます。1時間ごとにレコードの1/24をバックアップします。このアプローチの唯一の問題は、1日の最初の数時間でクラッシュした場合、その時点からクラッシュした時点まで何も失われることです。いずれにせよ、失われたレコードは24時間未満です（これがあなたにとってどれほど重要かはわかりません）。