Centos mysql5.7 主从复制之无损复制，增强版的半同步复制（ lossless replication ）单向同步

mysql 有四种同步方式：

1.异步复制（ asynchronous replication）
原理：在异步复制中，master写数据到binlog且sync，slave request binlog后写入relay-log并flush disk
优点：复制的性能最好，搭建简单，使用非常广泛，从mysql 诞生之初，就产生了这种架构，性能非常好，非常成熟。
缺点：但这种架构是异步，master挂掉后，slave可能会丢失事务，所以有数据丢失的风险。
代表：MySQL原生的复制

2.全同步复制（ fully synchronous replication）
原理：在全同步复制中，master写数据到binlog且sync，所有slave request binlog后写入relay-log并flush disk，并且回放完日志且commit
优点：保证数据安全，数据不会丢失
缺点：会阻塞master session，损失性能，性能太差，非常依赖网络
代表：MySQL-Cluster

3.传统半同步复制（ Semi synchronous replication）
原理: 在半同步复制中，master写数据到binlog且sync，且commit，然后一直等待ACK。当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志）
优点：会有数据丢失风险（低）
缺点：会阻塞master session，性能差，非常依赖网络，
代表：after commit, 原生的半同步
重点：由于master是在三段提交的最后commit阶段完成后才等待，所以master的其他session是可以看到这个提交事务的，所以这时候master上的数据和slave不一致，master crash后，slave数据丢失
总结：性能，功能都介于异步和全同步之间。从mysql5.5开始诞生，折中上述两种架构的性能及优缺点。

4.无损复制，增强版的半同步复制（ lossless replication ）
原理: 在半同步复制中，master写数据到binlog且sync，然后一直等待ACK. 当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志），mysql5.7诞生。
优点：数据零丢失（前提是让其一直是lossless replication），性能好
缺点：会阻塞master session，非常依赖网络
代表：after sync, 原生的半同步
重点：由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的，所以这时候master上的数据和slave一致，master crash后，slave没有丢失数据

无损复制，增强版的半同步复制（ lossless replication ）参数介绍

参数	comment	默认值	推荐值	是否动态
rpl_semi_sync_master_wait_for_slave_count	至少有N个slave接收到日志	1	1	dynamic
rpl_semi_sync_master_wait_point	等待的point	AFTER_SYNC	AFTER_SYNC	dynamic
rpl_semi_sync_master_timeout	切换复制的timeout	10000（10s）	1000(1s)	dynamic
rpl_semi_sync_master_enabled	是否开启半同步	OFF	ON	dynamic
rpl_semi_sync_slave_enabled	是否开启半同步	OFF	ON	dynamic

########semi sync replication settings########
plugin_dir=/usr/local/mysql/lib/plugin  #可不设置 若设置需要把插件放到此路径下 。建议不设置。
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"  #加载插件
loose_rpl_semi_sync_master_enabled = on    #开启主库的版同步复制
loose_rpl_semi_sync_slave_enabled = on #开启从库的半同步复制
loose_rpl_semi_sync_master_timeout = 1000  #超时1秒，切换回异步。默认为10000

开始

准备两台服务器安装mysql 完成后可以远程连接
主服务器ip 192.168.1.111
从服务器ip 192.168.1.112

1.主从服务器分别执行

vi /etc/my.cnf

2.主库my.cnf 添加参数

server_id =111      #服务ID *必须设置
log_bin=mysql-bin #开启二进制日志 *必需设置
expire_logs_days=15  #binlog保留多少天，选择设置，默认0
binlog_cache_size=1M            #binlog缓存的大小，选择设置，默认32k
max_binlog_size=2048M   #binlog日志每达到设定大小后，会使用新的bin log日志。如mysql-bin.000002 。 默认2097152GB
binlog_do_db=test               #需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
binlog-ignore-db=mysql     #不需要复制的数据库苦命，如果复制多个数据库，重复设置这个选项即可
log_bin_trust_function_creators =on     #同步函数和存储过程 默认为0
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"   #加载插件
loose_rpl_semi_sync_master_enabled = on #开启主库无损复制
loose_rpl_semi_sync_master_timeout = 1000       #切换复制的timeout，半同步

3.从库my.cnf 添加参数

server_id =112      #服务ID *必须设置
log_bin=mysql-bin #开启二进制日志     *非必需
expire_logs_days=15  #binlog保留多少天，选择设置，默认0
binlog_cache_size=1M       #binlog缓存的大小，选择设置，默认32k
max_binlog_size=2048M      #binlog日志每达到设定大小后，会使用新的bin log日志。如mysql-bin.000002 。 默认2097152GB
log_bin_trust_function_creators =on    #同步函数和存储过程 默认为0
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"      #加载插件
loose_rpl_semi_sync_slave_enabled = on #开启从库无损复制

4.分别重启主从库服务

  systemctl restart mysqld.service

我是用Navicat连接
5.分别查看主从配置是否生效

mysql> show variables like '%server_id%';  #查询配置文件的server_id

6.查看相关的插件

mysql> show plugins

7.查看相关设置参数

show global variables like '%semi%';

#可通过 set global variale_name = value设置对应的参数

创建复制用户

1.主库创建复制用户

mysql> GRANT REPLICATION SLAVE ON *.* TO  'repl'@'%' identified by '123456';

#若是提示设置密码级别不够，先执行下面语句在执行上面语句（密码级别够高请飘过！！）

mysql >set global validate_password_policy=0;
mysql> set global validate_password_length=1;

2.用户授权

mysql> grant replication client, replication slave on *.*   to 'repl'@'%'

3.刷新

msysql > flush privileges;

4.查看创建用户

mysql> select user,host from mysql.user;

5.查看授权

mysql> show grants for 'repl'@'%';

在从库上使用slave 与master repl账号建立连接

1.在主库执行

msysql >show master status;

2.在从库执行

msysql> stop slave    #停止从服务与主服务同步（）
msysql> change master tomaster_host='192.168.1.111',  #主服务ipmaster_port=3306,    #主服务端口master_user='repl',    #主服务用户名master_password='123456', #主服务密码master_log_file='mysql-bin.000001', #与上面结果对应master_log_pos=154;#与上面结果对应
msysql> start slave  #启动与主服务同步

3.从库执行查看

msysql> show slave status

#下面参数都为yes

4.主库查看进程


msysql > show processlist;       #查看进程

确认是同步还是半同步

参数说明：

Rpl_semi_sync_master_clients                        有多少个Semi-sync的备库
Rpl_semi_sync_master_net_avg_wait_time              事务提交后，等待备库响应的平均时间
Rpl_semi_sync_master_net_wait_time                  等待网络响应的总次数
Rpl_semi_sync_master_net_waits                      总的网络等待时间
Rpl_semi_sync_master_no_times                       一共有几次从Semi-sync跌回普通状态
Rpl_semi_sync_master_no_tx                          库未及时响应的事务数,如果这个值很大就有问题
Rpl_semi_sync_master_status                         主库上Semi-sync是否正常开启
Rpl_semi_sync_master_timefunc_failures              时间函数未正常工作的次数
Rpl_semi_sync_master_tx_avg_wait_time               开启Semi-sync，事务返回需要等待的平均时间
Rpl_semi_sync_master_tx_wait_time                   事务等待备库响应的总时间
Rpl_semi_sync_master_tx_waits                       事务等待备库响应的总次数
Rpl_semi_sync_master_wait_pos_backtraverse          改变当前等待最小二进制日志的次数
Rpl_semi_sync_master_wait_sessions                  当前有几个线程在等备库响应
Rpl_semi_sync_master_yes_tx                         Semi-sync模式下，成功的事务数

5.看效果主添加从同步

常用参数说明：

1.主从复制常用配置参数：

bind-address=192.168.1.11   #绑定地址
server_id=513306       #服务ID (主从不相同，规范建议：后IP+端口)
skip_name_resolve=off  #跳过主机域名/域名解析(默认关闭：不建议打开)
transaction-isolation=read-committed   #事务隔离级别 (读取已提交)

2.binlog二进制日志参数

log_bin=/mysql/log/binlog/itpuxdb-binlog    #二进制日志存放路径
log_bin_index=/mysql/log/binlog/itpuxdb-binlog.index   #二进制日志索引
binlog_format=row  #二进制文件的格式(必需为row)
binlog_rows_query_log_events=on    #二进制日志中记录更详细的sql操作
sync_binlog=1 #默认1 #mysql每次提交事务之前会将二进制同步到磁盘上，保证服务器崩溃时不会丢失事务,默认可不设置
innodb_flush_log_at_trx_commit=1 #每次事务提交时mysql都会把log buffer的数据写入log file,并flush(刷到磁盘)中去。默认可不设置 。默认为1
log_bin_trust_function_creators=1  #同步函数和存储过程 ，默认为0
max_binlog_size=2048M  #日志最大设置，默认为102M
expire_logs_days=7 #binlog保留多少天，看具体情况
binlog_cache_size=1M   #binlog缓存的大小，设置时要当心，建议1~4M,具体业务繁忙情况,默认21K
innodb_support_xa=1    #此参数是设置在主数据库上的，看到xa首先想到的是分布式事务，此参数确保事务日志写入bin-logde 的顺序与事务的 time-line 是一致的。系统崩溃时，启用日志恢复，可以严格按照时间线恢复数据库。默认为开启：1

relay_log中继日志参数

relay_log=/mysql/log/relaylog/itpuxdb-relay.log #中继日志存放地址
relay-log-recover=1    #中继日志参数是否打开 ，I/O thread crash safe  -IO线程安全。打开replication #中继日志崩溃恢复模式，replication 支持中继日志的自我修复功能。当slave从库宕机，如果 replay-log 发生损坏，导致一部分中继日志没有处理，就会自动放弃未执行的replay-log 重新从master上获取日志，完成了中继日志的恢复，此参数表示当前接收的relay-log 全部删除， 然后从sql线程回放到的位置重新拉取。
relay_log_info_repostory=table #中继日志信息库写入表。 sql thread crash safe -sql 线程安全。默认是file，sql 线程的数据回放是写入数据库的操作，relay-info 是写文件操作，这两个操作很难保证一致性，relay-info 将吸入到 mysql.slave_relay_log_info 这个表中。
master_info_repository=table   #master 信息库吸入到表 。默认为file,IO线程是接收一个一个的事件（event）,将收到的event 通过设置此参数可以将master-info 的信息写到什么位置，性能上比设置为file 有很高的提升，可靠性也得到保证，设置为table后，master-info 将信息保存到 mysq.slave_master_info

4.同步方式的参数

loose_rpl_semi_sync_master_enabled=1    #开启主库的版同步复制（mysql5.6 ：rpl_semi_sync_master_enabled）
loose_rpl_semi_sync_slave_enabled=1    #开启从库的半同步复制（mysql5.6：rpl_semi_sync_slave_enabled）
loose_rpl_semi_sync_master_timeout = 5000  #超时5秒，切换回异步。默认为10000
rpl_semi_sync_master_wait_forsave_count=1  #至少收到一个slave发回的ack
rpl_semi_sync_master_wait_proint=AFTER_SYNC/AFTER_COMMIT #mysql 5.7的方法：开启无损复制（推荐AFTER_SYNC）

5.GTID参数
先了解什么是GTID?
GTID （ Global Transaction Identifiers ）:对一个已提交的事务编号，事务的唯一编号，并且是一个全局唯一的编号。GTID和事务会记录到binlog中，用来标识事务。GTID是用来替代以前的传统复制方法（binlog_position）mysql5.6.2开始支持GTID。mysql支持GTID后。一个事务在集群中就不在孤单，在每个节点中，如果存在具体相同标识情况，可以避免同一个节点中出现多次的情况。
GTID的出现，最直接的效果就是，每个事务在集群中具有了唯一的意义，相对于行复制来讲数据的安全性更高，故障切换更简单。

GTID是由server_uuid:Sequence_Number
Server_uuid:是一个mysql实例的全局唯一标识；存放在$datadir/auto.cnf
Sequence_Number:是mysql内部的事务编号，一个mysql实例不会重复的序列号（保证全服务器内唯一），也表示在实例上已经提交事务的数量，并且随着事务提交而递增。根据GTID可以知道事务最初是在哪个实例上提交的，方便故障排查和切换。

gtid_mode=on    #开启gtid模式#-on:生产的GTID，slave只接受带GTID的事务#-ON_PERMISSIVE:产生GTID,slave接收不带GTID事务，也接收带GTID的事务#-OFF:不产生GTID,slave 只接受不带GTID 的事务#-OFF_PERMISSIVE:不产生GTID,slave 接受不带GTID的事务也接收带GTID的事务

log_slave_updates=1 ##当从库此参数没有开启时，从库的binlog不会记录来源于主库的操作记录。有开启此参数，从库的binlog才会记录主库同步操作日志。如果是多个从库，切换后，建议关掉此参数，否则重置成主库后，可能会将已执行过的二进制重复传送slave2,导致slave2同步错误。

enforce_gtid_consistency=1#-on/1:当发现语句/事务不支持GTID时，返回错误信息。#-WARN:当发现不支持语句/事务，返回警告，并在日志中记录警告信息。#-OFF/0：不检查是否有GTID 不支持的语句/事务。

6.不常用的参数

binlog_grid_simple_recovery=1   #此参数控制了当mysql启动或重启时，mysql在搜索GRIDs时是如何迭代使用binlog文件的。此参数设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。默认值为1gtid_executed_compression_period  #此参数控制表的压缩率
gtid_next:automatic     #gtid获取下一个事务的方式，automatic为自动获取session_track_gtids=off #控制用于捕获GTIDs和在OK PACKE 返回的跟踪器#-off:关闭#-own_grid:返回单签事务产生的GTID#-all_GTIDS：返回系统执行的所有GTID，也就是GTID_EXECUTED