MySQL recently encountered a synchronization problem, and now tidy up the frequently encountered error resolution, backup.
Method One: Manually set the dynamic parameter Sql_slave_skip_counter
My usual scripts:
Stop slave sql_thread;set global sql_slave_skip_counter=1;start slave sql_thread;
This is determined according to the specific error, generally used for primary key conflict or update failure error, to manually skip.
Method Two: Static server settings, need to restart MySQL
[Mysqld]
slave_skip_errors=1032,1064
After restarting MySQL, the configuration file is automatically loaded, the synchronization automatically skips the update, and the primary key conflicts with the error.
Parameter description:
Normally, replication stops when a error occurs on the slave.
This gives your opportunity to resolve the inconsistency in the data manually.
This variable tells the slave SQL thread to continue replication if a statement returns any of the errors listed in the Variable value.
Method Three: Dynamically set skip Errors
Slave_exec_mode
This is more ruthless.
Set global Slave_exec_mode =strict;
Enforce policies strictly. In most cases, errors are encountered and synchronization is terminated. Wait for the error to resolve.
Set global Slave_exec_mode =idempotent;
This setting allows synchronization to be skipped
Duplicate-key and No-key-found errors
Parameter description:
Controls whether idempotent or STRICT mode is used in replication conflict resolution and error checking.
Idempotent mode causes suppression of some errors, including Duplicate-key and no-key-found errors. Beginning with MySQL 5.1.23-ndb-6.2.14 and MySQL 5.1.24, this mode should is employed in multi-master replication, Circula R replication, and some other special replication scenarios.
STRICT mode is the default, and was suitable for most other cases
MySQL Skip Sync Error method