Asynchronous Replication

Overview

In asynchronous replication, after executing the transaction committed by the client, the primary database immediately returns the result to the client and calls the dump thread to notify the secondary database of the new transaction. The secondary database calls the I/O thread to write the obtained binlog to the relay log, calls the SQL thread to replay the relay log, and writes the update to the local drive. The primary database does not care whether the secondary database has received the binlog. Therefore, the data in the primary database may be inconsistent with that in the secondary database. If the primary database is faulty, data will be lost after the secondary database is forcibly switched over to the primary database.

Service Process

1. The client calls the user thread to send a data update request to the primary database. The primary database updates data, writes the update to the binlog, and returns a success message to the client. The primary database calls the dump thread to notify the secondary database of the new transaction.
2. After receiving the notification from the primary database, the secondary database calls the I/O thread to read the mysql.slave_master_info table to obtain the current binlog file name and position (position in the binlog) of the primary database, and then calls the I/O thread to send a request to the primary database for obtaining the latest binlog file name and position.
3. After receiving the request from the I/O thread of the secondary database, the primary database returns the latest binlog file name and the binlog to the secondary database.
4. The secondary database writes the binlog obtained from the primary database to the relay log, and updates the latest binlog file name and position to the mysql.slave_master_info table. Then, the secondary database calls the SQL thread to replay the relay log and writes the update to the local drive.

Application Scenarios

Asynchronous replication features low latency but may cause data loss on the secondary database. Hence it is suitable for scenarios that require high performance and can tolerate the loss of some data.