MySQL多线程复制遇到Error_code: 1872的解决方案

上周在生产环境上遇到一个问题,不敢独享,拿出来给小伙伴们做个简单的分享。

起因 :由于IDC机房断电(估计又是哪里被挖掘机碰了下吧),导致所有服务器重启,影响到了其中的MySQL数据库。来看下这时数据库遇到的问题:

数据库版本 :MySQL 5.7.10

问题表现

:从机复制报如下错误:Slave SQL for channel ”: Slave failed to initialize relay log info structure from the repository, Error_code: 1872

用了Inside君的MySQL标准配置文件模板,怎么没有实现crash safe呢?其实,这主要是因为多线程复制(MTS)所引起。不知MySQL 5.7,即使MySQL 5.6也同样会遇到问题。

在MTS场景下,可能会出现以下两个问题:

gap事务:后执行的事务先回放(apply)了
Exec_Master_Log_Pos位置不准确:可能存在已经事务已经提交,但是位置还没更新(单线程复制不存在此问题)
gap事务比较好理解,因为不论是基于database级别的MTS,还是基于logical_clock的MTS,都可能存在下面的这种场景:

由于MTS的原因,后面的事务可能比前面的事务早执行,如上图终可能事务tx2和tx4都已经提交了,但是事务tx1和tx3还未提交。这时就称为存在gap事务。在基于logical_clock的MTS场景下,用户可以通过配置 参数slave_preserve_commit_order=1 来保证提交的顺序性。

另一方面,这时Exec_Master_Log_Pos也是不准确的,当发生crash时,master info中依然记录的是tx1事务开始执行的位置(见上图右边的部分)。切记,即使将参数slave_preserve_commit_order设置为1,MTS场景下依然不能保证Exec_Master_Log_Pos是准确的,其称之为 gap-free low-watermark 。因为MTS场景下对于表slave_realy_info_log的更新并不是事务的(这个需要好好体会下)。

然而,MTS场景下引入了新的事务表slave_worker_info,用以表示发生宕机时每个线程更新到的位置,其与Worker线程的回放是事务的。因此,MySQL在恢复的时候可以通过通过Exec_Master_Log_Pos与表slave_worker_info的列Master_log_pos做对比,判断是否需要回放当前事务。

在MySQL 5.7.13版本之前,当发生宕机后需要手动执行如下操作,若直接执行CHANGE MASTER TO操作,则可能会触发上述1872错误:

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
START SLAVE SQL_THREAD;

由于服务器上的MySQL版本为5.7.10,而DBA试图通过命令CHANGE MASTER TO来修复复制问题,因此导致了上述问题。而在MySQL 5.7.13版本后,上述问题将有MySQL自动修复。简单来说,即使发生了宕机,也能准确并自动地恢复复制的运行状态。

不过,当Inside升级到MySQL 5.7.15过程时,又遇到了一个不大不小的坑,这个就留着等下回分享吧。

(0)

相关推荐

  • MySQL截取和拆分字符串函数用法示例

    本文实例讲述了MySQL截取和拆分字符串函数用法.分享给大家供大家参考,具体如下: 首先说截取字符串函数: SUBSTRING(commentid,9) 这个很简单,从第9个字符开始截取到最后.SUBSTRING的参数有三个,最后一个是截取的长度,默认是到结尾,负数是倒数第几位. 接着说拆分字符串函数: SUBSTRING_INDEX(commentid, '-', 1) 这个就稍稍复杂一些了,他的意思是以 - 进行拆分字符串,从第一个关键词开始取前面所有的字符串.如果上面的第三个参数修改为 -

  • php mysql连接数据库实例

    小插曲,晚上把数据的my.ini编码改为utf-8,然后数据库一直不能启动,改回gbk就可以,有知道的告知下问题所在. 因为是链接数据库,也没什么好说明的,直接上代码吧. <?php /* Connect to a MySQL server 连接数据库服务器 */ $link = mysqli_connect( 'localhost', /* The host to connect to 连接MySQL地址 */ 'jian', /* The user to connect as 连接MySQL

  • mysql #1062 –Duplicate entry '1' for key 'PRIMARY'

    近日一直在折腾vps ,刚刚碰到在搬移wordpress过程中导入数据库的时候.碰到了 #1062 – Duplicate entry '1′ for key 'PRIMARY' 当时那个急啊,原本的数据我已经全部删除了,没办法只有请求万能的百度了.我找了大半天终于给我给我找到了.兴奋ing,马上测试,O(∩_∩)O哈哈~成功了. 现在附上解决办法只要把原来的老数据清空导入就可以了. 原理我不明白,贴上来你们自己看吧.反正达到目的就ok了. "提示#1062 – Duplicate entry

  • mysql 复制表结构和数据实例代码

    在mysql数据库开发中,我们有时候需要复制或拷贝一张表结构和数据到例外一张表,这个时候我们可以使用create ... select ... from语句来实现,本文章向大家介绍mysql复制表结构和数据一个简单实例, 比如现在有一张表,我们要将该表复制一份,以备以后使用,那么如何使用mysql语句来实现呢?其实我们可以直接使用create ... select ... from语句来实现,具体实现方法请看下面实例. 我们先来创建一张Topic表,创建Topic表的SQL语句如下: mysql

  • JDBC 连接MySQL实例详解

    JDBC连接MySQL JDBC连接MySQL 加载及注册JDBC驱动程序 Class.forName("com.mysql.jdbc.Driver"); Class.forName("com.mysql.jdbc.Driver").newInstance(); JDBC URL 定义驱动程序与数据源之间的连接 标准语法: <protocol(主要通讯协议)>:<subprotocol(次要通讯协议,即驱动程序名称)>:<data so

  • PHP读MYSQL中文乱码的快速解决方法

    打算切换某个网站的主机,没想到遇到Php和Mysql中文乱码的问题. 以前的国外主机用的Mysql是4.x系列的,感觉还比较好,都无论GBK和UTF-8都没有乱码,没想到新的主机的Mysql是5.0版本的,导入数据后,用Php读出来全是问号,乱码一片,记得我以前也曾经有过一次切换出现乱码的经验,原因肯定是Mysql版本之间的差异问题. 只好查资料,发现了一个解决方法,就是在mysql_connect后面加一句SET NAMES UTF8,即可使得UTF8的数据库消除乱码,对于GBK的数据库则使用

  • MySQL里Create Index 能否创建主键 Primary Key

    MySQL里Create Index 能否创建主键 Primary Key? 答案: 不能,必须用 Alter table 创建. MySQL一个索引列最大允许的有效长度,不是列的所有数据都被索引的 MyISAM 是 1000字节 InnoDB 是 767 字节 注意这里是字节.

  • mysql中key 、primary key 、unique key 与index区别

    mysql中索引是非常重要的知识点,相比其他的知识点,索引更难掌握,并且mysql中的索引种类也有很多,比如primary key .unique key 与index等等,本文章向大家介绍mysql中key .primary key .unique key 与index区别.  一.key与primary key区别 CREATE TABLE wh_logrecord ( logrecord_id int(11) NOT NULL auto_increment, user_name varch

  • Mysql5.6启动内存占用过高解决方案

    vps的内存为512M,安装好nginx,php等启动起来,mysql死活启动不起来看了日志只看到对应pid被结束了,后跟踪看发现是内存不足被killed; 调整my.cnf 参数,重新配置(系统默认配置太高直接占用400M内存,小玩家玩不起呢)即可 performance_schema_max_table_instances=200 table_definition_cache=200 table_open_cache=128 下面附一个相关的my.cnf配置文件的说明 [client] po

  • 简单分析MySQL中的primary key功能

    在5.1.46中优化器在对primary key的选择上做了一点改动: Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be pref

  • 简单谈谈MySQL中的int(m)

    我们在设计表的时候,如果碰到需要设置int(整型)的时候,通常会按照惯例(大家都这样写)设置成int(11).那么这里为什么是11呢?代表的又是什么呢? 以前我一直以为这里是在限制int显示的宽度,后来仔细研究和通过上网查询发现,事实并不是那样的. 确切的来说,这里的"宽度"只是一个"预期值",它所代表的仅仅是你在设计数据表结构时,想让该列日后显示的值宽度为多少,但是具体存入值的宽度多少不会受任何影响. 当然,它的作用不仅如此,在存入数据的时候,还是有一定区别的,这

随机推荐