【数据库】MySQL的主从复制模式

MySQL的主从复制模式包括异步复制，全同步复制，半同步复制。MySQL默认为异步模式。MySQL5.7引入了一种新的半同步方案，并且在5.7引入了一个新的参数，rpl_semi_sync_master_wait_point，这个参数有两种取值，1）AFTER_SYNC 2)AFTER_COMMIT 前者是新的半同步方案后者为老的半同步方案。

MySQL的主从复制模式有三种

异步复制：

（Asynchronous replication）。MySQL的默认复制，主库在执行完客户端提交的事务后会立刻将执行结果返回给客户端，并不关心从库是否已经接收处理，这样带来的问题就是当主死掉了，此时主上提交的事务可能还没有传到从上。而强行将从提升为主就会导致新主上的数据不完整。

异步复制是一种基于偏移量的主从复制，实现的原理是：主库开启bbinlog功能并授权从库连接主库，从库通过change master得到主库的相关同步信息，然后连接主库进行验证，主库的IO线程根据从库slave的线程请求，从master.info开始记录的位置点向下开始取信息，同时把提取到的位置点和最新的位置与binlog信息一同发给从库IO线程，从库将相关的sql语句放在relay_log中，最终从库的sql线程会将relay_log里的sql语句应用到从库上，至此同步过程完成，以后一直循环此过程。
对于异步复制而言，主库将事务的Binlog事件写入到binlog文件中，此时主库会通知下dump线程发送这些新的binlog然后主库会继续处理提交操作，而此时并不保证这些日志会传输到任何一个从库的节点上。

全同步复制：

（Fully synchronous replication）。当主库执行完一个事务，所有的从库都执行了该事务才会将结果返回给客户端。这样保证了数据的安全性，但是因为需要等待所有从库执行完该事务才能返回客户端结果，所以全同步复制的性能必然会受到很大的影响。
对于全同步复制而言，当主库提交一个事务后，要求所有从库节点必须收到，执行并提交这些事务，然后主库线程才能继续做后续操作，而因此带来的问题就是主库完成一个事务的时间被大幅度拉长，性能降低。

半同步复制：

（Semi synchronous replication）。介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时也会造成一定程度的延迟，这个延迟为一个TCP/IP往返的时间。所以半同步复制需要在低延时的网络中使用。
对于半同步复制而言，是介于同步复制和异步复制之间的一种，主库需要等待至少一个从库节点收到并且刷新binlog到relay日志中，主库不需要等待所有从库给主库反馈，同时这里只是收到反馈而不死和完全执行并且提交事务的反馈，这样会节省很多的时间。

 主库上安装插件

install plugin rpl_semi_sync_master soname 'semisync_master.so';

查询数据库插件：mysql>show plugins;

#启用半同步

mysql>set global rpl_semi_sync_master_enabled=1; 

#查询同步

mysql>show global variables like '%rpl_semi%';

master服务器/etc/my.cnf里加入：

rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 # 1second

socket=/data/mysql/mysql.sockport = 3306open_files_limit = 8192log_binserver_id=1expire_logs_days = 7gtid-mode=ONenforce-gtid-consistency=ONrpl_semi_sync_master_enabled=1rpl_semi_sync_master_timeout=1000 # 1secondinnodb_buffer_pool_size = 512Mcharacter-set-server=utf8

从库安装插件

mysql>install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

mysql>show plugins;

#启用半同步，#(0/1) -->1是开启状态，0 是关闭状态

mysql>set global rpl_semi_sync_slave_enabled=1;

#查询

mysql>show global variables like '%rpl_semi%';

slave服务器/etc/my.cnf里加入：

rpl_semi_sync_slave_enabled=1

socket=/data/mysql/mysql.sockport = 3306server_id = 2log_bingtid-mode=ONenforce-gtid-consistency=ONlog_slave_updates=ONrpl_semi_sync_slave_enabled=1open_files_limit = 8192innodb_buffer_pool_size = 512Mcharacter-set-server=utf8

MySQL8.0关闭binlog，在my.cnf下加入

#skip-log-binskip-log-bin

从库优化之InnoDB引擎库修改刷盘方式

innodb_flush_log_at_trx_commit：是 InnoDB引擎特有的，ib_logfile的刷新方式( ib_logfile：记录的是redo log和undo log的信息)

取值:0/1/2
innodb_flush_log_at_trx_commit=0，表示每隔一秒把log buffer刷到文件系统中(os buffer)去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。也就是说一秒之前的日志都保存在日志缓冲区，也就是内存上，如果机器宕掉，可能丢失1秒的事务数据。cndba.cn/hbhe0316/article/22631

innodb_flush_log_at_trx_commit=1，表示在每次事务提交的时候，都把log buffer刷到文件系统中(os buffer)去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。这样的话，数据库对IO的要求就非常高了，如果底层的硬件提供的IOPS比较差，那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升。cndba.cn/hbhe0316/article/22631

innodb_flush_log_at_trx_commit=2，表示在每次事务提交的时候会把log buffer刷到文件系统中去，但并不会立即刷写到磁盘。如果只是MySQL数据库挂掉了，由于文件系统没有问题，那么对应的事务数据并没有丢失。只有在数据库所在的主机操作系统损坏或者突然掉电的情况下，数据库的事务数据可能丢失1秒之类的事务数据。这样的好处，减少了事务数据丢失的概率，而对底层硬件的IO要求也没有那么高(log buffer写到文件系统中，一般只是从log buffer的内存转移的文件系统的内存缓存中，对底层IO没有压力)。
原文链接：https://blog.csdn.net/wenchun001/article/details/131397065

半同步复制的条件：

必要条件
1）MySQL5.5及以上版本
2）变量have_dynamic_loading 为YES（查看命令：show variables like "have_dynamic_loading";）
3）主从复制已经存在(即提前部署mysql主从复制环境,主从同步要配置基于整个数据库的，不要配置基于某个库的同步，即同步时不要过滤库)

来源地址：https://blog.csdn.net/wenchun001/article/details/131403417