Troubleshooting Inbound Replication
Troubleshoot the issues you find during inbound replication.
Troubleshooting Inbound Replication Errors
Isolate inbound replication errors by retrieving inbound replication-related information.
Using MySQL Shell
Use MySQL Shell or a MySQL client program to retrieve inbound replication-related information.
- A running replica DB system.
- MySQL Shell or a MySQL client program connected to the replica DB system.
SHOW REPLICA STATUS \G
Shows status information on essential parameters of the replica threads. See SHOW REPLICA STATUS.
SELECT * FROM performance_schema.replication_connection_status \G
Shows the current status of the I/O thread that handles the replica's connection to the source. See replication_connection_status.
SELECT * FROM performance_schema.replication_applier_status_by_worker \G
Shows details of the transactions handled by applier threads on a replica. See replication_applier_status_by_worker.
Inbound Replication Receiver Error Codes
This table shows some of the common inbound replication receiver error codes.
Table 22-4 Inbound Replication Receiver Error Codes
Error Code | Description |
---|---|
MY-1045: ER_ACCESS_DENIED_ERROR; Access denied
for user '%s'@'%s' |
|
MY-1227 (42000): Access denied; you need (at
least one of) the SUPER or SET_USER_ID privilege(s) for this
operation |
You can do either of the following:
|
MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG
Got fatal error %d from master when reading data from binary log:
'%s' |
See Resolving Fatal Error 1236. |
MY-2003: Network connection has been
refused |
Hostname and port are incorrect, or the source is not running. Check the hostname and port you defined and confirm the source is running. |
MY-3159: ER_SECURE_TRANSPORT_REQUIRED Connections
using insecure transport are prohibited while
--require_secure_transport=ON |
The source requires a secure connection. Confirm you selected one of the SSL options when you defined your channel. |
Inbound Replication Applier Error Codes
This table shows some of the common inbound replication applier error codes.
Table 22-5 Inbound Replication Applier Error Codes
Error Code | Description |
---|---|
|
These errors occur if the data on the replica is no longer synchronised with the source. This can occur if the data on the replica has been edited manually, for example. To correct these errors, you must resynchronise the source and replica, and resume the replication channel. |
MY-1205: ER_LOCK_WAIT_TIMEOUT |
Timeout exceeded. To correct this error, resume the replication channel. See Resuming a Channel. |
MY-1595/ MY-013121: RELAY LOG READ
FAILURE |
The relay log is corrupted and cannot be read. To correct this error, reset the replication channel. See Resetting a Channel. |
Resolving Fatal Error 1236
You get the error when either the GTID set from the logical dump is not applied on the DB system or the binary logs were purged from the source. Binary logs are a mandatory requirement for replication.
Using MySQL Shell
Use MySQL Shell to resolve the Fatal Error 1236
that you
get while running inbound replication.
- You get the
Fatal Error 1236
while running inbound replication: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.
In the initial connection handshake, the replica (DB System) sends a GTID set containing the transactions that it has already received, committed, or both. The source responds by sending all transactions recorded in its binary log whose GTID is not included in the GTID set sent by the replica. This exchange ensures that the source only sends the transactions with a GTID that the replica has not already recorded or committed.
- To apply the GTID set during load, use the
updateGtidSet: "append"
option in the MySQL ShellloadDump()
command. See MySQL Shell Dump Loading Utility. - Review and increase the expire log configuration of the source to ensure sufficient time for the data transfer to the replica. See binlog_expire_logs_seconds and expire_logs_days.
Resolving Replica and Source Synchronization Issues
You get the synchronization issues when the replica has fallen far behind the source, and replication is unrecoverable.
Before you attempt to recover from this error, it is recommended to investigate why the error occurred and take corrective action.
Using MySQL Shell
Use MySQL Shell to resolve the replica and source synchronization issues.
- Your inbound replication source and replica are no longer synchronized, the replica has fallen far behind the source, and replication is unrecoverable.
If the source gtid values are reset to a lower value than those of the replica, if an erroneous
reset
master
was issued on the source, for example, inbound replication is
not recoverable. In that scenario, recreate the DB system and inbound replication
configuration.