mysql
私は約300GBのデータベースを持つUbuntu 8.04システムを持っています。次のコマンドを使用してmysqldump
すべてのデータベースをダンプしました。
mysqldump -u root -p --all-databases > file.sql
mysql
これで、RHEL6システムで次のコマンドを使用してデータベースを復元しようとしました。
mysql -u root -p < file.sql
しかし、上記のコマンドは時間がかかるようで、実行に時間がかかるようです。 3日後にリカバリされたデータベースサイズを確認してみると、リカバリされたデータベースサイズはわずか30GBでした。
データベースを復元する効率的な方法はありますか?
答え1
回答を投稿する前に、私が質問した内容をもう一度申し上げたいと思います。ここそしてここ。誰かが提案できるように、この質問は次のとおりです。データベース管理者。ところでここに載せる理由は編集が必要だからです/etc/my.cnf
。
最初のソリューション
/etc/my.cnf
次のパラメータを含めるように編集します。構成ファイルの場所は、Linuxディストリビューションによって異なる場合があります。 RHEL6では/etc/my.cnf
。
innodb_doublewrite = 0
innodb_flush_log_at_trx_commit = 0
innodb_support_xa = 0
innodb_locks_unsafe_for_binlog = 1
この提案は次のとおりです。ドロバートこの解決策を思い出した彼に感謝します。
テスト:復元コマンドほど遅くはありませんが、mysql
この方法はまだかなり時間がかかります。このコマンドを3日間実行した結果、約130GBが回復しました。
2番目の解決策
データベースダンプをインポートする前に、いくつかのフラグを設定して回復プロセスを大幅に高速化できます。
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
.sql
上記のフラグはファイルに設定する必要があります。自動コミットを無効にしたので、復元が完了したら手動でコミットする必要があります。
COMMIT;
上記のステートメントは.sql
ファイルの最後のステートメントでなければなりません。実際、私たちはmysqldump
以下を実行するスクリプトを見つけることができますここ。
このソリューションをテストする機会はありませんでしたが、外部キーチェックを無効にするので意味があります。
データベース全体を復元しているので、一意のチェックと外部キーのチェックを無効にすると、作業を高速化できます。また、復元の進行中ではなく、復元の終わりにすべてをコミットすることで、さらに速度が大幅に向上します。
3番目のソリューション
mysql
完全なデータディレクトリをバックアップしました。データディレクトリは通常にあります/var/lib/mysql
。私の場合、データディレクトリは別々のパーティションとしてマウントされました/mounts/mysql
。フォルダ全体をバックアップしたため、フォルダ全体を最新のRHEL6システムに復元しました。復元する前にデーモンがmysqld
起動していないことを確認してください。コマンドを使用して復元しましたが、rsync
ファイル権限が現在新しいRHEL6システムに設定されていることを確認したかったです。そのため、/mounts/mysql
新しいRHEL6システムに復元した後、次のコマンドを実行しました。
chown -R mysql:mysql /mounts/mysql
これでデータベースをテストしましたが、すべてが本当に素晴らしく見えました。回復時間は約3時間かかります。
mysql
データベースを回復するために上記の方法を使用することを提案した人はどこにも見たことがありません。私はで見たこれ答えは、mysql
データディレクトリからデータベースを復元するには、バージョンが互換性がなければならないことです。しかし、これまでの私の復元の経験によると、そうではありません。権限が正しく設定されていると、データベースは正常に動作します。
ただし、.sql
データベースをデータベースまたはデータベースに復元しようとする場合は、mysql
このファイルが必要です。sql-server
postgre