数据库

位置:IT落伍者 >> 数据库 >> 浏览文章

MYSQL主从同步故障一例及解决过程!


发布日期:2024年04月19日
 
MYSQL主从同步故障一例及解决过程!

公司里有两个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 (uidmidpidstatemtime) values ()

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

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

发现这条信息

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

temtime) 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;

+++++

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+++++

| 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]下面加入了一行

slaveskiperrors = (忽略所有的错误)

重启下从库的mysql /etc/initd/mysqld restart

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

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

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

修改从库的 mycfg

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

binlog_format=mixed

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

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

于是就进入到f 里在注释掉了 slaveskiperrors =

再次重新启动 mysql服务

进入从库

show slave status \G;

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

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

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

希望遇到和这次一样问题的朋友看到这篇文章后会得到 一些启发和解决问题的方法~~

               

上一篇:MySQL 存取权限系统

下一篇:Linux下MySQL的管理与配置