Foreword
————
In replication, sometimes because of copy error, interrupted copy. Usually because a normal SQL statement is executed at the main library, but from synchronized to the library, for various reasons, can not find the corresponding data, resulting in the failure to execute SQL, replication errors reported. The following main wrote a few common mistakes.
Copy and process interruption
———————————————
Copy the interruption:
-
1062 Error: write the data from the library already exists. Appear more self-growth ID already exists.
-
Error 1032: appears less data, update from the library, when delete, find the corresponding record.
-
Other: The DDL operation error
Treatment of these conditions:
-
Encounter this problem, you should think of how to meet the copy, instead of skipping the transaction; not recommended to skip the error encountered error correction should be over, and then connect the main library copy, otherwise it will become increasingly inconsistent databases from!
-
Some repair manual operation slow, for 1062 and 1032 can be wrong, write a script automated monitoring correct.
-
Note: If the data is often inconsistent, choose low peak business period, a test data (pt-table-checksum), to see if the same data, checking out if too much data is inconsistent, that it is no longer available from the library, and then create a from the library!
Common replication error
———————————
[Error code -1062]
Processing operations:
-
Deal with this situation, needs and business negotiation, or the formation of a provision in the company, in which case what to do (in the deduplication database to put this supplement to or from the main library).
-
In general, its deletion of data from the library, so replication to continue.
-
Use pt-slave-restart to fix the problem, it will bypass the error, it is recommended to handle the error, it can ensure data consistency
To do:
-
Locate the thing
-
Traditional replication: Exec_Master_Log_Pos and middle last_error in end_log_pos affairs
-
GTID copy: executed_gtid_set: xxxxx: 1-5, that is, the first six being given transaction.
-
master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
-
Deletion of the article data on the slave, then connect copy
-
> Set sql_log_bin = 0; # to prohibit the operation record of the current session of written binlog
-
> delete from xn_db.t_order_produce where id=35197;
-
> Set sql_log_bin = 1; # normal
-
> Start slave sql_thread; # start the SQL thread
[Error code -1032]
1032 errors are divided into: update and delete erroneous error.
update processing operations:
-
Get out on the main library value (no specific recovered) primary key, as long as SQL can be executed successfully.
update do:
-
Locate the thing
-
Traditional replication: Exec_Master_Log_Pos and middle last_error in end_log_pos affairs
-
GTID copy: executed_gtid_set: xxxxx: 1-5, that is, the first six being given transaction.
-
master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
-
The data did not create it, just in line with the implementation of the transaction to a successful error
-
> set sql_log_bin=0;
-
> insert into xn_db.t_mes(id) values(35592);
-
> set sql_log_bin=1;
-
> start slave sql_thread;
delete processing operations:
-
In the absence of data from the database, resulting in deletion fails, you can skip this error, because the transaction is equivalent to skip the deletion does not execute the delete statement, and not before the execution from the library is the same, that data will not exist in from the library.
delete specific operations:
-
Traditional replication:
-
> stop slave;
-
> Set global sql_slave_skip_counter = 1; # skip a transaction
-
> start slave;
-
GTID copy:
-
> stop slave;
-
> Set gtid_net = 'xxxxx: 6' # 6 skip given transaction
-
> Begin; commit; # perform a Space Affairs, that GTID for the transaction 6
-
> set gtid_next='AUTOMATIC';