mysql 5.7主从半同步复制（无损）
目录
指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。
一句话表示就是，主数据库做什么，从数据库就跟着做什么。
- 基于语句的复制 ：主库把sql语句写入到bin log中，完成复制
2.基于行数据的复制：主库把每一行数据变化的信息作为事件，写入到bin log，完成复制
3.混合复制：上面两个结合体，默认用语句复制，出问题时候自动切换成行数据复制
tip:和上面相对应的日志格式也有三种:STATEMENT，ROW，MIXED。
1.STATEMENT模式（SBR）
每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)
ROW模式（RBR）
不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。
MIXED模式（MBR）
以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。
- Master 数据库只要发生变化，立马记录到Binary log 日志文件中
2.Slave数据库启动一个I/O thread连接Master数据库，请求Master变化的二进制日志
3.Slave I/O获取到的二进制日志，保存到自己的Relay log 日志文件中。
4.Slave 有一个 SQL thread定时检查Realy log是否变化，变化那么就更新数据
确保数据相同
– 从库必须要有主库上的数据。
配置主服务器
– 启用 binlog 日志及设置格式,设置 server_id, 授权用户
配置从服务器
– 设置 server_id ,指定主数据库服务器信息
测试配置
– 客户端连接主库,写入的数据,在连接从库的时候也确保数据一致
写在主库配置文件里参数（对所有从库都有效）
[mysqld]
server-id = 1 #节点ID，确保唯一
binlog_do_db=库名列表 #允许同步的库,逗号拼接,写多行
binlog_ignore_db=库名列表 #不允许同步的库,逗号拼接,写多行
# log config
log-bin = mysql-bin #开启mysql的binlog日志功能
sync_binlog = 1 #控制数据库的binlog是否写磁盘 , 0 不写磁盘
binlog_format = mixed #binlog日志格式，mysql默认采用statement，建议使用mixed
expire_logs_days = 7 #binlog过期清理时间
max_binlog_size = 100m #binlog每个日志文件大小
binlog_cache_size = 4m #binlog缓存大小
max_binlog_cache_size= 512m #最大binlog缓存大
auto-increment-offset = 1 # 自增值的偏移量
auto-increment-increment = 1 # 自增值的自增量
slave-skip-errors = all #跳过从库错误
写在从库配置文件里参数（只针对从库本机有效）
replicate_do_db=库名列表 //指定只同步的库
replicate_ignore_db=库名列表 //指定不同步的库
relay-log = mysql-relay-bin
replicate-wild-ignore-table=mysql.%
replicate-wild-ignore-table=test.%
replicate-wild-ignore-table=information_schema.%
基本应用：
— 单项复制：一主一从
扩展应用：
— 一主多从
— 链式复制：主从从
— 主主（互为主从）
vi /etc/my.cnf
server-id = 2108 #保障唯一
log-bin = mysql-bin2108 #开启binlog日志，设置格式
binlog_format = "mixed" #设置日志格式
-
-
- 重启A（主库）mysql服务
-
systemctl restart mysqld
-
-
- 新增A（主库）MySQL的同步用户
-
[[email protected] ~]# mysql -uroot -p
mysql> use mysql;
mysql> grant replication slave on *.* to 'replUser'@'%' identified by '123456';
mysql> flush privileges;
-
-
- 查看A（主库）MySQL的日志文件，已经位置
-
mysql> show master status ;
-
-
- 在服务器B（从库）编辑my.cnf
-
vi /etc/my.cnf
server-id = 2109 #保障唯一
log_slave_updates #记录从库更新，允许链路复制
log-bin = mysql-bin2109 #开启binlog日志，设置格式
binlog_format = "mixed" #设置日志格式
-
-
- 重启服务器B（从库）mysql服务
-
systemctl restart mysqld
-
-
- 在服务器B（从库），配置同步进程
-
[[email protected] ~]# mysql -uroot -p
mysql>change master to master_host='192.168.2.108',master_user='replUser',master_password='123456',master_log_file='mysql-bin2108.000002',master_log_pos=311;
mysql> start slave;
mysql> show slave status \G;
-
-
- 在服务器A（主库），新建数据库 db2；并插入数据
-
mysql> create database db2;
mysql> use db2;
mysql> create table test(a int);
mysql> insert into test(a) values(111);
mysql> select * from test;
-
-
- 在服务器B（从库），查看mysql数据
-
-
-
- 把服务器B（从库），还原成独立的数据服务器
-
mysql> stop slave;
mysql> quit;
[[email protected] data]# rm -rf /var/lib/mysql/master.info
[[email protected] data]# rm -rf /var/lib/mysql/xiuba109-relay-bin.*
[[email protected] data]# rm -rf /var/lib/mysql/relay-log.info
[[email protected] data]# vi /etc/my.cnf
vi /etc/my.cnf
#server-id = 2109 #删除
#log_slave_updates #删除
#log-bin = mysql-bin2109 #删除
#binlog_format = "mixed" #删除
[[email protected] data]# systemctl restart mysql
复制模式介绍
• 异步复制( Asynchronous replication )
– 主库在执行完客户端提交的事务后会立即将结果返给客户端,并不关心从库是否已经接收并处理。
• 全同步复制( Fully synchronous replication )
– 当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端。
• 半同步复制( Semisynchronous replication )
– 介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到 relay log 中才返回给客户端
- 查看当前的数据库服务器是否支持动态加载模块
mysql> show variables like 'have_dynamic_loading';
- 使用命令安装模块，服务器A（主），服务器B（从）都完全安装
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
mysql> select plugin_name,plugin_status from information_schema.plugins where plugin_name like '%semi%';
- 启用半同步复制
mysql> set global rpl_semi_sync_master_enabled = 1;
mysql> set global rpl_semi_sync_slave_enabled = 1;
mysql> show variables like 'rpl_semi_sync_%_enabled';
- 配置写进配置文件使其永久生效
[[email protected] ~]# vi /etc/my.cnf
### 配置半同步复制模式
plugin-load=rpl_semi_sync_master=semisync_master.so
rpl_semi_sync_master_enabled=ON #或者设置为"1"，即开启半同步复制功能
rpl-semi-sync-master-timeout=1000 #超时时间为1000ms，即1s
plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=ON
[[email protected] ~]# systemctl restart mysql
- 半同步复制的原理
- 存在丢失数据风险
- MySQL 5.7半同步复制的改进
支持无损复制（Loss-less Semi-Synchronous）
在Loss-less Semi-Synchronous模式下，master在调用binlog sync之后，engine层commit之前等待Slave ACK（需要收到至少一个Slave节点回复的ACK后）。这样只有在确认Slave收到事务events后，master事务才会提交，然后把结果返回给客户端。此时此事务才对其他事务可见。在这种模式下解决了after_commit模式带来的幻读和数据丢失问题，因为主库没有提交事务。但也会有个问题，假设主库在存储引擎提交之前挂了，那么很明显这个事务是不成功的，但由于对应的Binlog已经做了Sync操作，从库已经收到了这些Binlog，并且执行成功，相当于在从库上多了数据，也算是有问题的，但多了数据，问题一般不算严重。这个问题可以这样理解，作为MySQL，在没办法解决分布式数据一致性问题的情况下，它能保证的是不丢数据，多了数据总比丢数据要好。
无损复制其实就是对semi sync增加了rpl_semi_sync_master_wait_point参数，来控制半同步模式下主库在返回给会话事务成功之前提交事务的方式。rpl_semi_sync_master_wait_point该参数有两个值：AFTER_COMMIT和AFTER_SYNC
- 支持无损复制原理
参考文献
https://www.cnblogs.com/kevingrace/p/10228694.html