mysqldump --single-transaction で alter table が発生した場合はどうすればよいですか?

テスト環境:

MySQL 5.5.14

データベースtestdb01の下にテーブルtb1001があります。現在のテーブルには2つのデータがあります:

##===========。 === ============================================##

空のセットがエラーなく返されたことがわかりました。

これは、私の同僚の操作の現象も合理的に説明しています。mysqldump プロセス中に、テーブル構造が変更され、変更操作はブロックされず、mysqldump 操作は「正常に完了」しました。

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb1001` オペレーションはエラーやデータを返さないため、mysqldump プロセスは tb1001 を空のテーブルとして扱い、すべてのテーブルがエクスポートされるまで後続のテーブルのエクスポートを続行します。その後、実行成功ステータスを返します。ただし、エクスポートされたバックアップにはすでに tb1001 のデータがありません。このバックアップを使用してデータを復元すると、必然的に「データの損失」が発生します。

解決策:

MySQL 5.5 バージョンでテーブルを変更する前に、まず現在のサーバーが mysqldump 操作を実行しているかどうかを確認して、2 つの操作の並列実行を回避します。

mysqldump によってエクスポートされたテーブルを変更する場合、mysqldump が終了するまで変更操作はブロックされます。この状況は MySQL バージョン 5.6 と一致します。

概要:

MySQL バージョン 5.5 の場合、mysqldump はテーブル変更操作と同時に実行されます:

テーブル変更操作が「mysqldump が開かれた後、変更されたテーブル データがエクスポートされるまで」の期間内に開始される場合"、テーブル変更操作は正常に完了し、mysqldump の実行は失敗しませんが、変更されたテーブルのデータを正常にエクスポートできません;

"mysqldum がエクスポートした時間内にテーブル変更操作が開始された場合、 「テーブル データを変更していますが、mysqldump 操作はまだ完了していません」というメッセージが表示された場合、テーブルは変更されます。操作はブロックされますが、mysqldum は正常に完了できます。mysqldump 操作が完了すると、テーブル変更操作は通常どおり実行できます。

MySQL バージョン 5.5 の場合、バックアップ内の変更されたテーブルのデータが失われ、データの不整合が発生することを避けるために、mysqldump 操作とテーブル変更操作を同時に実行しないようにする必要があります。

以上がmysqldump --single-transaction で alter table が発生した場合はどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。