公司里有两个mysql服务器做主从同步,某天Nagios发来报警短信,mysqla is down...赶紧联系机房,机房的人反馈来的信息是 HARDWARE ERROR 后面信息省略,让机房记下错误信息后让他们帮忙重启下看是不是能正常起来,结果竟然正常起来了,赶紧导出所有数据。
问题又出现了,nagios 又报警,mysql_AB error,检查从库
show slave status \G; 果然
Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出现了1062错误,还提示
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)'
很显然,由于主库重启导致 从库数据不同步而且主键冲突。查看error 日志发现error日志文件变得好大,比以前大了将近好几倍,
tail -f mysql_error.log 最开始查看到的是这条信息
发现这条信息
[ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,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
报错和上面的意思差不多,
最先想到的就是首先手动同步一下,从库上首先 stop slave;停止同步
进入主库锁表,
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)
进入从库
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;
完成上面这些后
start slave;
回到主库
unlock tables; 解锁
回到从库 查看
show slave status \G;
发现正常了,长处了一口气。可是还没过一分钟,发现又开始报错了,还是最开始那个错误,这是怎么回事...
于是又想到了跳过错误的办法,(不过我不太喜欢用这种方法)马上进入从库
stop slave;
set global sql_slave_skip_counter=1; (1是指跳过一个错误)
slave start;
再show slave status \G;查看
还是报错 只不过 原来的 164761 变成了 165881,连续执行了几次后
除了上面的数值 在变,错误依然还在
郁闷了,看来只能先强制跳过 1062错误了,于是修改从库的/etc/my.cnf文件
在里面的[mysqld]下面加入了一行
slave-skip-errors = 1062 (忽略所有的1062错误)
重启下从库的mysql /etc/init.d/mysqld restart
再 show slave status \G;一下发现正常了,但是我知道这时的数据可能已经不同步了,
再次查看一下日志,让我感到意外的是tail -f mysql_error.log 出现大量的
.......
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
.........
日志里面有大量的这种警告,意思应该是statement 格式不安全,用vim 打开他看了一下,发现好多这类警告,我说为什么错误日志怎么变这么大了呢!!
statement format 应该是 binlog的一种格式,进入从库查看一下
show global variables like 'binlog_format';
果然当前的格式为statement
我需要把格式改为 mixed格式
修改从库的 my.cfg
在[mysqld]下面加入下面这行
binlog_format=mixed
然后重启mysql服务,发现错误日志里的 警告 都停止了。这回清静多了~~
我突然想起一件事,记得有朋友说过 RBR 模式可以解决很多因为主键冲突导致的主从无法同步情况,想到这里我就想要不要把 slave-skip-errors = 1062 去掉再试试,
于是就进入到my.cnf 里在注释掉了 slave-skip-errors = 1062
再次重新启动 mysql服务
进入从库
show slave status \G;
.........
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
........
恢复了!!!有观察了一段时间没有出现问题这才放心,
看来导致 mysql 主从复制出错的原因还真不少修复的办法也不止一个,binlog的格式也是其中之一。
希望遇到和这次一样问题的朋友看到这篇文章后会得到 一些启发和解决问题的方法~~
MYSQL主从同步故障一例及解决
转载上一篇:mysql主从同步复制的配置
下一篇:APACHE 安装出错 configure: error: Cannot use an external APR with the bundled APR-util
举报文章
请选择举报类型
内容侵权
涉嫌营销
内容抄袭
违法信息
其他
补充说明
0/200
上传截图
格式支持JPEG/PNG/JPG,图片不超过1.9M
相关文章
-
MySQL 主从同步:要求及配置
MySQL搭建主从同步有哪些要求,如何进行配置。
mysql 主从 复制 -
【MYSQL百炼成圣】水火不侵篇——主从同步
MYSQL数据库服务器主从同步设置,再也不用担心数据库崩坏了
数据库 java 服务器 主从同步 -
第02关 如何体系化掌握数据库?技术选型之数据库选型 基于 docker 搭建 mysql 主从
CSDN话题挑战赛第1期活动详情地址:https://marketing.csdn.net/p/bb5081d88a77db8d6ef45bb7b6ef3d7f参赛话题:如何体系化掌握数据库?话
数据库选型 如何体系化掌握数据库 mysql docker 关系型数据库 -
MySQL主从同步延迟原因及解决办法
MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从
服务器 sql 主从同步 -
MySQL 主从同步: 半同步
如何设置半同步
主从 同步 半同步 -
mysql主从同步(4)-Slave延迟状态监控
之前部署了mysql主从同步环境(Mysql主从同步(1)-主从/主主环境部署梳理)
sql mysql mysql主从 -
MySQL 主从同步:同步相关信息的存储及查询
如何查看MySQL主从复制相关的信息和状态
mysql 主从 复制 -
mysql主从是否同步检测脚本
mysql主从是否同步检测脚本
mysql mysql主从 mysql主从同步
圆圆圈圈 2011-09-15
芥末花生 2011-05-19