MySQL — Introduction to Master-Slave Replication

master-slave replication

I. Overview

​Master- slave replication refers to transferring the DDL and DML operations of the master database to the slave library server through the binary log, and then re-executing these logs on the slave library (also called redo), so that the data in the slave library and the master library remains Synchronize.

​ The binary log file of the main library is synchronized from the library and executed. At this time, the data of the slave library and the data of the main library are also synchronized and consistent. This process is called master-slave replication.

MySQL supports one master database to replicate to multiple slave databases at the same time, and the slave database can also be used as the master database of other slave servers to realize chain replication

The main library is generally called Master, and the slave library is generally called Slave

advantage

• If there is a problem with the master library, you can quickly switch to the slave library to provide services

• Realize read-write separation and reduce the access pressure of the main library

  Requests for additions, deletions, and modifications operate on the master library, and requests for queries operate on the slave library

• Backups can be performed in the slave library to avoid affecting the main library service during the backup

​ When backing up data, a global lock needs to be added to avoid data inconsistency

​ After adding a global lock, other clients cannot perform additions, deletions, and modifications (but can query), which will obviously affect the business

​ But now with the slave library, data backup is performed directly in the slave library, but the main library can still be used. After the backup of the slave library is completed, the binary file is synchronized to the slave library, and the data of the main library and the slave library are consistent.

The following article introduces the situation of adding global locks and not adding global locks when performing backups:

MySQL — lock_I love Brown Bear's blog

2. Principle

How is the data in the master library synchronized to the slave library?

​Once related operations such as adding, deleting, modifying and executing DDL statements occur in the main library , it will write all data changes to a log - Binlog log (binary log)

​In this binary log, all data changes of the main library are recorded . (For example, if the main library executes an insert, it will be recorded in the Binlog log)

Two sets of threads are involved from the library

• IOThread

​ will initiate a request to connect to the master database, and then read the binlog logs in the master database.

​ After reading the log and returning, IOThread will write the Binlog log to a log of Slave itself, which is called the relay log Relay Log

• SQLThread

​ After the above steps are completed, the SQLThread thread appears. It is mainly responsible for reading the data in the relay log and reflecting the data changes recorded in the relay log to the data changes in its own database, thus ensuring that the master-slave data is consistent.

Binary log knowledge can be supplemented in the following article

MySQL — log, error log, binary log, query log, slow query log

Summarize

① When the master main library commits the transaction, it will record the data change in the binary log file Binlog.

② Read the binary log file Binlog of the master library from the library, and write it to the relay log Relay Log of the slave library.

③The slave redoes the events in the relay log, which will change to reflect its own data.

3. Build a master-slave replication structure

I don't have two servers, so I can only study theory.

3.1 Server preparation

Just turn off the firewall

3.2 Main library configuration

The main library can both read and write

• Modify the my.ini file

  binlog-ignore-db: Indicates which database to ignore during synchronization

  binlog-do-db: Specify which database to synchronize

#mysql 服务ID，保证整个集群环境中唯一，取值范围：1 – 232-1，默认为1
server-id=1
#是否只读,1 代表只读, 0 代表读写
read-only=0
#忽略的数据, 指不需要同步的数据库
#binlog-ignore-db=mysql
#指定同步的数据库
#binlog-do-db=db01

• Restart the MySQL service

systemctl restart mysqld

• Log in to MySQL, create a remote connection account, and grant the master-slave replication permission.
  This account is the account and password when the slave library will link to the master library in the future.

#创建itcast用户，并设置密码，该用户可在任意主机连接该MySQL服务。 %表示该用户可以在任意主机上访问该服务器
CREATE USER 'itcast'@'%' IDENTIFIED WITH mysql_native_password BY 'Root@123456';

#为 'itcast'@'%' 用户分配主从复制权限
GRANT REPLICATION SLAVE ON *.* TO 'itcast'@'%';

• View binary log coordinates

show master status;

file : from which log file to start pushing log files

position : From which position to push logs

binlog_ignore_db : Specify the database that does not need to be synchronized

3.3 Slave library configuration

• Modify the configuration file my.ini

  The slave library is read-only, which only means that it is read-only for ordinary users. It can also be read and written if it has administrator permissions. If you want the super administrator to also read-only, you need to add a super-read-only=1

#mysql 服务ID，保证整个集群环境中唯一，取值范围：1 – 2^32-1，和主库不一样即可
server-id=2
#是否只读,1 代表只读, 0 代表读写
read-only=1

• Restart the MySQL service

systemctl restart mysqld

• Log in to MySQL and set the main database configuration

  SOURCE_HOST: host address

  SOURCE_USER: Which user corresponds to the server

  SOURCE_PASSWORD: password

  SOURCE_PASSWORD: From which binary log file to start synchronization

  SOURCE_LOG_POS: From where to start synchronization in this log

CHANGE REPLICATION SOURCE TO 
  SOURCE_HOST='192.168.200.200', 
  SOURCE_USER='itcast',
  SOURCE_PASSWORD='Root@123456', 
  SOURCE_LOG_FILE='binlog.000004',
  SOURCE_LOG_POS=663;

The above is the syntax in 8.0.23. If mysql is a version earlier than 8.0.23, execute the following SQL:

The name of the knowledge parameter is different

CHANGE MASTER TO 
  MASTER_HOST='192.168.200.200', 
  MASTER_USER='itcast',
  MASTER_PASSWORD='Root@123456',
  MASTER_LOG_FILE='binlog.000004',
  MASTER_LOG_POS=663;

• Enable sync operation

start replica; #8.0.22之后
start slave; # 8.0.22之前

• View master-slave synchronization status

show replica status ; #8.0.22之后
show slave status ; #8.0.22之前

If the queried data is messy and not displayed in line, you can add \G after the operation command

show replica status\G ; #8.0.22之后
show slave status\G ; #8.0.22之前

If the red box below is Yes, it means the master-slave replication is normal

IOThread is used to read the binary log and write the content to the relay log

SQLThread is used to read the relay log and reflect the data to its own changes