第一种情况,开启GTID,从库与主库不同步。

1、在从库上查看从的状态

 
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.120.141.168
Master_User: sys_repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 4
。。。。。。。。
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
。。。。。。
Retrieved_Gtid_Set: 79212d47-7122-11e7-8641-0050569f788a:13579-17760
Executed_Gtid_Set: 07cfd8f2-b30c-11e7-8909-000d3a80115c:1-7,
635227c2-af6c-11e8-a447-5254003471ec:1-297,
66d902a5-b546-11e7-b1d4-000d3a80115c:1-13,
79212d47-7122-11e7-8641-0050569f788a:1-17760,
9d5436f6-7122-11e7-8e0c-0050569f19f6:1-6
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
 

结果报1236的错误,再从主库上查看下主库的状态

 
 mysql> show master status \G
*************************** 1. row ***************************
File: mysql-bin.000480
Position: 10751
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 07cfd8f2-b30c-11e7-8909-000d3a80115c:1-7,
635227c2-af6c-11e8-a447-5254003471ec:1-297,
66d902a5-b546-11e7-b1d4-000d3a80115c:1-13,
79212d47-7122-11e7-8641-0050569f788a:1-17797,
9d5436f6-7122-11e7-8e0c-0050569f19f6:1-6,
ac29dfbf-aa66-11e8-9d1e-5254003471ec:1
1 row in set (0.00 sec) mysql> show variables like '%gtid_purged%';
+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| gtid_purged | 07cfd8f2-b30c-11e7-8909-000d3a80115c:1-7,
635227c2-af6c-11e8-a447-5254003471ec:1-297,
66d902a5-b546-11e7-b1d4-000d3a80115c:1-13,
79212d47-7122-11e7-8641-0050569f788a:1-15338,
9d5436f6-7122-11e7-8e0c-0050569f19f6:1-6,
ac29dfbf-aa66-11e8-9d1e-5254003471ec:1 |
+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
 

发现有一个GTID从库还没有跑,主库就把这个GTID purged掉了,由于从库没有业务在跑,属于备份库,所以我索性直接

 
mysql> stop slave;
mysql> reset master; mysql> set global gtid_purged = '07cfd8f2-b30c-11e7-8909-000d3a80115c:1-7,
'> 635227c2-af6c-11e8-a447-5254003471ec:1-297,
'> 66d902a5-b546-11e7-b1d4-000d3a80115c:1-13,
'> 79212d47-7122-11e7-8641-0050569f788a:1-15223,
'> 9d5436f6-7122-11e7-8e0c-0050569f19f6:1-6,
'> ac29dfbf-aa66-11e8-9d1e-5254003471ec:1'; #主库的gtid_purged#
mysql> change master to master_host='10.120.141.136',master_user='sys_replication',master_password='x!Jkz@SIe',master_port=3306,master_auto_position=1;
mysql> start slave;
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.120.141.136
Master_User: sys_replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000480
Read_Master_Log_Pos: 10272
Relay_Log_File: mysqld-relay-bin.000034
Relay_Log_Pos: 10285
Relay_Master_Log_File: mysql-bin.000480
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 10272
Relay_Log_Space: 10580
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 141135
Master_UUID: 79212d47-7122-11e7-8641-0050569f788a
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 79212d47-7122-11e7-8641-0050569f788a:15224-17793
Executed_Gtid_Set: 07cfd8f2-b30c-11e7-8909-000d3a80115c:1-7,
635227c2-af6c-11e8-a447-5254003471ec:1-297,
66d902a5-b546-11e7-b1d4-000d3a80115c:1-13,
79212d47-7122-11e7-8641-0050569f788a:1-17793,
9d5436f6-7122-11e7-8e0c-0050569f19f6:1-6,
ac29dfbf-aa66-11e8-9d1e-5254003471ec:1
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
 

总结:

从库在开始同步前,主库会依靠GTID来确认从库在开始同步以后, 能够把每一个主库上执行过的事务(包括slave的SQL Thread)都复现一次,最终保持和主库完全一致;
判断方法也很简单,基本基于两个条件:
1.主库不能purge从库还没有execute的事务(即从库的executed_GTID要大于主库的GTID_Purged);
2.主库上的事务号不能低于从库(即从库的executed_GTID的最后一个事务要在主库的executed_GTID的范围之内);

2、 构架为双主(一主一从,且互为主从),业务和应用在主库上跑,从库做备份,基本没有业务和应用。

从库(s)指向主库(m)时连接良好,主库(m)指向从库(s)时报错1236。

 
mysql> show slave status \G  #主库(m)状态
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.120.141.168
Master_User: sys_repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 154
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 141168
Master_UUID: 055a9521-4906-11e8-8cdb-0050569f3621
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 181119 14:27:58
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 055a9521-4906-11e8-8cdb-0050569f3621:1-164859,
2f7211a3-fba0-11e5-b668-0050569f3621:1-627,
30d4f3f6-b56b-11e7-acf1-000d3a801c2f:1-14,
375942c7-0723-11e6-b55c-0050569f3621:1-16630,
61edd40b-af6c-11e8-a4f6-525400adeb6d:1-5059,
971844d6-d7ca-11e6-8d01-0050569f6058:1-11929269,
d408633e-fb9f-11e5-8de2-0050569f6058:1-1317354
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
 

再看从库(s)的gtid_purged

 
mysql> show variables like '%gtid%purged%'\G
*************************** 1. row ***************************
Variable_name: gtid_purged
Value: 055a9521-4906-11e8-8cdb-0050569f3621:1-157766,
2f7211a3-fba0-11e5-b668-0050569f3621:1-627,
30d4f3f6-b56b-11e7-acf1-000d3a801c2f:1-14,
375942c7-0723-11e6-b55c-0050569f3621:1-16633,
971844d6-d7ca-11e6-8d01-0050569f6058:1-9581086,
d408633e-fb9f-11e5-8de2-0050569f6058:1-1317354
1 row in set (0.00 sec)
 

发现由于从库(s)的 gtid_purged大于主库(m)的Executed_Gtid  #从库指向主库的结构已经搭建完成,现在是搭建主库指向从库时报错,即当前主是从#

根据之前总结的规则,主库(s)不能purge从库(m)还没有execute的事务(即从库(m)的executed_GTID要大于主库(s)的GTID_Purged)

所以会报1236的错误。由于主库(m)上还有业务和应用在跑,所以不能生硬的reset master,所以只能想办法把execunt gtid追回来,

我的方法是跳过这三个事务(不是唯一解法,如果差的事务号过多,这个办法就很愚蠢,在这个构架下出现这种错误很有可能在从库上有应用执行过事务,

如果从库执行的事务太多,那就要查查原因了)

 
stop slave;
set gtid_next='375942c7-0723-11e6-b55c-0050569f3621:16631'; --指定下一个事务执行的版本,即想要跳过的GTID
begin;
commit; --注入一个空事物
set gtid_next='375942c7-0723-11e6-b55c-0050569f3621:16632';
begin;
commit;
set gtid_next='375942c7-0723-11e6-b55c-0050569f3621:16633';
begin;
commit; set gtid_next='AUTOMATIC'; --自动的寻找GTID事务。 start slave; --开始同步 mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.120.141.168
Master_User: sys_repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 185245755
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 414
Relay_Master_Log_File: mysql-bin.000026
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 185245755
Relay_Log_Space: 622
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 141168
Master_UUID: 055a9521-4906-11e8-8cdb-0050569f3621
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 055a9521-4906-11e8-8cdb-0050569f3621:1-164859,
2f7211a3-fba0-11e5-b668-0050569f3621:1-627,
30d4f3f6-b56b-11e7-acf1-000d3a801c2f:1-14,
375942c7-0723-11e6-b55c-0050569f3621:1-16633,
61edd40b-af6c-11e8-a4f6-525400adeb6d:1-5059,
971844d6-d7ca-11e6-8d01-0050569f6058:1-11929305,
d408633e-fb9f-11e5-8de2-0050569f6058:1-1317354
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
 

这样就好了。

mysql主从不同步问题 Error_code: 1236的更多相关文章

  1. mysql主从不同步问题 Error_code: 1197

    首先查看从的状态   mysql> show slave status \G *************************** 1. row *********************** ...

  2. MySQL主从数据库同步延迟问题解决(转)

    最近在做MySQL主从数据库同步测试,发现了一些问题,其中主从同步延迟问题是其中之一,下面内容是从网上找到的一些讲解,记录下来以便自己学习: MySQL的主从同步是一个很成熟的架构,优点为:①在从服务 ...

  3. 配置MySQL主从双向同步

    原文地址:http://www.cnblogs.com/zhongshengzhen/ 原主数据库:192.168.137.33 原从数据库:192.168.137.197   需要先阅读并操作:ht ...

  4. MYSQL主从库同步配置过程

    MYSQL主从库同步配置过程 为了实现网站数据库的异地备份,采用了MySQL数据库主从同步配置,需要两台服务器分别作为主从库,当主库发生增删改等操作,会实时反映到从库,我的个人服务器配置如下: 主库为 ...

  5. Centos 配置 Mysql 主从双向同步

    配置之前,请先阅读mysql主从复制: Mysql-主从复制 原:  主从环境: 主服务器:192.168.153.130 从服务器:192.168.153.131 1.从数据库创建同步用户,将主数据 ...

  6. mysql主从不同步处理过程分享

    背景  8月7日15:58收到报障数据库出现不同步:数据库共四台,分别为10.255.70.11,10.255.70.12,10.255.70.13,10.255.70.14(ip为虚拟ip) 数据库 ...

  7. 使用Percona Toolkit解决Mysql主从不同步问题【备忘】

    由于各种原因,mysql主从架构经常会出现数据不一致的情况出现,大致归结为如下几类 1:备库写数据 2:执行non-deterministic query 3:回滚掺杂事务表和非事务表的事务 4:bi ...

  8. mysql 主从 重新同步

    mysql 主从同步一担出了问题之后,就会导致从库上的数据和主库不一样了.所以需要生新同步数据. 1.登录主库服务器,进入mysql,命令为:mysql -uroot -ppassword 2.执行: ...

  9. 解决mysql 主从数据库同步不一致的方法

    接着上文 配置完Mysql 主从之后,在使用中可能会出现主从同步失败的情况. mysql> show slave status\G Slave_IO_Running: Yes Slave_SQL ...

随机推荐

  1. SkipList 跳跃表

    引子 考虑一个有序表:14->->34->->50->->66->72 从该有序表中搜索元素 < 23, 43, 59 > ,需要比较的次数分别为 ...

  2. tsung压力测试——Tsung测试统计报告说明【转】

    1.主要统计信息 Tsung统计数据是平均每十秒重置一次,所以这里的响应时间(连接.请求.页面.会话)是指每十秒的平均响应时间: connect: 表示 每个连接持续时间: Hightest 10se ...

  3. MongoDB学习3 $操作符表达式大全及实例

    from : http://blog.csdn.net/qq_16313365/article/details/58599253 1.查询和投影   1.1 比较操作符 $eq 语法:{ <fi ...

  4. Java 容器源码分析之1.8HashMap方法讲解

    前言:Java8之后新增挺多新东西,在网上找了些相关资料,关于HashMap在自己被血虐之后痛定思痛决定整理一下相关知识方便自己看.图和有些内容参考的这个文章:http://www.importnew ...

  5. 【IT笔试面试题整理】有序数组生成最小高度二叉树

    [试题描述]定义一个函数,输入一个有序数组生成最小高度二叉树 We will try to create a binary tree such that for each node, the numb ...

  6. Spring 通过Java代码装配bean

    1. 背景 书接上文Spring自动化装配bean 尽管在很多场景下通过组件扫描和自动装配实现Spring的自动化扫描配置是更为推荐的方式,但在有些情况下自动化扫描的方案行不通,如想要将第三方库中的组 ...

  7. Redhat6.8下安装Oracle11gR2

    Step1.配置本地yum源,方便安装依赖包 df -h 补充: df命令查看 linux系统磁盘空间以及使用情况,-h代表方便阅读方式显示  :/dev/sr0为光驱设备名 mkdir cdrom ...

  8. Travelling Fee(Dijlstra——最短路问题变型)

    题目链接: http://acm.zju.edu.cn/onlinejudge/showProblem.do?problemCode=2027 题目: Samball is going to trav ...

  9. V8源码边缘试探-黑魔法指针偏移

    这博客是越来越难写了,参考资料少,难度又高,看到什么写什么吧! 众多周知,在JavaScript中有几个基本类型,包括字符串.数字.布尔.null.undefined.Symbol,其中大部分都可以在 ...

  10. [转]Magento2开发教程 - 如何向数据库添加新表

    本文转自:https://www.cnblogs.com/xz-src/p/6920365.html Magento 2具有特殊的机制,允许你创建数据库表,修改现有的,甚至添加一些数据到他们(如安装数 ...