Replication Modes
MySQL primary-secondary replication can be implemented in traditional mode or using global transaction identifiers (GTIDs). The primary and secondary databases use the same replication mode.
- Traditional mode (default mode): The secondary database replicates the binlog information (the file name of the binlog and the position in the binlog) obtained from the primary database.
Figure 1 Replication architecture (traditional mode)
- GTID mode: GTID-based replication is recommended for MySQL 5.7 or later versions. MySQL provides each transaction with a GTID, which is globally unique in the primary database and the entire primary/secondary cluster. A GTID consists of source_id and transaction_id, for example, UUID:33, UUID:34, and UUID:35 in Figure 2. source_id indicates the universally unique identifier (UUID) of the server that generates the GTID and is stored in the DARADIR/auto.cnf file. transaction_id indicates the sequence number of each server, which starts from 1 in ascending order. A GTID is automatically generated when a transaction is committed. The primary database finds an unused minimum GTID greater than 0 from the GTID set (gtid_executed) and uses it as the GTID of the next transaction. The secondary database reads the GTID of the primary database from the relay log. This GTID is used by the next transaction.
The GTID-based replication process is described as follows:
- The primary database adds the GTID before the transaction ID to generate a new transaction ID. It updates data, records the new transaction ID and data operations to the binlog, and calls the dump thread to notify the secondary database of the data update.
- The secondary database calls the I/O thread to obtain the binlog from the primary database, and writes the binlog to the relay log.
- The secondary database calls the SQL thread to read the GTID from the relay log, and checks whether the GTID record exists in the binlog of the secondary database. If yes, the transaction specified by the GTID has been executed, and the secondary database will not execute the transaction. If no, the secondary database will execute the transaction and records the transaction and update operations to the binlog.
Figure 3 GTID-based replication process
Application Scenarios
As a common MySQL replication practice, GTIDs automatically search for breakpoints for replication, eliminating the need to manually search for binlogs and positions and thus facilitating maintenance and management.
Parent topic: Principles
