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 ）参数介绍

########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/f

2.主库f 添加参数

server_id =111 #服务ID *必须设置log_bin=mysql-bin #开启二进制日志 *必需设置expire_logs_days=15 #binlog保留多少天，选择设置，默认0binlog_cache_size=1M #binlog缓存的大小，选择设置，默认32kmax_binlog_size=2048M #binlog日志每达到设定大小后，会使用新的bin log日志。如mysql-bin.000002 。 默认2097152GBbinlog_do_db=test#需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可binlog-ignore-db=mysql#不需要复制的数据库苦命，如果复制多个数据库，重复设置这个选项即可log_bin_trust_function_creators =on#同步函数和存储过程 默认为0plugin_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.从库f 添加参数

server_id =112 #服务ID *必须设置log_bin=mysql-bin #开启二进制日志*非必需expire_logs_days=15 #binlog保留多少天，选择设置，默认0binlog_cache_size=1M #binlog缓存的大小，选择设置，默认32kmax_binlog_size=2048M#binlog日志每达到设定大小后，会使用新的bin log日志。如mysql-bin.000002 。 默认2097152GBlog_bin_trust_function_creators =on#同步函数和存储过程 默认为0plugin_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 globalvariale_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_txSemi-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(刷到磁盘)中去。默认可不设置 。默认为1log_bin_trust_function_creators=1#同步函数和存储过程 ，默认为0max_binlog_size=2048M#日志最大设置，默认为102Mexpire_logs_days=7#binlog保留多少天，看具体情况binlog_cache_size=1M #binlog缓存的大小，设置时要当心，建议1~4M,具体业务繁忙情况,默认21Kinnodb_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秒，切换回异步。默认为10000rpl_semi_sync_master_wait_forsave_count=1#至少收到一个slave发回的ackrpl_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/f

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