Question

我想在启用GTID的情况下为Percona Server创建副本，但在显示slave状态时出现此错误：

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.'

通常，我会停止我的奴隶，重置它，重置主机（在从机上），并从主机获取新的GTID_PURGED值。但这一次，主人有一个非常不寻常的价值，我不知道如何确定使用哪一个：

mysql> show master status\G
*************************** 1. row ***************************
             File: mysqld-bin.000283
         Position: 316137263
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667
1 row in set (0.00 sec)

来自带有新备份副本的奴隶，我得到了这个：

root@ubuntu:/var/lib/mysql# cat xtrabackup_binlog_info
mysqld-bin.000283       294922064       1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960

还有一件事，我在备份前清除了主服务器上的二进制日志。自动binlog清除设置为7天。所以我知道这不是因为bin日志已被清除，因为错误是建议的。

我正在运行Ubuntu 14:04，以及Percona服务器版本5.6.31-77。

我该如何解决这个问题？主人的GTID_PURGED的正确值是什么？

Answer 1

mysql 5.6 GTID复制错误和修复什么是GTID？

4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

这是服务器的128位标识号（SERVER_UUID）。它标识交易的起源地。每个服务器都有自己的SERVER_UUID。 GTID解决了哪些问题？
可以在复制服务器之间唯一地标识事务。使故障转移过程的自动化更加容易。无需进行计算，检查二进制日志等。只是MASTER_AUTO_POSITION = 1。
在应用程序级别，更容易进行WRITE / READ分割。在MASTER上写入后，您有一个GTID，所以只需检查是否已在用于读取的SLAVE上执行了GTID。
现在开发新的自动化工具并不痛苦。我该如何实施呢？

复制链的所有服务器都需要三个变量

gtid_mode：可以是ON或OFF（不是1或0）。它在服务器上启用GTID。
log_bin：启用二进制日志。必须创建复制环境。
log-slave-updates：从属服务器必须在自己的二进制日志中记录来自主服务器的更改。
enforce-gtid-consistency：服务器拒绝无法以事务安全方式记录的语句。参考：http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html

复制错误和修复：

＆＃34;＆＃39;当从二进制日志中读取数据时，来自主站的致命错误1236：＆＃34;从站使用CHANGE MASTER连接到MASTER_AUTO_POSITION = 1，但主站已清除包含GTID的二进制日志奴隶需要。＆＃34; slave_io线程停止运行。

解决方案：考虑以下是主 - 从UUID＆＃39>

MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

步骤：

slave>stop slave;

slave> FLUSH TABLES WITH READ LOCK;

slave>show master status;

'4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-13030:13032-13317:13322-13325:13328-653183:653185-654126:654128-1400817:1400820-3423394:3423401-5779965′

(HERE 83345127  Last GTID executed on master and 5779965 Last slave GTID executed on Master )

slave> reset master;

slave>set global GTID_PURGED='4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-5779965′;

slave>start slave;

slave>unlock  tables;

  slave>show slave status;

注意：在重新启动奴隶后，如果他们停止复制，则需要其他连锁奴隶;

错误：＆＃39;错误＆＃34;表...＆＃39;不存在＆＃34;在查询。默认数据库：...查询：＆＃34; INSERT INTO或Last_SQL_Error：...。错误＆＃39;重复输入＆＃39; slave上的SKIP事务（slave_sql线程停止运行）注意：

SQL_SLAVE_SKIP_COUNTER不再适用于GTID。
我们需要找到导致复制失败的事务。
- - 来自二进制日志
- - 从SHOW SLAVE STATUS（检索vs执行）错误类型:(检查show slave status中的最后一个sql错误）

解决方案：考虑以下是主 - 从UUID＆＃39>

MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

奴隶＆gt;显示奴隶状态;

复制＆＃39; Executed_Gtid_Set＆＃39;值。＆＃39; 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4：1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444：1-70734947-80436012：80436021-80437839＆＃39;

-Seems that slave（与uuid 5b37def1-6189-11e3-bee0-e89a8f22a444）交易＆＃39; 80437840＆＃39;这里引起了问题。

slave> STOP SLAVE;

slave> SET GTID_NEXT="5b37def1-6189-11e3-bee0-e89a8f22a444:80437840";  (last_executed_slave_gtid_on_master + 1)

slave> BEGIN; COMMIT;

slave> SET GTID_NEXT="AUTOMATIC";

slave> START SLAVE;

slave>  show slave status;

并且它全部设定!!!

Answer 2

＃如果使用xtrabackup是主实例中的备份。

cat xtrabackup_info | grep binlog_pos

＃以您提供的信息为例：

binlog_pos =文件名'mysqld-bin.000283'，位置'294922064'，最后更改的GTID'1570dee1-165b-11e6-a4a2-00e081e93212：1-3537，c73f3ee7-e8d4-ee19-6507-f898a9930ccd：1 -18609，cdb70eaa-f753-ee1b-5c95-ecb8024ae729：1-2357789559：2357789561-2357790104：2357790106-2514115701：2514115703-2514115705：2514115707-2546400960'

#copy对gtid_purged的最新更改的GTID

slave>STOP SLAVE;
slave>RESET MASTER;
slave>SET GLOBAL gtid_purged='1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960';
slave>change master to master_host='master ip',master_port=master port,MASTER_USER = 'Your replicate username', MASTER_PASSWORD = 'Your replicate password',master_auto_position=1; 
slave>START SLAVE;

MySQL错误1236使用GTID时

2 个答案: