mysqldump ファイルを復元しようとすると、MySQL データベースが破損するシナリオにこれまで何度か遭遇しました。数年間、同じ手順 (バッチ スクリプト経由) を問題なく使用してきましたが、ここ数か月でようやくこの問題に遭遇し始めました。
MySQL Server バージョン 5.7.18-0ubuntu0.16.04.1 (Ubuntu 16.04.2 LTS) を実行しており、合計で約 350K のレコードを含む 2 つの MyISAM テーブルを復元しています。
内部からテーブルをバックアップし、リモート データベース サーバーに復元するには、次のコマンド スクリプトを使用します。
"%mysql_path%\mysqldump.exe" --user=root --password="%PWD%" --host=%source% ourdbname --tables table1 table2 | "%mysql_path%\mysql.exe" -uroot --password="%PWD%" --host=%dbtarget% -C ourdbname
変数%%は、より大きなバッチ スクリプトの一部として提供されます。基本的には、ダンプの出力を mysql.exe にパイプして、リモート サーバーに復元します。スクリプトは Windows 10 マシンで実行されますが、ソース データベースと宛先データベースは両方とも Linux 上にあります。
復元部分ではデータベースが破損し、DB サーバーの CPU 使用率がコアごとに 100% に急上昇します。この問題を解決する唯一の方法は、mysql プロセスを強制終了し、ファイルを削除して.frm, .MYD, .MYIから mysql を起動し、テーブルをローカルに復元することです (mysqldump ファイルをサーバーに scp して復元します)。
データベースが破損するのは、Web サイトにアクティブなトラフィックがあるときだけであることがわかりました。そのため、サイトを停止し (別のサーバーで Java を実行して JDBC 経由で接続)、スクリプトを実行してからサイトをオンラインに戻すと、100% 正常に動作します。これは理想的ではありませんが、現時点ではこれが唯一の方法です。
この原因は何だと思いますか? フロントエンド サーバーを停止せずに回避する方法はありますか?
答え1
サイトのデータベース エンジンとして MyISAM を使用しているようです。InnoDB を使用することをお勧めします。多くの点で優れています。
ただし、ここでの主な問題は、バックアップがデータベースに書き込まれるのと同時に、Web アプリケーションがデータベースに書き込む可能性が高いことです。実際のテーブル スキーマによっては、さまざまな悪影響が生じる可能性があります。正しく記憶している限り、MyISAM には行レベルのロックがないため、MyISAM を使用するとうまく機能します。
したがって、InnoDB を使用するとこの問題が解決する可能性がありますが、そうでない可能性もあります。唯一の安全なオプションは、フロントエンド サーバーを停止することです。別のオプションは、受信データをデータベースに安全に書き込むリモート アプリケーション用の API を作成することです。