mysqlのリカバリプロセスに時間がかかります。

mysqlのリカバリプロセスに時間がかかります。

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-serverpostgre

関連情報