web-dev-qa-db-ja.com

Subversionを使用したインクリメンタルMySQLバックアップ

当社のMySQLデータベースサーバーは、ダンプファイルサイズが1〜100 MBの範囲で、数十のデータベースをホストします。

現在、バックアップアプローチはmysqldumpであり、シェルスクリプトでラップされ、crontabから実行されます。これは私たちにとって素晴らしい働きをしました。唯一の主な欠点は、ダンプファイルを保存するための大容量のストレージ要件です。

MySQLデータベースダンプはテキストファイルなので、当然、Subversionなどのバージョン管理システムに保存することを検討します。 Subversionは、各コミットでファイルのデルタのみを保存することを思い出します。

このアプローチは推奨されますか？知っておくべき落とし穴はありますか？

backupsvnmysql
3
Arie K

sirStanによって言及されたbinlogは良いアプローチです。

または、mysqldumpsを実行してから、 rdiff-backup を使用してdumpfileのバックアップを作成することもできます。 rdiffはn個の最後のバックアップを保持し[数を決定します]、ファイルの最新バージョンの完全なスナップショットと以前のバージョンを再構築できるdiffのセットのみを保持するため、スペース効率が非常に高くなります。

svnに入れたものは何でも、svnにとどまります。リポジトリは大きくなるだけなので、SQLスキーマ、ソースコード、そしておそらくドキュメントを保持するのに適した場所です。ただし、SQLからの実際のデータではありません。

2
pQd

MySQLのドキュメントには、まさに必要なものが含まれている場合があります。バイナリ増分バックアップ！ （rsync/ftp/etcを介した貧弱なスレーブサーバーにも最適です）。

MySQLは増分バックアップをサポートしています：

バイナリロギングを有効にするには、-log-binオプションを使用してサーバーを起動する必要があります。 5.2.4項「バイナリログ」を参照してください。バイナリログファイルは、バックアップを実行した時点以降に行われたデータベースへの変更を複製するために必要な情報を提供します。増分バックアップ（最後の完全バックアップまたは増分バックアップ以降に発生したすべての変更を含む）を作成する時点で、FLUSHLOGSを使用してバイナリログをローテーションする必要があります。これが完了したら、最後の完全バックアップまたは増分バックアップの瞬間から最後の1つを除くすべてのバイナリログをバックアップ場所にコピーする必要があります。これらのバイナリログは増分バックアップです。復元時に、6.3項「ポイントインタイムリカバリ」で説明されているようにそれらを適用します。次回完全バックアップを実行するときは、FLUSH LOGS、mysqldump --flush-logs、またはmysqlhotcopy--flushlogを使用してバイナリログもローテーションする必要があります。セクション4.5.4「mysqldump—データベースバックアッププログラム」およびセクション4.6.9「mysqlhotcopy—データベースバックアッププログラム」を参照してください。

2
SirStan

この質問は少し古くなっていることは知っていますが、私の会社では同様のことを実験してきました。サイズが最大300MBのxml形式のバックアップ（MySQLからではなく、単にテキストファイル）をプルし、SVNリポジトリに毎晩1週間強コミットしています。最初のコミットでリポジトリは41MBになりましたが、それ以降の各コミットは小さくなっています。現在、リビジョン8であり、リポジトリの合計サイズはわずか57MBです。これは、含まれているすべての履歴のサイズの約2.5％です。

同じデータを使用してrdiff-backupを試しました。以下は比較です（すべてのサイズはMB単位）：

バックアップ＃バックアップサイズリポジトリサイズデルタrdiffサイズデルタ
 0 0 0.03 0.03 0 0 
 1 286.05 41.49 41.46 286.05 286.05 
 2 285.93 45.97 4.49 322.13 36.08 
 3 286.23 50.52 4.54 323.27 1.14 
 4 286.63 50.79 0.27 324.54 1.26 
 5 287.46 55.52 4.73 326.54 2.00 
 6 287.76 55.77 0.25 327.72 1.19 
 0.37 328.98 1.26 
 8 288.41 56.63 0.50 330.36 1.38

デルタはほぼ同じように見えます（svnの方が優れている場合もあれば、rdiff-backupの方が優れている場合もあります）。したがって、全体的なサイズでは、SVNが優先されます。 rdiffの利点は、古いバックアップを簡単に削除できることです。SVNでは、古いリビジョンを削除するために svnadmin dump および svnadmin load を実行する必要があります。好みの問題だと思いますが、SVNは使いやすく、それをサポートするためのツールがたくさんあります。

1
sbell

svnを使用すると、膨大なスペースが必要になります。

100mbのファイルをコミットしてsvnがバージョン1になるとすると、200mbの新しいファイルを追加すると、バージョンは2になります。

Svnリポジトリは300mbになります。

バージョン1のファイルが好きな場合は、svn co -r 1svnrepourlを実行する必要があります。

1
jonaz

プロセスを自動化し、データベースの特定の選択とテーブルの除外を可能にするこのスクリプトを確認してください[免責事項私は作成者です] - http://mysql-svn-backup.redant.com.au/

1
Sam Bauers