Error
Error Code:
1743
MariaDB Error 1743: Replication Checksum Failure
Description
This error indicates that the MariaDB replica (or client reading a binary log over the network) received corrupted or incomplete replication events from the source. The built-in checksum mechanism failed to validate the data integrity during network transfer, preventing successful replication. This typically happens during binary log synchronization.
Error Message
Replication event checksum verification failed while reading from network.
Known Causes
4 known causesNetwork Instability or Corruption
Unstable network connections, packet loss, or faulty network hardware can corrupt data packets during transmission between the MariaDB source and replica.
Hardware Issues
Defective network interface cards (NICs), cables, or other underlying hardware components on either the source or replica server can introduce data corruption.
Misconfigured Network Devices
Incorrect MTU settings, firewall rules, or other network device configurations might interfere with data integrity checks or cause packet fragmentation issues.
Software Bugs
Rarely, a bug in MariaDB itself or an underlying operating system component could lead to incorrect checksum calculations or verification failures.
Solutions
4 solutions available1. Restart Replication Threads easy
A simple restart often resolves transient network or data corruption issues.
1
On the replica server, stop the replication threads.
STOP SLAVE;2
Check the replication status for any errors.
SHOW SLAVE STATUS\G3
If the error persists, try clearing the relay logs (use with caution, as this will require re-syncing from the master if not handled carefully).
RESET SLAVE;4
Start the replication threads again.
START SLAVE;5
Monitor the replication status again to confirm it's working.
SHOW SLAVE STATUS\G2. Verify Network Connectivity and Integrity medium
Ensure a stable and uncorrupted network path between master and replica.
1
On the replica server, ping the master server to check basic network reachability.
ping <master_server_ip_or_hostname>2
Use `mtr` (My Traceroute) or `traceroute` to diagnose network latency and packet loss between the master and replica.
mtr <master_server_ip_or_hostname>3
Check for any firewall rules that might be interfering with the replication port (default 3306).
sudo ufw status4
If packet corruption is suspected, consider using tools like `tcpdump` on both master and replica to capture and analyze network traffic for anomalies during replication.
sudo tcpdump -i <interface> host <master_ip> and port 3306 -w replication_traffic.pcap5
If network issues are identified, work with your network administrator to resolve them. This might involve checking switches, routers, or network interface cards.
text3. Disable and Re-enable Checksum Verification medium
Temporarily disable checksums to rule out issues with the checksum calculation or verification process itself.
1
On the master server, disable binary log checksums.
SET GLOBAL binlog_checksum = 'NONE';2
Restart the replica's replication threads (as per 'Restart Replication Threads' solution).
STOP SLAVE; START SLAVE;3
Monitor replication. If it starts working, the issue is likely related to checksums. Re-enable checksums after troubleshooting.
SHOW SLAVE STATUS\G4
On the master server, re-enable binary log checksums. It's recommended to use a strong checksum algorithm like CRC32.
SET GLOBAL binlog_checksum = 'CRC32';5
If the problem reoccurs immediately after re-enabling checksums, investigate potential issues with the `binlog_format` or data inconsistencies.
text4. Rebuild Replica from a Fresh Master Dump advanced
A comprehensive solution for persistent corruption or checksum mismatches.
1
On the master server, take a consistent dump of the database.
mysqldump --all-databases --master-data=2 --single-transaction --flush-logs -u root -p > full_master_dump.sql2
Note the `file` and `position` from the `SHOW MASTER STATUS;` output after the dump. This is crucial for setting up replication correctly.
text3
On the replica server, stop replication and reset its slave state.
STOP SLAVE; RESET SLAVE ALL;4
Drop all existing databases on the replica (if safe to do so, otherwise manually drop them).
DROP DATABASE IF EXISTS \`database_name\`;5
Import the dump file into the replica server.
mysql -u root -p < full_master_dump.sql6
Configure the replica to connect to the master using the recorded `file` and `position` from step 2.
CHANGE MASTER TO MASTER_HOST='<master_server_ip_or_hostname>', MASTER_USER='<replication_user>', MASTER_PASSWORD='<replication_password>', MASTER_LOG_FILE='<recorded_log_file>', MASTER_LOG_POS=<recorded_log_position>;7
Start the replication threads on the replica.
START SLAVE;8
Monitor `SHOW SLAVE STATUS\G` to ensure replication is running without errors.
SHOW SLAVE STATUS\G