加入收藏 | 设为首页 | 会员中心 | 我要投稿 常州站长网 (https://www.0519zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 安全 > 正文

一条更新操作引起的MySQL主从复制异常

发布时间:2021-01-12 08:46:27 所属栏目:安全 来源:网络整理
导读:《一条更新操作引起的MySQL主从复制异常》要点: 本文介绍了一条更新操作引起的MySQL主从复制异常,希望对您有用。如果有疑问,可以联系我们。 一、环境描述 生产环境异地机房主从数据库,数据量过百G,数据库版本社区版本5.6.25. 二、问题描述 同事根据开发

《一条更新操作引起的MySQL主从复制异常》要点:
本文介绍了一条更新操作引起的MySQL主从复制异常,希望对您有用。如果有疑问,可以联系我们。

一、环境描述

生产环境异地机房主从数据库,数据量过百G,数据库版本社区版本5.6.25.

二、问题描述

同事根据开发提供的SQL在Master节点执行了一个大表的的全表更新操作,导致从节点Slave IO线程中断.

三、问题分析

1)相关参数

my.cnf中有两个参数设置:

expire_logs_days = 7????????#binlog保留时间7天
max_binlog_size = 1G??????#binlog大小

2)表大小,执行SQL

Table: v_clda?? 5.8G
Sql: update v_clda set uploadtime =now(); 主库执行成功

3)主库,大事物产生的binlog

-rw-rw—- 1 mysql mysql 1.1G Mar 16 02:49 mysql-bin.000159
-rw-rw—- 1 mysql mysql 8.0G Mar 16 15:28 mysql-bin.000160
-rw-rw—- 1 mysql mysql 7.4G Mar 16 18:13 mysql-bin.000161
-rw-rw—- 1 mysql mysql 1.1G Mar 16 23:55 mysql-bin.000162
-rw-rw—- 1 mysql mysql 1.1G Mar 17 12:15 mysql-bin.000163
-rw-rw—- 1 mysql mysql 1.1G Mar 18 16:54 mysql-bin.000164

4)异地从库报错

[ERROR] Slave I/O: Unexpected master’s heartbeat data: heartbeat is not compatible with local info;the event’s data:og_file_name mysql-bin.000160<90>ó°Y log_pos 121238917,Error_code: 1623
[ERROR] Slave I/O: Relay log write failure: could not queue event from master,Error_code: 1595
[Note] Slave I/O thread exiting,read up to log ‘mysql-bin.000160’,position 3626103968
[Note] Error reading relay log event: slave SQL thread was killed

Slave 已经无法同步数据.

一个事物只能写入一个binlog日志中,默认情况下,binlog日志达到设定值后(max_binlog_size),会自动生成一个新的日志文件,也会根据过期参数(expire_logs_days)设置自动删除binlog日志.如果生成了一个超大的binlog日志,很可能是由于大事物引起的.

尝试从启slave线程,多次尝试后失败.

尝试跳过事物,具体方法如下:

从节点执行(基于GTID)

stop slave;
SET @@SESSION.GTID_NEXT= ‘498815d6-20a9-11e6-a7d6-fa163e5770cc:53’; –根据实际情况
BEGIN; COMMIT;
SET SESSION GTID_NEXT = AUTOMATIC;
START SLAVE;
show slave statusG; 主从复制恢复正常

从节点执行更新操作,同步数据

set session sql_log_bin=0;
update v_clda set uploadtime =now();

在执行大事物前关闭 set session sql_log_bin=0; (默认是开启的),尤其是异地机房,网络带宽有限,而且VPN通道不是十分稳定的情况下.不允许它生成大量binlog日志.

如果像本例中,已经执行了,而且生成了大量的binlog,最终导致复制异常,可以考虑使用跳过事物的方法来解决这个问题.

最笨的方法就是重新搭建主从,由于数据量比较大,还是异地不可取.

根本解决方法还是要拆分大事物,进行批量提交操作.贺春旸老师的MySQL管理之道一书中第四章4.4节有具体的解决方法.

参考改为用存储过程,每删除10000条事务就提交一次,循环操作直至删除完毕.经过优化,行锁的范围变小了,性能也就变好了.相关代码如下:

DELIMITER ? $$
USE ? BIGDB$$
DROP ? PROCEDURE IF EXISTS BIG_table_delete_10k$$
CREATE ? PROCEDURE BIG_table_delete_10k(IN v_UserId INT)
BEGIN
del_10k:LOOP
delete ? from BIGDB.BIGTABLE where UserId = v_UserId limit 10000;
select ? row_count() into @count;
IF ? @count = 0 THEN
select CONCAT(‘BIGDB.BIGTABLE UserId = ? ‘,v_UserId,’ is ‘,@count,’ rows.’) as BIGTABLE_delete_finish;
LEAVE ? del_10k;
END IF;
select ? sleep(1);
END LOOP ? del_10k;
END$$
DELIMITER ? ;

作者:康壮 | 文章来源微信公众号:DBAplus社群

(编辑:常州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读