知识大全 MYSQL主从同步故障一例及解决过程

Posted 2022-04-11 知

篇首语：我们要像海绵一样吸收有用的知识。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 MYSQL主从同步故障一例及解决过程相关的知识，希望对你有一定的参考价值。

MYSQL主从同步故障一例及解决过程！ 以下文字资料是由(历史新知网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　公司里有两个mysql服务器做主从同步某天Nagios发来报警短信 mysqla is down 赶紧联系机房机房的人反馈来的信息是 HARDWARE ERROR 后面信息省略让机房记下错误信息后让他们帮忙重启下看是不是能正常起来结果竟然正常起来了赶紧导出所有数据

　　问题又出现了 nagios 又报警 mysql_AB error 检查从库

　　show slave status \\G; 果然

　　Slave_IO_Running: Yes

　　Slave_SQL_Running: No

　　而且出现了错误还提示

　　Last_SQL_Error: Error Duplicate entry for key PRIMARY on query Default database: bug Query: insert into misdata (uid mid pid state mtime) values ( )

　　很显然由于主库重启导致从库数据不同步而且主键冲突查看error 日志发现error日志文件变得好大比以前大了将近好几倍

　　tail f mysql_error log 最开始查看到的是这条信息

　　发现这条信息

　　[ERROR] Slave SQL: Error Duplicate entry for key PRIMARY on query Default database: ufo Query: insert into misdata (uid mid pid sta

　　te mtime) values ( ) Error_code:

　　 : : [Warning] Slave: Duplicate entry for key PRIMARY Error_code:

　　 : : [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

　　 position

　　报错和上面的意思差不多

　　最先想到的就是首先手动同步一下从库上首先 stop slave;停止同步

　　进入主库锁表

　　FLUSH TABLES WITH READ LOCK

　　mysql> show master status;

　　+ + + + +

　　+ + + + +

　　| ufo | | | |

　　+ + + + +

　　 row in set ( sec)

　　进入从库

　　mysql>change master to master_host= master_user= slave

　　master_password= xxx

　　master_port=

　　master_log_file= ufo

　　master_log_pos= ;

　　完成上面这些后

　　start slave;

　　回到主库

　　unlock tables; 解锁

　　回到从库查看

　　show slave status \\G;

　　发现正常了长处了一口气可是还没过一分钟发现又开始报错了还是最开始那个错误这是怎么回事

　　于是又想到了跳过错误的办法（不过我不太喜欢用这种方法）马上进入从库

　　stop slave;

　　set global sql_slave_skip_counter= ; （是指跳过一个错误）

　　slave start;

　　再show slave status \\G;查看

　　还是报错只不过原来的变成了连续执行了几次后

　　除了上面的数值在变错误依然还在

　　郁闷了看来只能先强制跳过错误了于是修改从库的/etc/f文件

　　在里面的[mysqld]下面加入了一行

　　slave skip errors = (忽略所有的错误)

　　重启下从库的mysql /etc/init d/mysqld restart

　　再 show slave status \\G;一下发现正常了但是我知道这时的数据可能已经不同步了

　　再次查看一下日志让我感到意外的是tail f mysql_error log 出现大量的

　　 : : [Warning] Statement may not be safe to log in statement format Statement: delete from `system_message_ ` where `to_uid` = ORDER BY `id` ASC LIMIT

　　日志里面有大量的这种警告意思应该是statement 格式不安全用vim 打开他看了一下发现好多这类警告我说为什么错误日志怎么变这么大了呢！！

　　statement format 应该是 binlog的一种格式进入从库查看一下

　　show global variables like binlog_format ;

　　果然当前的格式为statement

　　我需要把格式改为 mixed格式

　　修改从库的 my cfg

　　在[mysqld]下面加入下面这行

　　binlog_format=mixed

　　然后重启mysql服务发现错误日志里的警告都停止了这回清静多了~~

　　我突然想起一件事记得有朋友说过 RBR 模式可以解决很多因为主键冲突导致的主从无法同步情况想到这里我就想要不要把 slave skip errors = 去掉再试试

　　于是就进入到f 里在注释掉了 slave skip errors =

　　再次重新启动 mysql服务

　　进入从库

　　show slave status \\G;

　　Slave_IO_Running: Yes

　　Slave_SQL_Running: Yes

　　恢复了！！！有观察了一段时间没有出现问题这才放心

　　看来导致 mysql 主从复制出错的原因还真不少修复的办法也不止一个 binlog的格式也是其中之一

cha138/Article/program/MySQL/201311/29391