MySQL Slave relay_log repair

Time:

Fault: the database server is restarted without reason. When the Slave is started, the relay_log is damaged, and the SQL thread cannot proceed.

Cause of failure: OS restart may cause relay_log to fail to be synchronized normally

In this case, the solution is to re-change the master to, but the master log pos uses Exec_Master_Log_Pos (show slave status \ G variable output) to re-Accept data from the location where the slave has been executed.

I thought everything was okay, but the duplicate key error was reported on the slave. Then I can imagine that the SQL _slave_skip_counter = 1 was skipped.

The reason for duplicate key is that MYSQL itself is a problem.

Slave does not perform atomic operations to commit transactions or update replication information:

I/O thread synchronization: fsync calls refresh the relay log to the disk and update master.info respectively.

The following situations may cause repeated acceptance events:

Server refresh relay_log. When the master reading location of the master.info file is being updated, the server goes down and master.info is not updated, which leads to repeated events when replication is started.

SQL thread synchronization: the SQL thread first submits the transaction to the storage engine, and then updates the relay_log.info file.

Events have been applied on the database, but relay-log.info is not updated. When it is restored, the SQL statement repeats some events.