Why Does CHANGE MASTER Trigger Traffic Spikes in MySQL GTID Replication?

Background

After the master server’s IP address was changed (the instance remained the same), a massive amount of traffic appeared between the master and its replica. Both master and replica were configured with GTID and semi‑synchronous replication.

Observed Symptoms

Monitoring graphs showed that the master’s send traffic was abnormally high while its receive remained normal. Conversely, the replica’s receive traffic was high and its send traffic was normal. The master’s send curve overlapped almost exactly with the replica’s receive curve, indicating that the master was sending all traffic to the replica.

Key Question

Does executing CHANGE MASTER cause the replica to re‑receive binlog events that have already been applied on the master?

Test Setup

Environment: MySQL 5.7.12 with GTID enabled, using auto_position=1 for master‑replica configuration. Several operations were performed while observing the replica’s relay‑log contents.

Effect of CHANGE MASTER

After running CHANGE MASTER on the replica, the original relay‑log was cleared and a new log was created that included GTID information.

Restarting the replica with auto_position=1 showed that the replica started but did not immediately pull any binlogs from the master. After executing a simple SQL statement on the master, the replica fetched only the binlog entries that followed the last executed GTID, confirming that previously executed binlogs were not re‑sent.

Conclusion for First Question

Using CHANGE MASTER with auto_position=1 does not cause the replica to re‑pull binlog events that have already been executed on the master.

Extended Question: What If the Replica Is Lagging?

The author asked whether, when the replica already has replication lag, executing CHANGE MASTER would cause the pending, not‑yet‑applied binlog portion to be fetched again, potentially creating a short‑term traffic spike.

Answer

Yes, it would.

Verification

In a sysbench‑loaded environment where the replica was lagging, the replica was stopped, and its relay‑log examined. The log contained many pending transaction IDs, confirming significant lag.

After locating the relevant transaction in the relay‑log and noting its position, CHANGE MASTER was executed. The replica’s relay‑log was cleared again. When the I/O thread was restarted, the previously lagged binlog segment was fetched, producing a noticeable traffic peak.

Monitoring showed the master’s traffic consisting entirely of send and the replica’s traffic consisting entirely of receive, matching the expected pattern during the re‑synchronization.

Final Conclusion

If the replica is delayed, executing CHANGE MASTER clears the existing relay‑log and forces the replica to re‑pull the delayed portion of the binlog, creating a traffic peak whose magnitude and duration depend on the size of the delayed binlog segment. The original high‑traffic incident was likely not solely caused by this mechanism, as the observed traffic persisted far longer than the total size of the master’s binlog.