[英]MySQL error 1236 When using GTID
我想在启用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)
从具有新备份副本的slave,我得到:
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的正确值是多少?
mysql 5.6 GTID复制错误和修复什么是GTID? 
4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
这是服务器的128位标识号(SERVER_UUID)。 它标识交易的起源地。 每个服务器都有自己的SERVER_UUID。 GTID解决了什么问题?
可以跨复制服务器唯一地标识事务。 使故障转移过程的自动化更加容易。 无需进行计算,检查二进制日志等。 只是MASTER_AUTO_POSITION = 1。
复制链的所有服务器都需要三个变量
复制错误和修复:
“当从二进制日志读取数据时,来自主站的致命错误1236:”从站使用CHANGE MASTER连接到MASTER_AUTO_POSITION = 1,但主站已清除包含从站所需的GTID的二进制日志。“slave_io线程停止运行。
解决方案:考虑以下是主 - 从UUID
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;
注意:如果它们停止复制,则在重新启动从属其他链式从属之后;
错误:'错误'表...'查询不存在'。默认数据库:...查询:“INSERT INTO OR Last_SQL_Error:...。Error'重复项'从站的SKIP事务(slave_sql线程停止运行)注意:
解决方案:考虑以下是主 - 从UUID
MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444
奴隶>显示奴隶状态;
复制'Executed_Gtid_Set'值。 '4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444:1-70734947-80436012:80436021-80437839'
-seems奴隶(与uuid 5b37def1-6189-11e3-bee0-e89a8f22a444)交易'80437840'在这里造成了问题。
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;
这一切都是!!!
#如果使用xtrabackup是主实例中的备份。
cat xtrabackup_info | grep binlog_pos
#使用您提供的信息作为示例:
binlog_pos = filename'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对gtid_purged的最后一次更改
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;
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.