table of Contents
Preface
The following content is based on MySQL5.7 official documents
Mysql Replication
You can copy data from one MySQL database server (source) to one or more MySQL database servers (replicas). By default, replication is asynchronous and performs better; the replica does not need to be permanently connected to receive updates from the source. Depending on the configuration, you can copy all the databases in the database, selected databases, and even selected tables.
The advantages of replication in MySQL include:
- Scale-out solution-spread the load among multiple copies to improve performance. In this environment, all writes and updates must be performed on the replication source server (primary server). However, the read may occur on one or more replicas (slave servers). This model can improve write performance (because the source is dedicated to updates), while it can significantly increase read speeds in more and more replicas.
- Data security-because the data has been copied to the copy, and the copy can suspend the copy process, backup services can be run on the copy without destroying the corresponding source data.
- Analysis-Real-time data can be created on the source, and information analysis can be performed on the copy without affecting the performance of the source.
- Remote data distribution-You can use replication to create local copies of data for use by remote sites without having to permanently access the source.
MySQL 5.7 supports different replication methods. Traditional methods are based on copying events in the source binary log, and require log files and their locations to be synchronized between the source and the copy. Based on the Global Transaction Identifier (GTID) is a newer method, it is transactional, so there is no need to deal with log files or locations in these files, which greatly simplifies many common replication tasks. Using GTID for replication can ensure the consistency between the source and the replica, as long as all transactions committed on the source have also been applied to the replica.
Replication in MySQL supports different types of synchronization. The original type of synchronization is one-way asynchronous replication, in which one server acts as the source and one or more other servers act as replicas. This is contrary to the synchronous replication feature of NDB Cluster. In MySQL 5.7, in addition to the built-in asynchronous replication, it also supports semi-synchronous replication. For semi-synchronous replication, before returning to the session that performed the transaction, commit is performed on the source block until at least one replica confirms that it has received and recorded the transaction event; MySQL 5.7 also supports delayed replication so that the replica is after the time specified by the source Make a copy. For scenarios that require synchronous replication, please use NDB Cluster
There are two core types of replication formats: statement-based replication (SBR), which replicates the entire SQL statement; and row-based replication (RBR), which replicates only changed rows. You can also use the third type of hybrid hybrid replication (MBR).
You can use replication to solve many different problems, including performance, supporting backups of different databases, and as part of a larger solution to mitigate system failures.
Replication based on binary log file location
This section introduces the replication between MySQL servers based on the binary log file location method. In this replication method, the source MySQL instance (database changes originate from this instance) write updates and changes as "events" to the binary log. The information in the binary log is stored in different log record formats according to the recorded database changes. Configure the replica to read the binary log from the source and execute events in the binary log on the replica's local database.
Each copy receives a copy of the entire contents of the binary log. The copy is responsible for determining which statements in the binary log should be executed. Unless you specify otherwise, all events in the source binary log are executed on the copy. If needed, the replica can be configured to only process events that apply to a specific database or table.
Each copy records binary log coordinates: the name of the file read and processed from the source and the location of the file in the file. This means that multiple copies can be connected to the source and execute different parts of the same binary log. Since the replica controls this process, it is possible to connect and disconnect a single replica from the server without affecting the operation of the source. Similarly, since each copy records the current position in the binary log, the copy may be disconnected, reconnected, and then resume processing.
A unique ID must be configured for the source and each replica (using the server_id system variable). In addition, information about the source host name, log file name, and location in the file must be configured for each copy. You can use the CHANGE MASTER TO statement on the copy to control these details in the MySQL session.
Note: The copy source represents the master database (master), and the copy represents the slave database (slave)
Copy related configuration
The following will introduce the basic configuration based on binary log file replication. After reading it, you can clearly know and configure it.
Set the replication source configuration
To configure the source to use replication based on the location of the binary log file, you must ensure that binary logging is enabled and establish a unique server ID.
Each server in the replication topology must be configured with a unique server ID, which you can specify using the server_id system variable. This server ID is used to identify each server in the replication topology and must be a positive integer between 1 and (2 32) -1. You can dynamically change the value of server_id by issuing the following statement:
SET GLOBAL server_id = 2;
When the default server ID is 0, the source refuses any connection from the replica, and the replica refuses to connect to the source, so this value cannot be used in the replication topology. In addition to this, you can choose how to organize and select server IDs, as long as each server ID is different from every other server ID used by any other server in the replication topology. Note that if you previously set a value of 0 for the server ID, you must restart the server to initialize the source with the new non-zero server ID. Otherwise, there is no need to restart the server unless you need to enable binary logging or make other configuration changes that require a restart.
Binary logging must be enabled on the source because the binary log is the basis for copying changes from the source to its copy. If binary logging is not enabled on the source using the log-bin option, replication cannot take place. To enable binary logging on a server that has not been enabled for binary logging, you must restart the server. In this case, please shut down the MySQL server and edit the my.cnf or my.ini file. In the [mysqld] configuration file section, add log-bin and server-id options. If these options already exist but have been commented out, please uncomment these options and make changes as needed. For example, to use the log file name prefix to enable binary logging mysql-bin and configure the server ID to 1, use the following lines:
[mysqld]
log-bin=mysql-bin
server-id=1
After making the changes, restart the server.
Note The
following options affect this process:
In order to obtain the maximum durability and consistency in the replication settings where InnoDB is used with transactions, it should be used in the source file
innodb_flush_log_at_trx_commit=1
和
sync_binlog=1
Make sure that the skip_networking system variable is not enabled on your source. If this variable is enabled, the network connection will be disabled, the copy cannot communicate with the source, and the copy will fail.
Create a user for replication
Each replica needs to use a MySQL username and password to connect to the source, so there must be a user account on the source, and the replica can be used to connect. When setting up a copy, the user name is specified by the option CHANGE MASTER TO on the command MASTER_USER. As long as the account has been granted REPLICATION SLAVE privileges, any account can be used for this operation. You can choose to create a different account for each copy, or use the same account for each copy to connect to the source.
Although it is not necessary to create an account specifically for replication, it should be noted that the replication username and password are stored in plain text in the replication metadata repository. Therefore, you may want to create a separate account that only has privileges for the copy process to minimize the possibility of harm to other accounts.
To create a new account, use the CREATE USER command. To grant the account the required privileges for replication, use the following GRANT statement. If the account is created only for replication purposes, the account only needs the REPLICATION SLAVE privilege. For example, to set up a new user, repl that user can replicate connections from any host in the example.com domain, issue the following statement on the source:
mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';
Get the binary log coordinates of the copy source
To configure the copy to start the copy process at the correct point, you need to write down the current coordinates of the source in its binary log.
If you plan to shut down the source to create a data snapshot, you can choose to skip this process and instead store a copy of the binary log index file with the data snapshot. In this case, the source will create a new binary log file on restart. Therefore, the binary log coordinates of the source where the copy must start is the start of the new file, which is the next binary log file on the source, after the file listed in the copied binary log index file.
To obtain the binary log coordinates of the source, follow these steps:
1. Connect to the source by using the command line client to start a session on the source, and flush all tables and prevent write statements by executing the following FLUSH TABLES WITH READ LOCK statement:
mysql> FLUSH TABLES WITH READ LOCK;
Note: FLUSH TABLES WITH READ LOCK will prevent the COMMIT operation of the table, that is, prevent the submission of write operations
2. In another session on the source, use the SHOW MASTER STATUS statement to determine the name and location of the current binary log file:
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73 | test | manual,mysql |
+------------------+----------+--------------+------------------+
The File column shows the name of the log file, and the Position column shows the position in the file. In this example, the binary log file is mysql-bin.000003 and the location is 73. Record these values. You will need them later when setting up the copy. They represent copied coordinates from which the copy should process new updates in the source.
If the source has been running before and binary logging is not enabled, the log file name and location value displayed by SHOW MASTER STATUS or mysqldump --master-data is empty. In this case, the value that needs to be used when specifying the source log file and location later is an empty string ('')
Now you have the information to make the copy start reading and copying from the binary log in the correct location.
#Copy settings
The following sections describe how to set up a copy.
1. Each copy must have a unique server ID specified by the server_id system variable. If you want to set up multiple replicas, each replica must have a unique server_id value, which must be different from the source replica and any other replicas. If the server ID of the replica server has not been set, or the current value conflicts with the value you selected for the source server or other replica servers, you must change it. The default server_id value is 0, which means that the replica refuses to connect to the source.
You can dynamically change the value of server_id by issuing the following statement:
SET GLOBAL server_id = 21;
If server_id has previously set the default value to 0, the server must be restarted to initialize the replica with the new non-zero server ID. Otherwise, you do not need to restart the server when changing the server ID unless you make other configuration changes that require it. For example, if binary logging is disabled on the server, and you want to enable binary logging on the copy, you need to restart the server to enable this feature.
If you want to shut down the replica server, you can edit the [mysqld] section of the configuration file to specify a unique server ID. E.g:
[mysqld]
server-id=21
The copy can be replicated without enabling binary logging. However, the binary log records on the copy can be used for data backup and crash recovery. Replicas with binary logging enabled can also be used as part of more complex replication topologies. If you want to enable binary logging on the replica, configure the log-bin option in the [mysqld] section of the configuration file. The server needs to be restarted to start binary logging on a server that has not been used before.
2. Set the source configuration on the replica server
To set up the replica to communicate with the replication source, configure the necessary connection information for the replica. To do this, execute the following statement on the copy, replacing the option value with the actual value related to the system:
mysql> CHANGE MASTER TO
-> MASTER_HOST='source_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
3. Start the replication thread:
mysql> START SLAVE;
After performing this process, the replica server will connect to the source and copy the self-taken snapshot to all updates that occurred on the source.