#Word文档导入#Mysql主从部署

​

目录​

​​一、概述 2​​​

​​1.mysql主从复制原理 2​​​

​​2.复制架构 3​​​

​​二、安装mysql 5​​​

​​1.包下载方式 5​​​

​​三、基于binlog搭建主从复制 6​​​

​​1.一主一从配置 6​​​

​​2.新建用户授权 7​​​

​​3.测试 9​​​

​​4.基于 binlog 不影响业务搭建主从 9​​​

​​5.主从复制 binlog 格式 11​​​

​​6.主从复制过滤规则 12​​​

​​四、基于 GTID 搭建主从复制(5.7版本后建议使用此模式) 13​​​

​​1.基本配置 13​​​

​​2.主库开启GTID 14​​​

​​3.从库开启GTID 15​​​

​​4.在线增加从服务器 17​​​

​​五、双主复制 18​​​

​​1.主从都配置 18​​​

​​2.主库配置（基于GTID） 18​​​

​​3.双主防主键冲突 19​​​

​​六、复制方法 21​​​

​​1.多线程复制（从库配置） 21​​​

​​2.多源复制（多主单从） 23​​​

​​3同步复制和lossless无损复制 25​​​

推荐方案：GTID一主多从+半同步复制+keepalive+LVS+双VIP做读写分离方案​

一、概述​

1.mysql主从复制原理​

原理：​

步骤一：主库db的更新事件(update、insert、delete)被写到binlog​

步骤二：从库发起连接，连接到主库​

步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库​

步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.​

步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.​

​

1）master 节点上的 binlogdump 线程，在 slave 与其正常连接​

的情况下，将 binlog 发送到 slave 上。​

2）slave 节点的 I/O Thread ，通过读取 master 节点 binlog 日 志名称以及偏移量信息将其拷贝到本地 relay log 日志文件。​

3） slave 节点的 SQL Thread，该线程读取 relay log 日志信息， 将在 master 节点上提交的事务在本地回放，达到与主库数据保持一致的目的。​

2.复制架构​

应用场景：​

1）从服务器作为主服务器的实时数据备份​

当主服务器出现问题时，我们可以人工或设置自动切换到从服务器继续提供服务，此时从服务器的数据和宕机时的主数据库几乎是一致的。对于人为地执行 drop、delete 等语句删除数据的情况，从库的备份功能就没有用了，因为从服务器也会执行删除的语句。（mysql主库执行任何操作都实时同步到备库，主备都可读写。orcale复制技术datagaurd 主可读写，备只读不能写。）​

2）主从服务器实时读写分离，从服务器实现负载均衡​

主从服务器架构可通过程序（Javaweb等）或代理软件 （mysql‐proxy、mycat 等）实现对用户（客户端）的请求读写分离，即让从服务器仅仅处理用户的 select 查询请求，降低用户查询响应时间及读写同时在主服务器上带来的访问压力。对于更新的数据（例如 update、insert、delete 语句） 仍然交给主服务器处理，确保主服务器和从服务器保持实时同步。​

3）把多个从服务器根据业务重要性进行拆分访问​

二、安装mysql​

1.包下载方式​

https://downloads.mysql.com/archives/community/ ​

安装mysql​

复制以下4个rpm包​

​

如报错卸载yum remove mariadb-libs，卸载冲突包后再执行rpm –ivh *.rpm​

安装成功​

​

#rpm -ql mysql-community-server #查看安装后文件配置目录​

​

#systemctl start mysqld​

#systemctl enable mysqld​

#cat /var/log/mysqld.log | grep password #获取随机密码​

#mysql –uroot –p​

set password for root@localhost=password('G@inH0w2019') #修改密码​

grant all privileges on *.* to root@'%' identified by 'G@inH0w2019'; #授权​

三、基于binlog搭建主从复制​

1.一主一从配置​

#vim /etc/my.cnf​

#validate_password=OFF #验证密码强度（关闭）​

#character_set_server=utf8 #更改字符集为utf8​

#show variables like ‘%char%’; #查看字符集​

主库需开启binlog，备用不是必须的​

master：server-id = 101 #每个数据库Id唯一 ​

log-bin = mysql-bin #开启binlog日志​

slave：server-id = 102 #开启server-id 无需开启binlog​

show variables like '%log_bin%';​

下面log_bin ON #已经开启binlog​

#cd /var/lib/mysql/ #binlog文件和索引，每切换一次增长1​

​

2.新建用户授权​

# grant replication slave on *.* TO 'repl'@'%' identified by 'G@inH0w2019'; %代表任何追加都可以连接，主库建用户repl给备库连接用并指定 replication 权限​

#mysql -uroot -pG@inH0w2019​

#use mysql;​

#select user,host from user;​

# show master status; #主库运行，记下file和position 字段对应的参数。​

#change master to master_host='192.168.3.4',master_port=3306,master_user='repl',master_password='G@inH0w2019',master_log_file='mysql-bin.0000010',master_log_pos=154; #从库设置他的master​

#show slave status\G; #从库执行​

*************************** 1. row ***************************​

Slave_IO_State: ​

Master_Host: 192.168.1.92​

Master_User: repl​

Master_Port: 3306​

Connect_Retry: 60​

Master_Log_File: mysql-bin.000001 #文件​

Read_Master_Log_Pos: 437 #位置​

Relay_Log_File: db02-relay-bin.000001 #中继日志​

Relay_Log_Pos: 4​

Relay_Master_Log_File: mysql-bin.000001​

Slave_IO_Running: No #I/O线程​

Slave_SQL_Running: No #SQL线程​

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: 437​

Relay_Log_Space: 154​

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: NULL​

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: 0​

Master_UUID: ​

Master_Info_File: /var/lib/mysql/master.info #记录主库信息​

SQL_Delay: 0​

SQL_Remaining_Delay: NULL​

Slave_SQL_Running_State: ​

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​

Replicate_Rewrite_DB: ​

Channel_Name: ​

Master_TLS_Version:​

start slave;开启上面两个线程，可以看到Slave_IO_Running: Yes​

Slave_SQL_Running: Yes​

则配置成功。​

如果主库为一直为NO则可能两台主从数据库服务器UUID冲突​

# vim /var/lib/mysql/auto.cnf #修改任意数值两台不同即可​

改完后重mysqld，然后重新查看show master status; 重新执行change和start slave;​

3.测试​

Navicat新建库和表测试发现主建完成后从也有​

4.基于 binlog 不影响业务搭建主从​

A．原理：​

⑴ 原子性（Atomicity）​

⑵ 一致性（Consistency）​

⑶ 隔离性（Isolation）​

⑷ 持久性（Durability） ​

事务隔离级别:​

幻读是指同样一笔查询在整个事务过程中多次执行后，查询所得的结果集是不一样的。​

mysql默认隔离级别为可重复读​

#show variables like '%isolation%'; #查看隔离级别tx_isolation repeatable-read为可重复读​

B.搭建流程​

1）清除上面配置​

#stop slave #停从库​

#reset slave; #清除主库信息​

#cat /var/lib/mysql/master.info #查看主库信息发现没有信息，删除完成​

#show slave status\G; #状态NO​

#show variables like '%engine%'; #查看数据库存储引擎​

2）导入导出数据库​

@在从库远程登录主库导出数据​

#mysqldump -h 192.168.3.4 -uroot -pG@inH0w2019 --default-character-set=utf8 --databases test --single-transaction --master-data=2 > test.sql ​

‐‐master‐data=1 不注释 change master​

‐‐master‐data=2 注释 change master​

single‐transaction 使用可重复读隔离级别,可以保证数据的读一致性（导出过程中表写入数据不影响）。前提是mysql存储引擎是innodb​

@ #cat test.sql #导出后查看导出数据记录POS和FILE后面值​

@往新增的备库导入数据​

#mysql -uroot -pG@inH0w2019 --default-character-set=utf8 < test.sql​

@最后开启主从​

#change master to master_host='192.168.3.4',master_port=3306,master_user='repl',master_password='G@inH0w2019',master_log_file='mysql-bin.000006',master_log_pos=950; #从上图950往后区同步数据，如果start slave两个线程没起来，执行stop slave然后start slave开启。​

#start slave;​

可看到主备库已经同步成功​

5.主从复制 binlog 格式​

Mysql binlog 日志有三种格式：​

Statement,MIXED,以及 ROW 基于语句，混合模式（语句和列），和列模式​

# show variables like '%format%'; #默认格式为ROW​

vim my.cnf（在[mysqld]模块中配置）​

#binlog_format=STATEMENT​

#binlog_format=ROW​

#binlog_format=MIXED​

#show master status;​

#cd /var/lib/mysql #一定再此目录下执行下面指令​

#mysqlbinlog mysql-bin.000012 –v #binlog记录操作信息​

#mysqlbinlog mysql-bin.000012 -v --base64-output=DECODE-ROWS #binlog记录操作信息(去掉加密信息）​

做的update，insert，delete都会记录在这里，select不会记录在binlog​

在ROW模式会记录所有操作，如下。如果Statement模式就只记录一条指令​

6.主从复制过滤规则​

可以从master设置也可以从slave设置，一般建议在从库设置。​

参数：replicate_do_db 只应用指定的数据库,多个数据库 就写多行​

replicate_ingore_db 只忽略应用指定的数据库​

replicate_do_table 只应用指定的表​

replicate_ignore_table 只忽略指定的表 ​

replicate_wild_do_table 使用 wild 匹配来复制的​

指定表,比如参数设为 abc.%,表示复制 abc 的所有表。​

replicate_wild_ignore_table 使用 wild（通配符） 匹配来不复制​

的指定表,比如参数设为 abc.%,表示不复制 abc 的所有表。​

案例:​

@复制指定数据（从库配置）​

#vim /etc/my.cnf​

replicate-do-db = fxdb​

#show slave status\G;​

以下说明只复制fxdb数据库，不复制其他库，在test库新建表发现没复制则成功​

@复制指定数据库，但是排查其中的部分表​

#vim /etc/my.cnf​

replicate-do-db = fxdb​

replicate_ignore_table=fxdb.t2​

@排除通配符指定的表​

#vim /etc/my.cnf​

seplicate-do-db = fxdb​

replicate_wild_ignore_table=fxdb.abc%​

四、基于 GTID 搭建主从复制(5.7版本后建议使用此模式)​

1.基本配置​

GTID (Global Transaction ID)，也就是全局事务 ID, 其保证为​

每一个在 master 主上提交的事务在复制集群中可以生成一 个唯一的 ID​

# cat /var/lib/mysql/auto.cnf #查看UUID​

#show variables like '%uuid%'; #查看UUID第二种方法​

#show variables like '%gtid%'; #查看gtid是否开启​

# show variables like '%log_bin%';​

2.主库开启GTID​

#vim /etc/my.cnf #开启gtid​

server-id = 101 ​

log-bin = mysql-bin ​

gtid-mode = ON​

enforce-gtid-consistency = ON​

#systemctl restart mysqld #重启数据库后查看都已开启​

#grant replication slave,replication client on *.* TO 'repl'@'%' identified by 'G@inH0w2019'; #授予replication slave,replication client权限​

#show master status\G; #前面为uuid后面为事务ID​

@在线开启（不用重启数据库，但是my.cnf配置会没）​

set global enforce_gtid_consistency=ON;​

set global gtid_mode='ON';​

show variables like '%gtid%';​

3.从库开启GTID​

vim /etc/my.cnf​

gtid-mode = ON​

enforce-gtid-consistency = ON​

systemctl restart mysqld​

@查看gtid为开启状态​

@开启从库​

stop slave;​

# CHANGE MASTER TO MASTER_HOST='192.168.233.137',MASTER_USER='repl',MASTER_PASSWORD='G@inH0w2019',MASTER_AUTO_POSITION=1; 自动同步​

start slave;​

新建表发现数据库已经可以同步，GTID不再关心日志位置，自动同步​

1）在备库上清除主库信息​

清除备库mysql表中的gtid信息，清除一下图二为空。​

2）在从库远程备份主库表​

#mysqldump -h192.168.3.4 -uroot -pG@inH0w2019 --default-character-set=utf8 --databases fxdb --single-transaction --master-data=2 --triggers --routines --events > test.sql #触发器事件等一起导出​

#cat test.sql ​

以上显示1-4，导入数据库时候从第4个事务开始同步​

mysql -uroot -pG@inH0w2019 --default-character-set=utf8 < test.sql #导入后mysql库中GTID表中就有一个1-4的事务，后面同步从4开始​

3）测试​

@主库新建表显示从1-4变为1-5，从5开始，打开备库start slave;则新建的表已经同步过去​

#show master status\G;​

#show slave status\G; #也已经从5开始​

@查询GTID表则刚执行的事务从5开始​

4.在线增加从服务器​

A.binlog方式​

#mysqldump -h 192.168.3.4 -uroot -pG@inH0w2019 --default-character-set=utf8 --databases test --single-transaction --master-data=2 > test.sql​

#mysql -uroot -pG@inH0w2019 --default-character-set=utf8 < test.sql​

#mysql> change master to master_host='192.168.3.4',master_port=3306,master_user='repl',master_password='G@inH0w2019',master_log_file='mysql-bin.000006',master_log_pos=950;​

#start slave;​

B.GTID方式​

#mysqldump -h192.168.3.4 -uroot -pG@inH0w2019 --default-character-set=utf8 --databases fxdb --single-transaction --master-data=2 --triggers --routines --events > test.sql​

#mysql -uroot -pG@inH0w2019 --default-character-set=utf8 < test.sql​

#mysql> CHANGE MASTER TO MASTER_HOST='192.168.3.4',MASTER_USER='repl',MASTER_PASSWORD='G@inH0w2019',MASTER_AUTO_POSITION=1; #自动寻找​

#start slave;​

五、双主复制​

1.主从都配置​

主：#vim /etc/my.cnf​

auto_increment_increment=2​

auto_increment_offset=1​

从：#vim /etc/my.cnf​

auto_increment_increment=2​

auto_increment_offset=2​

#systemctl restart mysqld​

#show variables like '%auto%';​

# log-bin = mysql-bin #从库开启binlog（之前作为从不需要打开binlog，现在配置双主都需要打开）​

#grant replication slave,replication client on *.* TO 'repl'@'%' identified by 'G@inH0w2019'; #从库执行，授权一个账户从主库复制数据库​

2.主库配置（基于GTID）​

#stop slave #配置前stop，主库也需要stop slave;​

#CHANGE MASTER TO MASTER_HOST='192.168.3.2',MASTER_USER='repl',MASTER_PASSWORD='G@inH0w2019',MASTER_AUTO_POSITION=1; #如果配置基于binlog后面可修改​

#start slave;​

测试​

在主库和从库新建表两边都同步​

3.双主防主键冲突​

有多主时防止逐渐冲突步长设置原理​

主库​

auto_increment_offset=1 步长为1​

auto_increment_increment=2 从2开始​

从库​

auto_increment_offset=2 步长为2​

auto_increment_increment=2 从2开始​

1)主键冲突验证​

在数据库新建两个表，测试添加字段，发现两个主库新建表ID值都错开。​

2）停掉从库stop slave​

主库和从库都插入相同表字段，主库查看sql线程全部为停状态，并且提示主键冲突​

#show slave status\G; ​

3）解决主键冲突方法​

#show variables like '%gtid%';​

主从库都执行​

#stop slave;​

#set gtid_next='084bcbdb-513b-11eb-ac91-000c2938e5f7:6';​

#begin;commit;​

#set gtid_next=automatic;​

#start slave;​

#show slave status\G; #查看都变为正常​

六、复制方法​

1.多线程复制（从库配置）​

1）查看线程情况（当先状态为双主模式）​

#show processlist; #第一个是等待msater发送线程为IO线程，第二个是读取中继日志为SQL线程​

#show variables like '%parallel_workers%';# 查看是否开启多线程复制，为0没有开启，大于0开启​

#show variables like '%parallel%'; #查看并行复制方式，未修改前slave_parallel_type参数为DATABASE方式，需要修改为LOGICAL_CLOCK​

2）配置参数​

#vim /etc/my.cnf​

slave_parallel_type='LOGICAL_CLOCK' #（开启 MTS 功能后，会频繁更​

新 master.info，设置为 TABLE 减小开销）​

slave_parallel_workers=2 #对应CUP数​

master_info_repository=TABLE #默认为FILE，修改为TABLE​

relay_log_info_repository=TABLE #默认为FILE，修改为TABLE​

log_slave_updates=ON #如果不开启此参数执行start slave会提示开始报错​

与how slave status\G;查看的相关参数对应​

修改TABLE后文件都存在右侧对应表中，slave_master_info 记录了首次同步 master 的位置​

以下为优化参数，见另一个文档详解。​

relay_log_recovery=ON ​

slave_preserve_commit_order=ON​

查看设置参数是否成功，​

3）多线程参数总结​

从库配置​

stop slave​

slave_parallel_type='LOGICAL_CLOCK'​

slave_parallel_workers=1​

master_info_repository=TABLE​

relay_log_info_repository=TABLE​

relay_log_recovery=ON​

slave_preserve_commit_order=ON​

log_slave_updates=ON​

#systemctl restart mysqld​

start slave；​

注：以上设置对应参数都可在mysql库中找到和show slave status和show master status查到的信息相匹配。​

4）多线程复制工作原理​

开启多线程复制后​

第一条为IO线程（等待主库发送线程）都是一个线程​

第二条为读取中继日志（开启多线程前为SQL线程），开启后为协同（coordinator）线程​

最后两条线程是从协同线程发送来为工作（work）线程​

2.多源复制（多主单从）​

1）环境要求​

192.168.3.2 master-1​

192.168.3.4 master-2​

192.168.3.5 slave​

2）master-1配置​

server-id = 101​

log-bin = mysql-bin ​

gtid-mode = ON​

enforce-gtid-consistency = ON​

grant replication slave,replication client on *.* TO 'repl'@'%' identified by 'G@inH0w2019';​

3）master-2配置​

server-id = 102​

log-bin = mysql-bin ​

gtid-mode = ON​

enforce-gtid-consistency = ON​

grant replication slave,replication client on *.* TO 'repl'@'%' identified by 'G@inH0w2019';​

4）slave配置​

server-id = 103​

log-bin = mysql-bin ​

gtid-mode = ON​

enforce-gtid-consistency = ON​

如果没数据就直接change如果数据多需要先mysqldmup​

CHANGE MASTER TO MASTER_HOST='192.168.3.2',MASTER_USER='repl',MASTER_PASSWORD='G@inH0w2019',MASTER_AUTO_POSITION=1 FOR CHANNEL 'master-1'; ​

CHANGE MASTER TO MASTER_HOST='192.168.3.4',MASTER_USER='repl',MASTER_PASSWORD='G@inH0w2019',MASTER_AUTO_POSITION=1 FOR CHANNEL 'master-2'; ​

#start slave for channel 'master-1';​

#start slave for channel 'master-2'; ​

#如果执行失败报错误为“若要具有多个通道，存储库不能是文件类型; 请检查存储库配置并将其转换为表。”则需要把salve的my.cnf加入上面多线程复制中第1-3）内容把类型改为TABLE，重启数据后执行成功。​

master_info_repository=TABLE​

relay_log_info_repository=TABLE​

#use mysql #查看权限​

#select user,host from user;​

#grant all priviledges on *.* TO 'repl'@'%' identified by 'G@inH0w2019'; #授权root使可以远程连接​

#start slave; 开启后查看是否同步（如果启动失败则stop slave--reset slave—start slave）​

show slave status\G; #可查到通过master-1通道代表连接的是哪一个master​

show processlist; #可看到IO和SQL线程有两份分别对msater1和master2​

3同步复制和lossless无损复制​

原理：​

MySQL 的三种复制方式​

asynchronous 异步复制​

fully synchronous 全同步复制​

Semisynchronous 半同步复制​

1. 异步复制（asynchronous）​MySQL 默认的复制是异步的，主库在执行完客户端提交的事​
   务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果崩溃了，此时主上已经提交的事务可能并没有传到从上，如果此时，将从提升为主，可能导致新主上的数据不完整。原理：在异步复制中，master 写数据到 binlog 且 sync，slave request binlog 后写入 relay‐log 并刷新磁盘​
   优点：复制的性能最好​
   缺点：master 挂掉后，slave 可能会丢失数据​
   
2. 全同步复制（Fully synchronous replication）​
   指当主库执行完一个事务，所有的从库都执行了该事务才返​
   回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。​
   优点：数据不会丢失​
   缺点：会阻塞 master session，性能太差，非常依赖网络​
   
3. 半同步复制（Semisynchronous replication）​
   介于异步复制和全同步复制之间，主库在执行完客户端提交​
   的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度 的延迟，这个延迟最少是一个TCP/IP往返的时间。所以半同步复制最好在低延时的网络中使用。 ​
   优点：会有数据丢失风险（低）​
   缺点：会阻塞 master session，性能差，非常依赖网络，​
   由于 master 是在三段提交的最后commit阶段完成后才等待，所以master的其他session 是可以看到这个提交事务的，所以这时候master上的数据和 slave 不一致，master 崩溃后，slave数据丢失。​
   
4. 无损复制（lossless）（增强版的半同步复制）​

原理: 在半同步复制中，master 写数据到 binlog 且 sync，然 后一直等待 ACK. 当至少一个 slave request bilog后写入到 relay‐log 并刷新磁盘，就返回 ack（不需要回放完日志）​

优点：数据零丢失（前提是让其一直是 lossless replication），性能好。​

缺点：会阻塞 master session，非常依赖网络​

由于 master 是在三段提交的第二阶段 sync binlog 完成后才等待, 所以 master的其他 session 是看不见这个提交事务的， 所以这时候 master 上的数据和 slave 一致，master崩溃后，slave 没有丢失数据​

搭建无损复制：​

主库​

#show plugins; #查看可用插件​

#cd /usr/lib64/mysql/plugin #插件一个主库安装一个备库安装​

#show variables like '%dynamic%'; #查看是否支持动态加载的mysql服务器​

#install plugin rpl_semi_sync_master soname 'semisync_master.so'; #安装插件​

#show variables like '%rpl_semi%'; #查看安装插件修改以下参数 超时1000毫秒是10秒，​

#vim /etc/my.cnf​

rpl_semi_sync_master_enabled=1 #开启​

rpl_semi_sync_master_timeout=1000 #超时时间设置为1秒​

#systemctl restart mysqld​

#show variables like '%rpl_semi%'; #再次查看为开启状态​

#show status like '%semi%';​

#rpl_semi_sync_master_timeout 一个以毫秒为单位的值，用于控制主服务器等待来自从服务 器的确认提交并恢复到异步复制的时间，超过这个值就是超时。 默认值是 10000（10 秒）。超时之后，就从半同步复制，返回到异步复制。​

#Rpl_semi_sync_master_yes_tx​

从库成功确认的提交数量。​

#Rpl_semi_sync_master_no_tx​

从库未成功确认的提交数量。​

最底下记录数据库没操作一次增加数据或者删除就会增加1​

备库：​

#install plugin rpl_semi_sync_slave soname 'semisync_slave.so'; #安装​

#vim /ect/my.cnf​

rpl_semi_sync_slave_enabled = 1​

#systemctl restart mysqld​

# show variables like '%rpl_semi%';​

以上无损复制配置完毕。​

下面为测试步骤：​

1）测试 AFTER_SYNC 和 AFTER_COMMIT​

A．主库设置超时时间为 1000 秒，备库停掉复制，模拟 timeout set global rpl_semi_sync_master_timeout=1000000;​

B．备库 stop slave​

C．主库​

insert into t values('aaaa'); 卡住 再开一个窗口查询这条数据，发现查询不到。​

主库宕机。​

无损的半同步复制是在 write binlog 之后。需要得到备库的确 认。所以这时候主库宕机，不会发生丢数据。 当主库启动后，插入的数据重新可见。​

2）将 rpl_semi_sync_master_wait_point 设置为 AFTER_COMMIT， 再次测试:​

set global rpl_semi_sync_master_wait_point=AFTER_COMMIT;​

A.主库设置超时时间为1000 秒，备库停掉复制，模拟 timeout set global rpl_semi_sync_master_timeout=1000000;​

set global rpl_semi_sync_master_wait_point=AFTER_COMMIT;​

B.备库 stop slave;​

C.主库​

insert into t values('bbbb'); 卡住 再开一个窗口查询这条数据，发现可以查询到。 这时候主库宕机，会发生数据丢失。 主库重新启动，备库启动 slave 会同步到备库。​