mysql alter 同步_MySQL主从同步的一个小问题解决

由于历史遗留问题,我们的MySQL主从库的表结构不一致,主库的某个表tableA比从库表tableA少了一个字段。

当尝试在主库上更改表结构时,这行alter语句会随着binlog同步到从库,如果从库执行这行语句时出错,主从同步线程就会自动停止,那样只能人为手动处理错误,然后再启动slave上的主从同步线程。场景大概是下面这个样子:

1,在主库上执行alter table aaa add column xxx int default 1  after yyy;

2,从库同时也会执行这样语句,但是由于从库上已经有xxx这个字段了,于是主从线程更改表失败,这个时候用show slave status查看主从状态就会发现类似于下面这样的语句:

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 1060

Last_Error: Error 'Duplicate column name 'xxx'' on query. Default database: 'dbxxx'. Query: 'alter table aaa add column xxx int default 1 after yyy'

//此处省略了一些语句

Last_SQL_Errno: 1060

Last_SQL_Error: Error 'Duplicate column name 'xxx'' on query. Default database: 'dbxxx'. Query: 'alter table aaa add column xxx int default 1 after yyy'

可以看到,从主库复制binlog的salve_io线程还在忙活,但是执行从库更新的slave_sql已经罢工了,从Last_error:可以看到是因为执行主库中国来的alter table aaa add column xxx int default 1 after yyy时出错了,具体原因是这个表上已经有了xxx这一列。

手动的解决方法是告诉从库slave_sql线程让他忽略掉这个错误继续执行:

mysql>set global sql_slave_skip_counter=1;

mysql>start slave;

上面的语句是告诉slave跳过当前卡住的event,然后重新起来干活。

上面的方法在slave比较少的时候还可以,但是当从库有几十台时,逐台去处理既费时又容易出错,怎样在主库这一侧一劳永逸地避免呢?

对,就是在主库这侧不要将这样alter这样语句写入到binlog中,MySQL不愧世界级的软件产品,它提供了一个session粒度的选项,通过关闭这个选项可以不让主库将打开这个选项或关闭连接前的SQL语句写入binlog。

mysql>set sql_log_bin=off;

mysql>alter table aaa add column xxx int default 1 after yyy;

是不是很方便呢?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL主从延迟问题是数据库运维中经常遇到的问题之一,通常会引起应用程序性能下降或者数据不一致的问题。下面我们来介绍一下如何排查MySQL主从延迟问题。 1. 确认主从复制的状态 首先需要确认主从复制的状态。可以通过以下命令查看: ``` SHOW SLAVE STATUS \G; ``` 在输出结果中,需要关注以下几个参数: - Slave_IO_Running:表示Slave I/O线程是否正在运行,如果为YES,则正常运行,否则需要检查错误日志; - Slave_SQL_Running:表示Slave SQL线程是否正在运行,如果为YES,则正常运行,否则需要检查错误日志; - Seconds_Behind_Master:表示从库落后主库的时间,如果为0,则表示主从同步正常。 2. 确认网络延迟 如果主从复制状态正常,但是Seconds_Behind_Master不为0,那么需要确认网络延迟是否存在。可以通过在主库和从库上分别执行以下命令进行测试: 在主库执行: ``` SELECT NOW(); ``` 在从库执行: ``` SELECT NOW(); ``` 比较两个输出结果的时间差,即可得到主从复制的网络延迟时间。如果网络延迟较大,可以考虑优化网络连接或者将主从库部署在同一地域内。 3. 检查主从库配置 如果网络延迟不存在,那么需要检查主从库的配置是否正确。可以比较主从库的以下参数是否一致: - server_id:表示服务器的ID,主从库必须不同; - log_bin:表示二进制日志文件名称,主库必须开启二进制日志; - binlog_format:表示二进制日志格式,主库必须开启ROW格式; - replicate_do_db:表示从库需要复制的数据库,如果设置了该参数,则只复制该数据库; - replicate_ignore_db:表示从库忽略复制的数据库,如果设置了该参数,则不复制该数据库。 4. 检查主从库版本 如果主从库配置正确,但是主从延迟问题依然存在,那么需要检查主从库的版本是否一致。主从库的版本必须一致,否则会出现主从延迟的问题。 5. 总结 通过以上步骤,可以排查MySQL主从延迟问题。在实际运维过程中,还可以通过监控工具对主从库的状态进行实时监控,及时发现主从延迟问题,并进行处理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值