(1) Before each transaction updates data, the Master records these changes in the binary log. After writing to the binary log is completed, the Master notifies the storage engine to commit the transaction.

(2) Slave copies Master to its relay log (Relay log). First, the slave starts a working thread (I/O), the I/O thread opens a normal connection on the Master, and then starts the Binlog dump process. Binlog dump process reads events from the Master's binary log. If it has caught up with the Master, it sleeps and waits for the Master to generate new events. The I/O thread writes these events to the relay log.

(3) The SQL slave thread (SQL slave thread) handles the last step of the process. The SQL thread reads events from the relay log and replays the events to update the Slave data to make it consistent with the data in the Master. As long as the thread is consistent with the data in the Master, The I/O thread remains consistent, and the relay log will usually be located in the OS cache, so the overhead of the relay log is very small. The replication process has an important limitation, that is, replication is serialized on the Slave, which means that parallel update operations on the Master cannot be performed in parallel on the Slave.

MySQL master-slave replication delay

The master server has high concurrency and forms a large number of transactions.

network delay

The master-slave hardware device causes the CPU frequency, memory IO, and hard disk IO

It is not synchronous replication, but asynchronous replication from the database to optimize Mysql parameters. For example, increasing innodb_buffer_pool_size allows more operations to be completed in Mysql memory and reduces disk operations. Use a high-performance host from the library. Including powerful CPU and increased memory. Avoid using virtual cloud hosts and use physical hosts, which improves I/O aspects. The slave library uses SSD disk network optimization to avoid synchronization across computer rooms.

Problem solving

Semi-synchronous replication - solves the problem of data loss

Parallel replication---solve the problem of replication delay from the database

2. MySQL has several synchronization methods: three

① Asynchronous Replication (Async Replication)

② Synchronous replication (sync Replication)

③ Semi-synchronous replication (Async Replication)

④ Enhanced semi-synchronous replication (lossless Semi-Sync Replication), lossless replication

Async Replication

After the master library writes the updates to the Binlog log file, it can continue to process more requests without waiting for the data updates to be copied to the slave library. The Master writes the event to the binlog, but does not know if or when the Slave has received it and processed it. In the case of an asynchronous replication mechanism, if the Master goes down, transactions have been committed on the Master, but it is likely that these transactions have not been transmitted to any Slave. Assuming there is a Master->Salve failover mechanism, the Slave may also lose transactions at this time. MySQL replication defaults to asynchronous replication, which provides the best performance.

Sync Replication

After the main library writes the update to the Binlog log file, it needs to wait until the data update has been copied to the slave library and successfully executed in the slave library before it can return to continue processing other requests. Synchronous replication provides the best security to ensure data security and data will not be lost, but it has a certain impact on performance.

Semi-Sync Replication

After the master library submits updates and writes them to the binary log file, it waits for the data updates to be written to the slave server relay log before it can continue to process other requests. This function ensures that at least one slave library has received the binlog content passed by the main library and has written it into its own relay log before notifying the waiting thread on the main library that the operation is completed. Semi-synchronous replication is a compromise between optimal security and optimal performance. The semi-synchronous replication function was introduced after MySQL version 5.5. The master-slave server must install the semi-synchronous replication plug-in to enable this replication function. If the waiting timeout exceeds the time set by the rpl_semi_sync_master_timeout parameter (the default value is 10000, which means 10 seconds), semi-synchronous replication is turned off and automatically converted to asynchronous replication mode. After the master dump thread has sent all events of a transaction, if a response from the slave library is received within rpl_semi_sync_master_timeout, the master-slave will return to enhanced semi-synchronous replication. ACK (Acknowledge character) is the confirmation character.

Enhanced semi-synchronous replication (lossless Semi-Sync Replication, lossless replication)

Enhanced semi-synchronization was introduced in MySQL 5.7. In fact, semi-synchronization can be regarded as a transitional function, because the default configuration is enhanced semi-synchronization. Therefore, the semi-synchronization that everyone generally refers to is actually enhanced semi-synchronization replication, which is lossless replication. . The difference between enhanced semi-sync and semi-sync is that the waiting time for ACK is different. rpl_semi_sync_master_wait_point = AFTER_SYNC (default). The problem with semi-sync is that the point of waiting for ACK is after Commit. At this time, the Master has completed the data change and the user can already see the latest data. When the Binlog has not been synchronized to the Slave and a master-slave switch occurs, the slave library does not have the latest data at this time, and the user sees the old data. Enhanced semi-synchronization places the point of waiting for ACK before submitting Commit. At this time, the data has not been submitted, and the outside world cannot see the data changes. If a master-slave switch is sent at this time, the new database will still have the old data, and there will be no problem of data inconsistency. .

3. Mysql application scenarios

The main performance of mysql database is reading and writing. In general scenarios, there are more read requests. Master-slave replication can evolve into read-write separation, because read-write separation is based on master-slave replication, and read-write separation can be used to solve high concurrency problems.

The direction of the evolution of mysql architecture: 1. A single mysql has a single point of failure 2. Cluster---》Master-slave replication 3. The pressure of master-slave replication across the river and writing is uneven 4. Read-write separation 5. The basis of read-write separation is master From copy 6, mysql high availability architecture MHA (master HA high availability)

4. Master-slave replication experiment

The first step is to install the time synchronization environment

Command: yum -y install ntp

The second step is to modify the NTP configuration file

Command: vim /etc/ntp.cnf

The third step is to start the service

Command: systemctl start ntpd

Step 4: Turn off firewalls and security mechanisms on all devices

Instruction: systemctl stop firewalld

setenforce 0

Step 5: Synchronize Alibaba Cloud time

Command: ntpdate ntp.aliyun.com

Step 6: Install the slave database environment

Command: yum -y install ntp ntpdate

Step 7: Synchronize time on all devices

Command: ntpdate ntp.aliyun.com

Step 8 Modify the database configuration file

Command: vim /etc/my.cnf

Step 9 Restart the service

Command: systemctl restart mysqld

Step 10: Enter the main database setting rules

Command: grant replication slave on *.* to 'myslave'@'network segment' identified by 'password';

Step 11: Refresh the permission table

Command: flush privileges;

Step 12 Check the main database status

Command: show master status;

Step 13 Modify the slave database configuration file

Command: vim /etc/my.cnf

Step 14 Restart the service

Command: systemctl restart mysqld

Step 15 Configure relevant content information and start

Command: change master to master_host='Master database IP address',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=log number;

start slave

Step 16 Check whether the information from the database is correct

Instruction: show slave status\G

Step 17 Test Experiment Results

Command: create database database name;

Step 18 Check whether the slave database is synchronized

Command: show databases;

How to deploy MySQL master-slave replication

1. Master-slave replication principle

MySQL replication types

The working process of MySQL master-slave replication;

Two logs, three threads