3

私は 200GB / 400Mrows の mysql/innodb データベースを持っています - 私が見つけた合理的なものをはるかに超えています。

1 つの驚くべき問題は、バックアップの復元です。mysqldump は巨大な sql ファイルを生成し、それらを新しいデータベースにインポートして戻すのに約 1 週間かかります (トランザクションを大きく/小さくしたり、インポート中にキーをオフにしたり、ネットワーク圧縮などを高速化しようとする試みはこれまで失敗しました。myisam インポートは2 倍速くなりますが、トランザクションは発生しません)。

さらに悪いことに、これについて何らかの助けを得たいと思っています.1週間に200GBを超える転送を行うネットワーク接続は、途方もなく壊れる可能性があり、SQLインポートプロセスは重要な方法で続行できません.

それに対処する最善の方法は何ですか？現在、接続が切断されていることに気付いた場合は、最後にインポートされたテーブルの最上位の主キーをチェックして、接続がいつ終了したかを手動で把握しようとします。次に、基本的にこれを行う perlscript を用意します。

perl -nle 'BEGIN{open F, "prelude.txt"; @a=<F>; print @a; close F;}; print if $x; $x++ if /INSERT.*last-table-name.*highest-primary-key/'

これは本当に進むべき道ではないので、最善の方法は何でしょうか?

4

3 に答える 3

1

mysqldump を使用して大規模なデータベースをバックアップすることはできません。200G は実行可能ですが、より大きなデータベースはますます悪化します。

あなたの最善の策は、データベース ディレクトリのボリューム スナップショットを取得し、それを何らかの方法で圧縮することです (これは私たちが一般的に行っていることです)。

ファイルシステムまたはブロックデバイスがスナップショットをサポートしていない場合、基本的に問題があります。データベースをシャットダウンしてバックアップを取ることはできますが、それをしたいとは思いません。

それを復元するには、反対のことを行ってから再起動し、innodb リカバリが問題を解決するまで (おそらくしばらく) 待ちます。

maatkit mk-parallel-dump および restore ツールは、速度の点で mysqldump よりも少し優れていますが、それらの正確性について 100% 確信があるわけではありません。

編集：質問を読み直して、ファイルシステムのスナップショット+ rsyncがおそらく最善の方法だと思います。ライブシステムに影響を与えずにこれを行うことができ（最後のバックアップ以降に変更されたものを転送するだけで済みます）、接続が失敗した場合はrsyncを再開でき、中断したところから続行します.

于 2010-01-30T08:06:38.947 に答える
1

MySQL ボックスには、すべてのデータを 2 倍にするのに十分なハード ドライブ容量がありますか? ここではローカル ストレージが最適ですが、それができない場合は、iSCSI を利用する何らかの NAS デバイスを試すこともできます。それはまだネットワーク経由で行われていますが、この場合は、非常にスリムな OS を搭載し、再起動する必要がほとんどない NAS のみに依存しているため、スループットと信頼性が向上します。

于 2010-01-29T17:20:31.507 に答える
0

データベース内のすべてが必要ですか?

情報の一部をアーカイブ データベースにプッシュし、ユーザーがアーカイブ内のレコードを表示できるようにする何かをアプリケーションに追加できますか?

明らかに、これはアプリケーションと設定に大きく依存しますが、解決策になる可能性がありますか? あなたのDBはおそらく大きくなるだけです....

于 2010-01-29T17:24:24.670 に答える