background
错误原因，slave 在主库找不到binlog文件
Write in front
本次使用dbdeployer快速搭建测试环境https://github.com/datacharmer/dbdeployer/releases
link
Reproduce the problem
1. Stop slave from the library;
2. Update data or add data, and then flush logs;
3. Manually delete master binlog, purge binary logs to'bin.0000**';
the binglog deleted in the third step contains The transaction data of the second step. After opening the copy thread from the library, an error will be reported.
The simulation here is a scenario where the main library has deleted too many binlog files or has not been transferred to the slave library.
Error message
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.'
Solution
主库purge 的binlog文件还没有传到从库。（或是从库缺少binlog,主库上也没有了） 解决办法是，重建从库。
Error message
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.'
Solution
使用的前提是，已经重新基于最新的主库，备份恢复了从库。但是从库出现上述问题。
The reason is that after rebuilding the slave database above, it shows that the transaction is still ./mysql-bin.000010' at 454. View from the library Executed_Gtid_Set: 00017261-1111-1111-1111-111111111111: 1-1001171 is consistent
with the host's show master status. (The data is normal).
The solution is to restart the replication thread (stop slave, start slave) from the library after flush logs in the main library.
Supplement about the use of 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
About 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时。
This article explains that the main technical content comes from the sharing of Internet technology giants, as well as some self-processing (only for the role of annotations). If related questions, please leave a message after the confirmation, the implementation of infringement will be deleted