Description:
A slave will apply an already done binary event and silently continue. This is OK, but maybe it's good to put a Warning in the error log when this happens.
We found this when failing over replication channels for MySQL Cluster Replication. The manual says to do the following query on the master to start
the new slave reading from the binary logs:
mysqlM'> SELECT
-> @file:=SUBSTRING_INDEX(File, '/', -1),
-> @pos:=Position
-> FROM mysql.ndb_binlog_index
-> WHERE epoch > @latest
-> ORDER BY epoch ASC LIMIT 1;
If you do '>= @latest' instead of '> @latest' it will do an epoch already applied. This works, and is not harming.
How to repeat:
On slave cluster:
mysql> select max(epoch),hex(epoch) from mysql.ndb_apply_status;
+----------------+--------------+
| max(epoch) | hex(epoch) |
+----------------+--------------+
| 47674136985602 | 2B5C00000002 |
+----------------+--------------+
On master cluster:
mysql> SELECT SUBSTRING_INDEX(File, '/', -1),Position FROM mysql.ndb_binlog_index WHERE epoch >= 47674136985602 ORDER BY epoch ASC LIMIT 5;
+--------------------------------+----------+
| SUBSTRING_INDEX(File, '/', -1) | Position |
+--------------------------------+----------+
| machA01.000001 | 91227 |
| machA01.000001 | 91562 |
| machA01.000001 | 91897 |
| machA01.000001 | 92232 |
| machA01.000001 | 92567 |
+--------------------------------+----------+
The binary event at position 91227 was already applied, we should actually take the 91562, but lets take 91227.
On slave cluster:
mysql> change master to master_host='localhost',master_port=3361,master_user='repl',master_log_file='machA01.000001',master_log_pos=91227;
mysql> start slave;
This silently works and continues correctly the replication.
Suggested fix:
Add a warning in the MySQL error log when an epoch/binary event is applied which was already done by the slave.
© 2024, Oracle Corporation and/or its affiliates
Description: A slave will apply an already done binary event and silently continue. This is OK, but maybe it's good to put a Warning in the error log when this happens. We found this when failing over replication channels for MySQL Cluster Replication. The manual says to do the following query on the master to start the new slave reading from the binary logs: mysqlM'> SELECT -> @file:=SUBSTRING_INDEX(File, '/', -1), -> @pos:=Position -> FROM mysql.ndb_binlog_index -> WHERE epoch > @latest -> ORDER BY epoch ASC LIMIT 1; If you do '>= @latest' instead of '> @latest' it will do an epoch already applied. This works, and is not harming. How to repeat: On slave cluster: mysql> select max(epoch),hex(epoch) from mysql.ndb_apply_status; +----------------+--------------+ | max(epoch) | hex(epoch) | +----------------+--------------+ | 47674136985602 | 2B5C00000002 | +----------------+--------------+ On master cluster: mysql> SELECT SUBSTRING_INDEX(File, '/', -1),Position FROM mysql.ndb_binlog_index WHERE epoch >= 47674136985602 ORDER BY epoch ASC LIMIT 5; +--------------------------------+----------+ | SUBSTRING_INDEX(File, '/', -1) | Position | +--------------------------------+----------+ | machA01.000001 | 91227 | | machA01.000001 | 91562 | | machA01.000001 | 91897 | | machA01.000001 | 92232 | | machA01.000001 | 92567 | +--------------------------------+----------+ The binary event at position 91227 was already applied, we should actually take the 91562, but lets take 91227. On slave cluster: mysql> change master to master_host='localhost',master_port=3361,master_user='repl',master_log_file='machA01.000001',master_log_pos=91227; mysql> start slave; This silently works and continues correctly the replication. Suggested fix: Add a warning in the MySQL error log when an epoch/binary event is applied which was already done by the slave.