第一种情况,开启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. Linux MBR扇区误删恢复

    目录 1. 引导记录误删恢复 1.1 备份引导记录 1.2 误删引导记录 1.3 恢复引导记录 2. 分区表误删恢复 2.1 备份分区表 2.2 误删分区表 2.3 恢复分区表 如果MBR分区表没了, ...

  2. 前端组件化Polymer入门教程(2)——Hello world

    本节为体验篇,就是让你了解它有哪些功能,不做详细说明,后面再来讲细节. 自定义元素 组件页 <link rel="import" href="../polymer- ...

  3. java web 中 filter 与 servlet的关系

    过滤器的转载顺序是服务器按照we.xml文件中定义的顺序从后往先的顺序转载的,而过滤的顺序就是按照先后顺序过滤的,而销毁也是从后往先销毁的.

  4. Centos下安装最新版Mono并为windwos服务配置开机启动项

    一:安装Mono,此步骤参照官网 1:配置Yum仓库 #Centos 7yum install yum-utils rpm --import "http://keyserver.ubuntu ...

  5. FFmpeg在JAVA中的使用-音频提取&字幕压缩

    由于项目需求中涉及到视频中音频提取,以及字幕压缩的功能,一直在研究ffmpeg,仅仅两个功能,却深受ffmpeg的折磨. 今天谈谈ffmpeg在java中的简单使用,首先下载FFmpeg包,官方地址: ...

  6. switch-case最容易忽视的一点

    switch语句是常用的一种java语法,但是往往最基本的,总是最容易被人们忽略. 首先,看下switch语句的基本结构: switch(表达式){ case 常量1: 语句1; break; cas ...

  7. SQLServer之视图篇

    1 视图介绍          视图是从一个或者几个基本表(或视图)导出的表.它与基本表不同,是一个虚表.数据库中只存放视图的定义,而不存在视图对应的数据,这些数据仍然存放在原来的基本表中.所以一旦基 ...

  8. [日常] Go语言圣经-匿名函数习题

    Go语言圣经-匿名函数1.拥有函数名的函数只能在包级语法块中被声明,通过函数字面量(function literal),我们可绕过这一限制,在任何表达式中表示一个函数值2.通过这种方式定义的函数可以访 ...

  9. Re0:从零学习node.js

    起小项目 express xxx 镜像 npm install npm install npm start 创建自己的端口...

  10. JVM 堆内存和非堆内存

    转载自:http://www.importnew.com/27645.html 堆和非堆内存 按照官方的说法:“Java 虚拟机具有一个堆(Heap),堆是运行时数据区域,所有类实例和数组的内存均从此 ...