Remember a MySQL master-slave replication error

The master copy from often wrong, I was ***, and the last reason is problematic from a library of configuration files, I have resolved, and today they wrong, as shown: So the solution is to skip the erroneous transaction.

1

Before MySQL5.6, simply execute:

mysql>set global sql_slave_skip_counter=1;

Skipping a transaction error, you can continue to replicate, but after Mysql5.6 to die:

wps7

analysis:

Because it is to be replicated by gtid, so it is necessary to skip this transaction to continue the replication binlog on this transaction can go to see the Lord: because they do not know which GTID find the error, so I do not know how to skip which GTID. But in the show slave status in the information can be found in the implementation of Master in the POS: 635508

wps8

By command

mysql>  SHOW BINLOG EVENTS in 'mysql-bin.002121' from 635508 limit 10;

Check out the tune can be had GTID

mysql-bin.002121 | 635508 | Gtid           | 1408099586 |      635573 | SET @@SESSION.GTID_NEXT= '9b4f9d6b-5777-11e8-9e63-ec0d9a2fab3e:97831165'

Then, FIG performed as follows:

mysql>set session gtid_next= '9b4f9d6b-5777-11e8-9e63-ec0d9a2fab3e:97831165';

mysql>begin;

mysql>commit;

mysql>SET SESSION GTID_NEXT = AUTOMATIC;

mysql>start slave;

wps9

Then view status

wps10

The problem is solved, Perfect!

Guess you like

Origin blog.51cto.com/14508648/2446247