web-dev-qa-db-ja.com

バックアップの復元時のMySQL重複エントリエラー1062

申し訳ありませんが、私は同様のスレッドを見ましたが、それでも私の問題に対処するためのスレッドを見つけることができませんでした。これについての詳細情報が必要でした。

要件：既存のDB 'db3'の正確なレプリカ 'db4'を作成します。

手順が続きました：

  • mysqldump -uuser -ppass db3> db3.sql（サイズは6G）
  • mysql -uuser -ppass db4 <db3.sql（db4は新しく作成された空のデータベース）

2番目のステップでエラーがスローされます。

ERROR 1062 (23000) at line 5524: Duplicate entry '600806' for key 1"

--forceを使用して、2番目のステップを再度実行しました。復元は完了しましたが、さらに2つの同様のエラーが発生しました。

ERROR 1062 (23000) at line 6309: Duplicate entry '187694' for key 1    
ERROR 1062 (23000) at line 6572: Duplicate entry '1567400' for key 1

完了時にdb4データベースの特定のテーブルを照会したところ、欠落しているレコードを確認できました。

質問：

  1. これは、破損した/問題のあるdb3データベースを示していますか？

  2. Db3の「一貫した/機能する」レプリカ（db4）を作成する方法

  3. （2）が失敗した場合、トラブルシューティングを行い、それが発生する理由の背後にある理由を見つける方法は？

おかげで、

mysqlbackupmysqldumprestoremysql-5
4
user492160

これは確かにdb3の問題を示していると思います。デフォルトでは、mysqldumpは「拡張」挿入ステートメントを生成し、1行に複数行の挿入を含みます。

INSERT INTO table_name VALUES (...), (...), (...), ...;

単一のステートメントでの複数の挿入は、個々の挿入ステートメントを実行するよりもはるかに高速であるため、これは最適化です。

ただし、--skip-extended-insertオプションを使用してこの動作を無効にすることができます。

バックアップにこのオプションを使用すると、復元がはるかに遅くなるため、良い考えではありませんが、このオプションを使用すると、目で見やすくなり、grepまたは同様のツール。

このオプションを使用してデータベースをダンプし、ファイルを検索して、エラーをスローしている重複キーを探します。重複している行または重複しているはずの重複するキーを持つ行が見つかる可能性があります... db3。

これがInnoDBで発生する可能性のある方法は考えられませんが、MyISAMを使用すると、明らかに可能です。

他にもいくつか役立つmysqldumpオプションがあります。

  • --replaceは、ステートメントをREPLACE INTOの代わりにINSERT INTOとして書き込むファイルを生成します。これにより、ファイルの前半で発生した競合するレコードがファイルの後半で発生する重複キーレコードが生成されずに置き換えられます。エラー
  • --insert-ignoreは、INSERT IGNORE INTOではなくINSERT INTOとして記述されたステートメントを含むファイルを生成します。これにより、ファイル内で以前に発生した重複キーレコードが、後で競合するため、復元されたテーブルに永続化されます。レコードは無視され、挿入されず、エラーも生成されません。
6
Michael - sqlbot

MysqldumpファイルでInsert intoを検索してInsert Ignore intoに置き換えることもできます。

4
Sachin Singh

序文

そのため、レプリケーションサーバーの1つが不整合な状態になった後、この問題に遭遇しました。迅速な修正でオンラインに戻すことができなかったため、新しいバックアップでレプリケーションを再初期化することにしました。

上記の質問は同じ問題ではありませんが、同じエラーを返します。そのため、他の人が探している場合に備えて、この回答を追加することにしました。

Server Fault に関するこの質問の正確な複製でもありますが、その質問は（私の）Googleの結果で上位にランクされているため、そこにも投稿しました。

私たちがしたこと

MySQL Workbenchを使用してインスタンス上のすべてのデータベースを削除しました。インスタンスを再起動し、インスタンスにデータベースが残っていないことを再確認しました。マスターサーバーでは、いつも使用するスクリプトを使用して新しいバックアップの作成を既に開始しています。

次に、障害が発生したサーバーにバックアップが作成されたらインポートを開始し、数時間後にほとんどのデータをインポートして次のようなエラーで失敗しました。

ERROR 1062 (23000) at line XXX: Duplicate entry 'dbName-tblName' for key 'PRIMARY'
Operation failed with exitcode 1

大丈夫だと思いました。バックアップの作成中に問題が発生した可能性があります。バックアップ内のデータをチェックアウトしましたが、問題は見つかりませんでした。すべてを見逃さないようにすべての手順を再試行しましたが、残念ながら葉巻はありませんでした。

実際の問題

表示されるエラーは、データの実際の挿入ではなく、インデックスの作成です。これが問題なくデータが挿入された理由です（チェックした）が、それでもエラーが発生しました。どうやらすべてのテーブルを削除するだけでは不十分で、インデックスデータがサーバー上にまだ存在しています（これは、以前にこの問題が発生したことがないため、MySQL 5.6での変更が原因である可能性があります）。また、これらのインデックスのインポートはインポートファイルの途中にあるため、残りのデータはインポートされませんでした。

修正

Mysqlデータベースフォルダー内のibdata1ファイルとすべてのinnodb_index_statsおよびinnodb_table_statsファイルを削除してから、インスタンスを起動しました。その後、MySQLは一部のシステムテーブルが欠落していることを通知します ここで詳細を確認できます

これで問題が解決し、サーバーは期待どおりに複製されています。

うまくいけば、どこかで誰かのために数時間節約できます:)

1
Sc0tTy