MySQLレプリケーションエラー：Error_code：1032
読み取り専用のMySQLリードレプリカを設定しました。マスターとスレーブの両方がMySQL 5.6を実行しています。スレーブは直接書き込まれることはありませんが、1〜2時間以上同期を保つことができないようです。少し走った後、私は常にこのタイプのエラーに遭遇します：
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log
次に、MySQLダンプからスレーブを再作成するプロセスを実行する必要がありますが、どうしてもこのエラーが発生します。なぜこれが起こっているのか誰かが手掛かりを持っていますか？
使用しているエンジン、複数のスキーマを使用しているかどうか、mysqldumpで使用しているオプションによっては、一貫したダンプが得られない場合があります。
2つのスキーマがある場合、たとえば、1つの名前がdevelopmentでもう1つがproductionである場合、mysqldumpはスキーマごとに別々にテーブルをロックします。つまり、開発スキーマをバックアップしている間も、プロダクションスキーマは書き込み可能で更新されます。
2つのスキーマのダンプを取得してレプリケーションを開始したので、2つのスキーマは実際には異なるbinlogの位置にあります。つまり、Error_code 1032を取得したとき、そのキーは実際にはありません。
バックアップする必要があるテーブルのallがInnoDBである場合、mysqldumpの--single-transactionオプションを調べる必要があります。 InnoDBとMyISAMが混在している場合、InnoDBテーブルのみが一貫していることが保証されます。 MyISAMテーブルは、引き続きこのオプションを使用して書き込まれます。
InnoDBとMyISAMが混在している場合、または純粋なMyISAMのみである場合、（mysqldumpを使用する）最良のオプションは--lock-all-tablesを使用することです。それはまさにそのように聞こえ、ダンプが完了するまで何も書き込まれません。これには、データベースに依存するアプリケーションまたはWebサイトもロックされるという大きな欠点があります（書き込みできないため）。
最良のオプションIMOは、すべてがInnoDBに移動していない場合は移動し、 Percona Xtrabackup を使用することです。 MyISAMテーブルでも問題なく機能しますが、InnoDBテーブル（cpまたはrsync）とは異なるツールを使用します。 MyISAMテーブルをコピーしている間もテーブルをロックする必要がありますが、その時間を最小限に抑えることが最善です。 rsyncメソッドを使用する場合、ツールは最初にすべてのMyISAMテーブルをコピーし、、次にテーブルをロックしてから、コピーします最初のコピー以降に更新されたテーブル。ロックは、2番目のrsyncの間だけ保持する必要があります。