背景
错误原因,slave 在主库找不到binlog文件
写在前面
本次使用dbdeployer快速搭建测试环境https://github.com/datacharmer/dbdeployer/releases
link
问题复现
1.从库 stop slave;
2.更新数据或是添加数据,然后flush logs;
3.手动删除master binlog ,purge binary logs to ‘bin.0000**’;
第三步删除的binglog中包含第二步的事务数据。之后开启从库复制线程,就会报错。
此处模拟的是主库删除了过多或是还没有传到从库的binlog文件的场景。
报错信息
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.'
解决办法
主库purge 的binlog文件还没有传到从库。(或是从库缺少binlog,主库上也没有了) 解决办法是,重建从库。
紧接着报错信息
Got fatal error 1236 from master when reading data from binary log:
'unknown error reading log event on the master; the first event '' at 4,
the last event read from './mysql-bin.000010' at 454, the last byte read from './mysql-bin.000010' at 454.'
解决办法
使用的前提是,已经重新基于最新的主库,备份恢复了从库。但是从库出现上述问题。
原因,以上重建从库之后,显示事务还在./mysql-bin.000010’ at 454。查看从库Executed_Gtid_Set: 00017261-1111-1111-1111-111111111111:1-1001171
和主机的show master status 一致。(说明数据正常)。
解决办法是,主库,flush logs之后,从库重启复制线程(stop slave,start slave)。
关于dbdeployer使用的补充
备份
/usr/local/sandboxes/mysql_base/5.7.26/bin/mysqldump -hlocalhost -port17261 --socket=/tmp/mysql_sandbox17261.sock -umsandbox -p123456 --set-gtid-purged=OFF --single-transaction --master-data=2 test >/tools/test1204.sql
恢复
/usr/local/sandboxes/mysql_base/5.7.26/bin/mysql -umsandbox -p123456 --socket=/tmp/mysql_sandbox17262.sock test </tools/test1204.sql
好像它这个,我们自建复制需要大写:
CHANGE MASTER TO MASTER_HOST='192.168.66.133',master_port=17261, MASTER_USER='msandbox', MASTER_PASSWORD='123456', MASTER_AUTO_POSITION=1;
reset master 清空 select @@GLOBAL.GTID_EXECUTED;
--set-gtid-purged=ON默认 导出的sql文件导入时,会要求 @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
需要在从库reset master。
如果--set-gtid-purged=OFF 备份的sql导入,对于基于gtid的复制,从库有数据但是没有事务ID。(在重建从库时,不行。推荐默认备份ON,记录事务gtid)。
注意备份时不要--set-gtid-purged=OFF,因为它不导出事务id。本次我们需要事务id。缺点只是我们需要reset master
关于mysqldump
mysqldump报错如下:
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
FROM information_schema.COLUMN_STATISTICS
WHERE SCHEMA_NAME = 'tongdun_feature_offline_new' AND
TABLE_NAME = 'tongdun_feature_offline';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)
原因是mysqldump命令的版本和需要备份的版本不一致。比如mysql Ver 8.0.20备份5.7.26时。
本文说明,主要技术内容来自互联网技术大佬的分享,还有一些自我的加工(仅仅起到注释说明的作用)。如有相关疑问,请留言,将确认之后,执行侵权必删