Alas, misfortune is not a single line, just encountered deadlock problem, encountered table_id problem...
- Source Code Analysis of TABLE ID in MySQL Binlog
- Detailed reasons for missing mysql slave data of Taobao Logistics
- MySQL table_id principle and risk analysis
- FAQ Series | table id problem caused master-slave replication to fail
- [MySQL] And table_in MySQLID
Conclusion:
1. Increase table cache
2. Check table_periodicallyId, whose value cannot exceed uint (restart primary library)
3. Will RPL_TABLE_LIST Table_inside this internal data structureChange ID type to ulong (modify MySQL source)
Outside of the sentence:
Looking at the output of mysql using strace, it is observed that the relay log is normally read, but the binlog is always opened from the first corpus poll
102300 10:32:03.110995 open("/data/dir/mysql-bin.000018", O_RDONLY|O_CLOEXEC) = 136 <0.000014> 102300 10:32:03.111123 open("/data/dir/mysql-bin.000019", O_RDONLY|O_CLOEXEC) = 136 <0.000009> 102300 10:32:03.111242 open("/data/dir/mysql-bin.000020", O_RDONLY|O_CLOEXEC) = 136 <0.000007> 102300 10:32:03.111351 open("/data/dir/mysql-bin.000021", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 64972 10:32:03.196014 open("/data/dir/mysql-bin.000018", O_RDONLY|O_CLOEXEC) = 136 <0.000013> 64972 10:32:03.196147 open("/data/dir/mysql-bin.000019", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 64972 10:32:03.196253 open("/data/dir/mysql-bin.000020", O_RDONLY|O_CLOEXEC) = 136 <0.000007> 64972 10:32:03.196356 open("/data/dir/mysql-bin.000021", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 64972 10:32:25.839283 open("/data/dir/mysql-bin.000018", O_RDONLY|O_CLOEXEC) = 136 <0.000012> 64972 10:32:25.839430 open("/data/dir/mysql-bin.000019", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 64972 10:32:25.839539 open("/data/dir/mysql-bin.000020", O_RDONLY|O_CLOEXEC) = 136 <0.000007> 64972 10:32:25.839646 open("/data/dir/mysql-bin.000021", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 102300 10:32:33.111911 open("/data/dir/mysql-bin.000018", O_RDONLY|O_CLOEXEC) = 136 <0.000011> 102300 10:32:33.112030 open("/data/dir/mysql-bin.000019", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 102300 10:32:33.112137 open("/data/dir/mysql-bin.000020", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 102300 10:32:33.112242 open("/data/dir/mysql-bin.000021", O_RDONLY|O_CLOEXEC) = 136 <0.000007> 64972 10:32:33.196552 open("/data/dir/mysql-bin.000018", O_RDONLY|O_CLOEXEC) = 136 <0.000012> 64972 10:32:33.196671 open("/data/dir/mysql-bin.000019", O_RDONLY|O_CLOEXEC) = 136 <0.000007> 64972 10:32:33.196776 open("/data/dir/mysql-bin.000020", O_RDONLY|O_CLOEXEC) = 136 <0.000008> 64972 10:32:33.196882 open("/data/dir/mysql-bin.000021", O_RDONLY|O_CLOEXEC) = 136 <0.000007>
This is odd, as Bog said before, that ulong saves to the unint type being staged, but here you see binlog rotate...
Embarrassed instances rebuilt...