| There are two mysql servers in the company for master-slave synchronization. One day, Nagios sent an alarm text message, mysqla is down ... hurry up and contact the computer room. The information returned by the people in the computer room is that the information behind HARDWARE ERROR is omitted. Let the computer room write down the error message. Ask them to help restart to see if it can be normal, and it turns out to be normal, and quickly export all the data.
The problem appeared again, nagios alarmed again, mysql_AB error, check the slave library
show slave status /G; sure enough
Slave_IO_Running: Yes
Slave_SQL_Running: No
and 1062 errors occurred, and also prompted
Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)
' The restart of the master database causes the data of the slave database to be out of sync and the primary key conflicts. Looking at the error log, I found that the error log file has become very large, nearly several times larger than before. The
tail -f mysql_error.log first saw this information.
Found this information
[ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,state
,mtime ) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17: 39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296 The
error is similar to the above,
The first thing that comes to mind is to manually synchronize first, stop slave on the slave library first; stop synchronization
and enter the master library lock table,
FLUSH TABLES WITH READ LOCK;
mysql> show master status;
+-------------------+-------------+--------------+-- ----------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+--- --------+-------------+------------------+
| ufo.000063 | 159164526 | | |
+-------------------+-------------+-------------+ ------------------+
1 row in set (0.00 sec)
into the slave library
mysql>change master to master_host='192.168.1.141', master_user='slave',
master_password ='xxx',
master_port=3306,
master_log_file='ufo.000063',
master_log_pos=159164526;
after completing the above,
start slave;
go back to the master library to
unlock tables; unlock and
go back to the slave library to view
show slave status /G;
I found that it was normal, and my strengths took a sigh of relief. But not a minute later, I found that the error started to be reported again, and it was the same error at the beginning. What's going on...
So I thought of a way to skip the error, (but I don't like this method very much) and enter immediately Slave
stop slave;
set global sql_slave_skip_counter=1; (1 means skipping an error)
slave start;
then show slave status /G ; check
and still report an error, but the original 164761 has become 165881, after several consecutive executions,
except The above values are changing, and the error is still there. I am
depressed. It seems that I can only forcefully skip the 1062 error first, so I modified the /etc/my.cnf file of the slave library and added a line of slave-skip
under [mysqld].
-errors = 1062 (ignore all 1062 errors) restart mysql /etc/init.d/mysqld restart
of the slave library and then show slave status /G; I found that it is normal, but I know that the data may be out of sync at this time , looking at the log again, what surprised me is that tail -f mysql_error.log shows a lot of ......
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1
.........
There are a lot of such warnings in the log, which means that the statement format is not safe. He opened it with vim and found a lot of such warnings. I said why the error log has become so big! !
The statement format should be a format of binlog, enter the slave library to check
show global variables like 'binlog_format';
sure enough, the current format is statement
, I need to change the format to mixed format ,
modify the my.cfg of the slave library and add it under
[ mysqld] The following line
binlog_format=mixed
and then restart the mysql service, and found that the warnings in the error log have stopped. This time it is much quieter~~
I suddenly remembered one thing, I remember a friend said that the RBR mode can solve many master-slave synchronization problems caused by primary key conflicts. Thinking of this, I want to put slave-skip-errors = 1062 remove it and try again.
So I went to my.cnf and commented out slave-skip-errors = 1062
and restarted the mysql service again.
Enter the slave library
show slave status /G;
.........
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.. ...
restored! ! ! After observing for a period of time, I can rest assured that there is no problem.
It seems that there are many reasons for the error of mysql master-slave replication, and there are more than one way to fix it, and the format of binlog is also one of them.
I hope that friends who encounter the same problem as this time will get some inspiration and solutions to the problem after reading this article~~ |