Mysql master-slave replication, read-write separation

In enterprise applications, mature businesses usually have large amounts of data. A single MySQL cannot meet actual needs in terms of security, high availability, and high concurrency. Multiple master-slave database servers are configured to achieve read-write separation.

2. Master-slave replication principle

2.1 MySQL replication types

Statement-based replication (STATEMENT, MySQL default type)

Row-based replication (ROW)

Mixed type copy (MIXED)

2.2 The working process of MySQL master-slave replication

(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.

⭐⭐ Two logs, three threads

Binary log: the log file of the primary database

Relay log: log file from database

Dump thread: Receive and process Slave’s read request

I/O thread: Send requests to Dump and read and write relay logs

SQL thread: read the data in the relay log and write and save it to the slave database

2.2.1 MySQL master-slave replication delay

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

2. Network delay

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

4. 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.

2.3 MySQL three data synchronization methods

1. Async Replication

2. Synchronous Replication (sync Replication)

3. Async Replication

4. Enhanced semi-synchronous replication (lossless Semi-Sync Replication) and lossless replication

2.3.1. 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.

2.3.2. 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.

2.3.3. 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.

2.3.4. 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. .

2.4 The direction of mysql architecture evolution

1. A single MySQL server has a single point of failure.

2. Cluster---》Master-slave replication

3. The pressure of master-slave copying across the river is uneven

4. Separation of reading and writing

5. The basis of read-write separation is master-slave replication

6. MySQL’s high availability architecture MHA (master HA high availability) MGR MMM

3. Master-slave replication experiment

Environment deployment cetos7.6

Virtual machine service environment

Master server:192.168.181.100 mysql5.7

slave1 server:192.168.181.101 mysql5.7

Slave2 server:192.168.181.102 mysql5.7

Amoeba server:192.168.181.103 (preparatory machine) jdk1.6

Client server:192.168.181.1 test

3.1. Master-slave server time synchronization

① Install ntp and modify configuration files

[root@master ~]# yum install ntp -y
[root@master ~]# vim /etc/ntp.conf
[root@master ~]# yum -y install ntpdate ntp    #安装ntp软件
[root@master ~]# ntpdate ntp.aliyun.com        #时间同步
[root@master ~]# vi /etc/ntp.conf                   #编辑配置文件
fudge 127.127.1.0 stratum 10
#设置本机的时间层级为10级，0级表示时间层级为0级，是向其他服务器提供时间同步源的意思，不要设置为0级

server 127.127.1.0    #设置本机为时间同步源

② Turn on NTP service, turn off firewall and enhance security functions

[root@master ~]# systemctl start ntpd
[root@master ~]# systemctl stop firewalld.service 
[root@master ~]# setenforce 0

3.1.2 Configuration of two SLAVE servers

① Install ntp and ntpdate services

[root@localhost ~]# yum install ntp ntpdate -y

② Turn on the ntp service, turn off the firewall and enhance security functions

③ Time synchronization master server

[root@localhost ~]# ntpdate 192.168.181.100

④ The two slave servers have the same configuration

#master服务器同步阿里云时钟服务器
ntpdate ntp.aliyun.com
ntpdate 192.168.181.100
crontable -e
*/10 * * * * /usr/sbin/ntpdate 192.168.181.100

3.2. Manual compilation and installation of MySQL (ignored here)

........Omit some content, please refer to mysql compilation and installation for details.

Three MySQLs are compiled and installed manually at the same time

3.3. Configure master-slave synchronization

① Modify the configuration file of the master server

[root@master ~]# vi /etc/my.cnf
#在mysqld模块下修改一下内容
#开启二进制日志文件（之后生成的日志名为master-bin）
log_bin=master-bin
#开启从服务器日志同步
log_slave-updates=true
#主服务器id为1（不可重复）
server_id = 1
--------》wq

重启服务
[root@master ~]# systemct restart mysqld

配置规则
[root@master ~]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.

mysql> GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.181.%' IDENTIFIED BY '123123';
Query OK, 0 rows affected (0.00 sec)

#刷新权限表
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)


规则解析：GRANT REPLICATION SLAVE ON *.* TO ‘myslave’@‘192.168.181.%’ IDENTIFIED BY ‘123123’;

给从服务器提权，允许使用slave的身份复制master的所有数据库的所有表，并指定密码为123456

查看master数据库状态
mysql> show master status;
+-------------------+----------+--------------+------------------+-------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000001 |      412 |              |                  |                   |
+-------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

mysql> 
#以上可见产生了master-bin.000001日志文件，定位为412
#从服务器需要定位到此处进行复制

② Configure from server

[root@slave1 ~]# vi /etc/my.cnf
#开启二进制日志文件
log-bin=master-bin
#设置server id为22，slave2 为23
server_id = 22
#从主服务器上同步日志文件记录到本地
relay-log=relay-log-bin
#定义relay-log的位置和名称（index索引） 
relay-log-index=slave-relay-bin.index
--------》wq

log_bin=master-bin
server_id = 22
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index




开启从服务器功能
[root@slave1 ~]# mysql -uroot -p
...............
mysql> change master to master_host='192.168.181.100',master_user='myslave',master_password='123123',master_log_file='master-bin.000001',master_log_pos=603;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

change master to master_host='192.168.181.100',master_user='myslave',master_password='123123',master_log_file='master-bin.000003',master_log_pos=603;

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

查看从服务器状态
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.181.100
                  Master_User: myslave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-bin.000001
          Read_Master_Log_Pos: 412
               Relay_Log_File: relay-log-bin.000002
                Relay_Log_Pos: 284
        Relay_Master_Log_File: master-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 412
              Relay_Log_Space: 455
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 11
                  Master_UUID: c59043ec-5ad8-11ea-b895-000c29fe085b
             Master_Info_File: /home/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)

同理、开启另一台从服务器同步

3.4. Test data synchronization

Create a database on the main server

mysql> create database work;
Query OK, 1 row affected (0.00 sec)

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| work               |
+--------------------+
5 rows in set (0.00 sec)

View the database list directly on the two slave servers

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| work               |
+--------------------+
5 rows in set (0.00 sec)

以上，主从同步复制配置完成

4. MySQL read and write separation

4.1. What is read-write separation? (what)

The basic principle of read-write separation is to let the master database handle transactional add, modify, and delete operations (INSERT, UPDATE, and DELETE), while the slave database handles SELECT query operations. Database replication is used to synchronize changes caused by transactional operations to slave databases in the cluster.

4.2. Why should reading and writing be separated? (why)

Because the "write" operation of the database (it may take 3 minutes to write 10,000 pieces of data) is relatively time-consuming. But the "read" of the database (reading 10,000 pieces of data may only take 5 seconds). Therefore, the separation of reading and writing solves the problem that writing to the database affects the efficiency of queries.

4.3. When should reading and writing be separated? (when)

The database does not necessarily need to be separated from reading and writing. If the program uses the database a lot, updates less, and queries a lot, it will be considered. Using database master-slave synchronization and separation of reading and writing can share database pressure and improve performance.

4.4. Master-slave replication and read-write separation

In an actual production environment, reading and writing the database are in the same database server, which cannot meet actual needs. Whether it is in terms of security, high availability or high concurrency, it is completely unable to meet actual needs. Therefore, data is synchronized through master-slave replication, and the concurrent load capacity of the database is improved through read-write separation. It is somewhat similar to rsync, but the difference is that rsync backs up disk files, while mysql master-slave replication backs up data and statements in the database.

4.5. MySQL read-write separation principle

The separation of reading and writing means writing only on the master server and reading only on the slave server. The basic principle is to let the master database handle transactional operations, while the slave database handles select queries. Database replication is used to synchronize changes caused by transactional operations on the master database to the slave databases in the cluster.

4.6. Enterprise uses MySQL read-write separation scenario

Currently, the more common MySQL read-write separation is divided into the following two types:

1) Internal implementation based on program code

In the code, routing is classified based on select and insert. This method is currently the most widely used in production environments. The advantage is that the performance is better, because it is implemented in the program code, and there is no need to add additional equipment for hardware expenses; the disadvantage is that it requires developers to implement it, and operation and maintenance personnel have no way to start. However, not all applications are suitable for implementing read-write separation in program code. For example, in some large and complex Java applications, if read-write separation is implemented in program code, the code changes will be larger.

2) Implemented based on the intermediate proxy layer

The proxy is generally located between the client and the server. After receiving the client's request, the proxy server will forward it to the back-end database through judgment. The following representative procedures are available. (1)MySQL-Proxy. MySQL-Proxy is a MySQL open source project that performs SQL judgment through its own lua script. (2) Atlas. It is a data middle layer project based on the MySQL protocol developed and maintained by the infrastructure team of Qihoo 360's Web Platform Department. It is based on mysql-proxy version 0.8.2, has been optimized and added some new features. 360 internally uses Atlas to run its mysql business, which handles billions of read and write requests every day. Supports transactions and stored procedures. (3)Amoeba. Developed by Chen Siru, the author once worked at Alibaba. The program is developed in Java language and Alibaba uses it in the production environment. But it does not support transactions and stored procedures.

Since using MySQL Proxy requires writing a large number of Lua scripts, these Lua scripts are not ready-made and need to be written by yourself. This is very difficult for people who are not familiar with the MySQL Proxy built-in variables and the MySQL Protocol. Amoeba is a very easy-to-use and highly portable software. Therefore it is widely used in production environments as the proxy layer of databases.

5. Reading and writing separation experiment

The environment and server information of the entire experiment

Environment deployment cetos7.6

Virtual machine service environment Master server: 192.168.181.100

slave1 server:192.168.181.101

Slave2 server:192.168.181.102

Amoeba server:192.168.181.103 jdk1.6, Amoeba

Client server:192.168.181.1 mysql test

Note: There must be a master and two slave environments before doing the read-write separation experiment.

5.1 Set up MySQL reading and writing separation

5.1.1 Amoeba server configuration

##安装 Java 环境##
因为 Amoeba 基于是 jdk1.5 开发的，所以官方推荐使用 jdk1.5 或 1.6 版本，高版本不建议使用。
cd /opt/
cp jdk-6u14-linux-x64.bin /usr/local/
cd /usr/local/
chmod +x jdk-6u14-linux-x64
./jdk-6u14-linux-x64.bin
//按yes，按enter

mv jdk1.6.0_14/ /usr/local/jdk1.6

vim /etc/profile
export JAVA_HOME=/usr/local/jdk1.6
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/lib:$JAVA_HOME/jre/bin/:$PATH:$HOME/bin
export AMOEBA_HOME=/usr/local/amoeba
export PATH=$PATH:$AMOEBA_HOME/bin

source /etc/profile
java -version

##安装 Amoeba软件##
mkdir /usr/local/amoeba
tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
chmod -R 755 /usr/local/amoeba/
/usr/local/amoeba/bin/amoeba
//如显示amoeba start|stop说明安装成功

##配置 Amoeba读写分离，两个 Slave 读负载均衡##
#先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问
grant all on *.* to test@'192.168.181.%' identified by '123123';

#再回到amoeba服务器配置amoeba服务：
cd /usr/local/amoeba/conf/

cp amoeba.xml amoeba.xml.bak
vim amoeba.xml									#修改amoeba配置文件
--30行--
<property name="user">amoeba</property>
--32行-- 
<property name="password">123456</property>
--115行--
<property name="defaultPool">master</property>
--117-去掉注释-
<property name="writePool">master</property>
<property name="readPool">slaves</property>

cp dbServers.xml dbServers.xml.bak
vim dbServers.xml								#修改数据库配置文件
--23行--注释掉  作用：默认进入test库 以防mysql中没有test库时，会报错
<!-- <property name="schema">test</property> -->
--26--修改
<property name="user">test</property>
--28-30--去掉注释
<property name="password">123123</property>
--45--修改，设置主服务器的名Master
<dbServer name="master"  parent="abstractServer">
--48--修改，设置主服务器的地址
<property name="ipAddress">192.168.181.101</property>
--52--修改，设置从服务器的名slave1
<dbServer name="slave1"  parent="abstractServer">
--55--修改，设置从服务器1的地址
<property name="ipAddress">192.168.181.102</property>
--58--复制上面6行粘贴，设置从服务器2的名slave2和地址
<dbServer name="slave2"  parent="abstractServer">
<property name="ipAddress">192.168.181.100</property>
--65行--修改
<dbServer name="slaves" virtual="true">
--71行--修改
<property name="poolNames">slave1,slave2</property>


/usr/local/amoeba/bin/amoeba start&					#启动Amoeba软件，按ctrl+c 返回
netstat -anpt | grep java							#查看8066端口是否开启，默认端口为TCP 8066

5.1.2 Test read and write separation

#先安装数据库
yum install -y mariadb-server mariadb
systemctl start mariadb.service
在客户端服务器上测试
mysql -u amoeba -p123456 -h 192.168.181.1 -P8066		
//通过amoeba服务器代理访问mysql ，在通过客户端连接mysql后写入的数据只有主服务会记录，然后同步给从--从服务器

在主服务器上：
use db_test;
create table test (id int(10),name varchar(10),address varchar(20));

在两台从服务器上：
stop slave;											#关闭同步
use db_test;
//在slave1上：
insert into test values('1','zhangsan','this_is_slave1');

//在slave2上：
insert into test values('2','lisi','this_is_slave2');

//在主服务器上：
insert into test values('3','wangwu','this_is_master');

//在客户端服务器上：
use db_test;
select * from test;		//客户端会分别向slave1和slave2读取数据，显示的只有在两个从服务器上添加的数据，没有在主服务器上添加的数据

insert into test values('4','qianqi','this_is_client');		//只有主服务器上有此数据

//在两个从服务器上执行 start slave; 即可实现同步在主服务器上添加的数据
start slave;