MySQL database cluster combat --- MySQL semi-synchronous replication, fully synchronous replication (replicon)

A, MySQL replication

1.1 MySQL several sync pattern concept:

1、 Asynchronous replication (Asynchronous replication)

That is the default MySQL replication is asynchronous, the main library after the completion of the transaction execution submitted by the client will immediately return the results to the client, and does not care whether it has received treatment from the library, so there will be a problem, if the main crash out, the transaction at this time on the main library has been submitted may not be transferred from the library, if at this time, the main library will force the library to enhance, may lead to the data on the new primary database is incomplete.

2、Full Replication (Fully synchronous replication)

Means that when it returned to the client the main library executing the transaction, all of the libraries are executed the transaction. All because of the need to wait for completion of the transaction executed from the library to return, so the whole synchronous replication performance is bound to receive a serious impact.

3、Semi-synchronous replication (Semisynchronous replication)

From a multi-master mode, a successful return from the node, i.e. the success, without waiting for all of the plurality of nodes to return. Be between asynchronous replication and fully synchronous replication, the master database After you perform a transaction submitted by the client does not immediately returned to the client, but wait at least one received from the library to the relay log in and write it back to the client. With respect to the asynchronous replication, semi-synchronous replication improves data security, but it also caused some delay, the delay is at least a TCP / IP round trip time. Therefore, semi-sync is preferably used in the low-latency network.

Here Insert Picture Description

1.2 MySQL semi-synchronous replication technology

In general, an ordinary replication, namely MySQL asynchronous replication, rely on MySQL binary log that is binary log data replication. For example two machines, a host (Master), the other one is the slave (slave).

  • Normal replication are:A transaction (t1) written binlog buffer; dumper thread notifies slave new transaction t1; binlog buffer conduct checkpoint; slave of io thread receives t1 and written to own a relay log; slave is written to the local sql thread database. At this time, master and slave can see this new transaction, even if the master hanging, slave can be promoted to a new master.

  • Abnormal copy to:A transaction (t1) written binlog buffer; dumper thread notifies slave new transaction T1; binlog
    Buffer conduct checkpoint; slave because the network is unstable, we have not received t1; master hang up, promoted to the new slave master, t1 loss .

  • The big question is: And a host of sync updates from machine transactions, even if there is no other network or system anomalies, when the service concurrent up, slave master batch to be executed since the transaction sequence, resulting in significant delays.

In order to compensate for the lack of more than a few scenes, MySQL 5.5 launched from a semi-synchronous replication. Compared asynchronous replication, semi-synchronous replication improves data integrity, because it is clear to know,After a successful transaction commits, the transaction will be present in at least two places. That is, after the dumper thread notifies slave master, adds an ack (acknowledgment message), that is, whether t1 successfully received the flag code, which is in addition to sending dumper thread t1 to the slave, also assumed the work ack of receiving slave.If an exception occurs, do not receive ack, it will automatically be downgraded to an ordinary copy, abnormal repair until then will automatically become semi-synchronous replication. MASTER means that only one of which receives the return information SLAVE, will commit; otherwise, wait until the timeout is then switched to the asynchronous submit.

Specific properties of semi-sync 1.3

Library to produce master binlog binlog File primary library, from the library spread relay log, and from the database application; that is transmitted is asynchronous, the application also asynchronous. Semi-synchronous replication refers to transmission synchronous, asynchronous or application!

  • Libraries will tell when connected to the main library from the main library, it is configured in the semi-synchronous.
  • If the semi-synchronous replication in the master side is opened, and there is at least a semi-synchronous replication from the library nodes, then the transaction thread main library will be blocked and waiting when submitting results, there are two possibilities, either at least it has received a notice from the library node Binlog all events this transaction, or waits until the configuration of more than a certain point in time, but this time, semi-synchronous replication will automatically shut down, converted to asynchronous replication.
  • Only after all Binlog received one transaction, it is written from the library node and Flush to Relay Log files, correspondence will notify waiting thread above the main library.
  • If the waiting, the waiting time has exceeded the timeout time, without any notice from the current transaction nodes, then the main library will be automatically converted to asynchronous replication, when at least a semi-synchronous come up from the node, the main library it will be automatically converted to semi-synchronous replication mode.
  • Semi-synchronous replication and the job must be opened from both ends of the library are the main libraries, the main library or use the default asynchronous replication.

Second, the semi-synchronous replication configuration

The plug-ins installed in the database is a temporary exit will re-login failure, permanent write can be configured in the configuration file
Experimental environment: Based on the basis of asynchronous replication

1、 On server1 (master node)

1 | INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 安装半同步模块
2 |	SELECT PLUGIN_NAME, PLUGIN_STATUS 
		   FROM INFORMATION_SCHEMA.PLUGINS 
		   WHERE PLUGIN_NAME LIKE '%semi%'; 查看插件
3 | SET GLOBAL rpl_semi_sync_master_enabled = 1; 开启半同步,也就是激活插件

Here Insert Picture Description

2、On server2 (slave node)

1 | INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';  安装半同步插件
2 | SET GLOBAL rpl_semi_sync_slave_enabled =1; 激活插件
3 | STOP SLAVE IO_THREAD; 重启IO线程使半同步生效
4 | START SLAVE IO_THREAD;
  • Io restart the process from the library, then activate the plugin io must restart the process, they will not take effect, if not restart, then it means the data is not synchronized across

Here Insert Picture Description

3, on server1 (master node) to view the status of variables and values:

mysql> show status like '%rpl%'; 查看变量的状态
mysql> show variables like '%rpl%'; 查看变量的值
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
		### 是否开启半同步
| rpl_semi_sync_master_timeout              | 10000      | 
		###切换复制的timeout
| rpl_semi_sync_master_trace_level          | 32         | 
		###用于开启半同步复制模式时的调试级别,默认是32
| rpl_semi_sync_master_wait_for_slave_count | 1          |
		###至少有N个slave接收到日志
| rpl_semi_sync_master_wait_no_slave        | ON         |
		###是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on 
| rpl_semi_sync_master_wait_point           | AFTER_SYNC | 
		###等待的point
| rpl_stop_slave_timeout                    | 31536000   |
+-------------------------------------------+------------+    
		###控制stop slave 的执行时间,在重放一个大的事务的时候,突然执行stop slave,命令 
		###stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能


Here Insert Picture Description

Here Insert Picture Description

4, in the slave node,

mysql> show variables like '%rpl%'; 查看变量的值

Here Insert Picture Description

5、test:
1)server2 close io process: STOP SLAVE IO_THREAD;
2) on server1,

use ranran;
insert into usertb values ('user00','123');

Waiting for the master repository 10s, 10s when a request is not received ack slave, the master database is automatically converted to asynchronous replication.
Here Insert Picture Description
Check the semi-synchronous state is off, the transaction is to be synchronized 1
Here Insert Picture Description
A 10-second delay, which is due to the closure of the io process from the library and can not write data; wait 10 seconds after the main library from the library not up yet, wait no longer write directly to the main library

3) Insert data again found to be particularly fast, at this time has become asynchronous, and the master is switched to the asynchronous library from the library after a not care .
Here Insert Picture Description

4)server2开启io进程:START SLAVE IO_THREAD;
5)输出结果显示了有哪些线程在运行:show processlist;

id列:一个标识
user列: 显示当前用户,如果不是root,这个命令就只显示你权限范围内的sql语句
host列:显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户
db列:显示这个进程目前连接的是哪个数据库
command列:显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)
time列:此这个状态持续的时间,单位是秒
state列:显示使用当前连接的sql语句的状态

Here Insert Picture Description
6)查看表信息,已经复制过来,只要从库的io进程恢复工作就会立即同步没有同步的数据

Here Insert Picture Description

三、全同步复制(组复制)

1、全同步复制(组复制)的基本概念

  • 组复制模型:
    它支持单主模型和多主模型两种工作方式(默认是单主模型)
    单主模型: 从复制组中众多个MySQL节点中自动选举一个master节点,只有master节点可以写,其他节点自动设置为read only。当master节点故障时,会自动选举一个新的master节点,选举成功后,它将设置为可写,其他slave将指向这个新的master。
    多主模型: 复制组中的任何一个节点都可以写,因此没有master和slave的概念,只要突然故障的节点数量不太多,这个多主模型就能继续可用
  • 组复制原理:
    组复制由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务,但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。

2、配置组复制

实验环境

主机名 IP 功能
server1 172.25.7.1 master节点
server2 172.25.7.2 slave节点
server3 172.25.7.3 slave节点

在server1上
1、关闭mysqld :systemctl stop mysqld
2、查看UUID:cat /var/lib/mysql/auto.cnf
3、删除mysql数据:rm -fr /var/lib/mysql/*

  • 注意:删除数据之前先复制uuid,三个节点的uuid使用同一个值,而且不能与三个节点自身的uuid相同
    Here Insert Picture Description

4、修改配置文件 vim /etc/my.cnf

  • binlog_checksum=NONE :关闭binlog校验
  • binlog_format=ROW :组复制依赖基于行的复制格式
  • loose-group_replication_bootstrap_group=off :插件是否自动引导,这个选项一般都要off掉,只需要由发起组复制的节点开启,并只启动一次,如果是on,下次再启动时,会生成一个同名的组,可能会发生脑裂
  • 开启多主模式的参数
    loose-group_replication_enforce_update_everywhere_checks=ON
    loose-group_replication_single_primary_mode=OFF

Here Insert Picture Description
5、 开启数据库 systemctl start mysqld ,再次安全初始化:mysql_secure_installationHere Insert Picture Description
6、登录数据库并配置组复制


mysql> SET SQL_LOG_BIN=0;
	##关闭二进制日志
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'Westos==123';
	##创建用户
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
	##用户授权
mysql> FLUSH PRIVILEGES;
	##刷新用户授权表
mysql> SET SQL_LOG_BIN=1;
	##开启二进制日志

Here Insert Picture Description

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', 
	MASTER_PASSWORD='Westos==123', 
	FOR CHANNEL 'group_replication_recovery';
	##配置用户
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
	##安装组复制插件
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
	##在第一个节点上要先打开一次
mysql> START GROUP_REPLICATION;
	##开启组复制
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
	##关闭组复制激活
mysql> SELECT * FROM performance_schema.replication_group_members;
	##查看当前组的状态,是否为online

Here Insert Picture Description

Here Insert Picture Description

Here Insert Picture Description

Here Insert Picture Description

在server2和server3上配置
7、关闭mysql服务: systemctl stop mysqld
8、删除数据目录的内容:rm -fr /var/lib/mysql/*
9、编辑配置文件vim /etc/my.cnf,重启服务systemctl start mysqld

  • Change only server-id and loose-group_replication_local_address

Here Insert Picture Description

Here Insert Picture Description

10, see the temporary password grep password /var/log/mysqld.log, Security initialization mysql_secure_installationHere Insert Picture Description
11, Log database: mysql -uroot -pWestos == 123


CREATE USER rpl_user@'%' IDENTIFIED BY 'Westos==123';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='Yan+123kou' FOR CHANNEL 'group_replication_recovery';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;

Here Insert Picture Description
Here Insert Picture Description
At this open group replication, we found an error, view the log: cat /var/log/mysqld.log

Here Insert Picture Description

Here Insert Picture Description

12, once again log into the database,

STOP GROUP_REPLICATION;
set global group_replication_allow_local_disjoint_gtids_join=on;
START GROUP_REPLICATION;

Here Insert Picture Description

13, after configured on server1 View,
SELECT * FROM performance_schema.replication_group_members;
Here Insert Picture Description
14, the same modifications profile on server3
Here Insert Picture Description

Here Insert Picture Description

Here Insert Picture Description

14, server2 and configured after server3 On server1 View,
SELECT * FROM performance_schema.replication_group_members;
Online three are seen, indicating a normal, then the write data in any node, the other nodes can see.

Here Insert Picture Description

15、test
Inserting data on server1:

Here Insert Picture Description

It can be seen in the data inserted on server1 server3, and data may be inserted.

Here Insert Picture Description

Here Insert Picture Description
You can see, has achieved a set of replication, a write data at any node, the other two nodes will be set to copy

Published 102 original articles · won praise 21 · views 5329

Guess you like

Origin blog.csdn.net/ranrancc_/article/details/102899646