MySQL增强半同步的搭建实验,和一些参数的个人理解

环境信息


role


ip


port


hostname


master


192.168.188.101


4306


mysqlvm1


slave


192.168.188.201


4306


mysqlvm1-1


5306


6306


7306

MySQL版本

  5.7.26

前置条件

  已配置好主从复制。

配置增强半同步

  1.加载lib,所有主从节点都要配置。

    主库:install plugin rpl_semi_sync_master soname ‘semisync_master.so‘;

    从库:install plugin rpl_semi_sync_slave soname ‘semisync_slave.so‘;

    ps:可以一起装。建议一起装,因为会有主从切换的情景。

2.查看,确保所有节点都成功加载。

  mysql> show plugins;

    | rpl_semi_sync_master       | ACTIVE   | REPLICATION        | semisync_master.so | GPL     |

    | rpl_semi_sync_slave        | ACTIVE   | REPLICATION        | semisync_slave.so  | GPL     |

3.启用半同步

  1.先启用从库上的参数,最后启用主库的参数。

    从库:set global rpl_semi_sync_slave_enabled = {0|1};   # 1:启用,0:禁止

    主库:

      set global rpl_semi_sync_master_enabled = {0|1};   # 1:启用,0:禁止

      set global rpl_semi_sync_master_timeout = N;       # 单位为ms

    PS:配置文件加载库: #官方手册建议这样写入配置文件,但是——

      风险!:endbled写入配置文件的话,会使实例启动后立即进入半同步模式,如果发生长时间断连的实例重新运行启动,有可能导致主库被拖垮。

      建议!:长时间断开的从库,重新连接后,要等待追完全部事务后,手动开启半同步模式,而不是启动后直接切换,防止冲击主库。

        [mysqld]

        rpl_semi_sync_master_enabled=1

        rpl_semi_sync_master_timeout=1000

        [mysqld]

        rpl_semi_sync_slave_enabled=1

  2.从库重启io_thread

    stop slave io_thread;

    start slave io_thread;

    此时在主库会发现

      mysql> show global status like "%sync%";


| Variable_name                              | Value |


| Innodb_data_fsyncs                         | 141   |


| Innodb_data_pending_fsyncs                 | 0     |


| Innodb_os_log_fsyncs                       | 87    |


| Innodb_os_log_pending_fsyncs               | 0     |


| Rpl_semi_sync_master_clients               | 2     |


#支持和注册半同步复制的已连Slave数。


| Rpl_semi_sync_master_net_avg_wait_time     | 0     |


# master等待slave回复的平均等待时间,单位毫秒。


| Rpl_semi_sync_master_net_wait_time         | 0     |


# master总的等待时间。


| Rpl_semi_sync_master_net_waits             | 0     |


# master等待slave回复的的总的等待次数,即半同步复制的总次数,不管失败还是成功,不算半同步失败后的异步复制。


| Rpl_semi_sync_master_no_times              | 1     |


# master关闭半同步复制的次数。


| Rpl_semi_sync_master_no_tx                 | 8     |


# master没有收到slave的回复而提交的次数,可以理解为master等待超时的次数,即半同步模式不成功提交数量。


| Rpl_semi_sync_master_status                | ON    |


# ON是活动状态(半同步),OFF是非活动状态(异步),用于表示主服务器使用的是异步复制模式,还是半同步复制模式。


| Rpl_semi_sync_master_timefunc_failures     | 0     |


| Rpl_semi_sync_master_tx_avg_wait_time      | 0     |


# master花在每个事务上的平均等待时间。


| Rpl_semi_sync_master_tx_wait_time          | 0     |


# master总的等待时间。


| Rpl_semi_sync_master_tx_waits              | 0     |


# master等待成功的次数,即master没有等待超时的次数,也就是成功提交的次数


| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |


# master提交后来的先到了,而先来的还没有到的次数。


| Rpl_semi_sync_master_wait_sessions         | 0     |


# 前有多少个session因为slave的回复而造成等待。


| Rpl_semi_sync_master_yes_tx                | 0     |


# master成功接收到slave的回复的次数,即半同步模式成功提交数量。


| Rpl_semi_sync_slave_status                 | OFF   |


# Slave上的半同步复制状态,ON表示已经被启用,OFF表示非活动状态。

  3.主库参数详解 

    mysql> show global variables like ‘%sync%‘;


| Variable_name                             | Value      |


| binlog_group_commit_sync_delay            | 100        |


| binlog_group_commit_sync_no_delay_count   | 10         |


| innodb_flush_sync                         | ON         |


| innodb_sync_array_size                    | 1          |


| innodb_sync_spin_loops                    | 30         |


| rpl_semi_sync_master_enabled              | ON         |


#(主库)是否启动半同步


| rpl_semi_sync_master_timeout              | 100000     |


#为了防止半同步复制中主在没有收到S发出的确认发生堵塞,用来设置超时,超过这个时间值没有收到信息,则切换到异步复制,执行操作。默认为10000毫秒,等于10秒,这个参数动态可调,表示主库在某次事务中,如果等待时间超过10秒,那么则降级为异步复制模式,不再等待SLAVE从库。如果主库再次探测到SLAVE从库恢复了,则会自动再次回到半同步复制模式。


| rpl_semi_sync_master_trace_level          | 32         |


| rpl_semi_sync_master_wait_for_slave_count | 1          |


#For example:if rpl_semi_sync_master_wait_for_slave_count is 2, then 2 slaves must acknowledge receipt of the transaction before the timeout period configured by rpl_semi_sync_master_timeout for semisynchronous replication to proceed. If less slaves acknowledge receipt of the transaction during the timeout period, the master reverts to normal replication.

超时前至少x个来自slave对的ack应答。如果超时前的应答未及该值,则master转为异步复制。

在slave存活大于等于该值时,master提交不会有任何等待发生,一旦slave存活低于该值,则master会进行等待,直到超时。


| rpl_semi_sync_master_wait_no_slave        | ON         |


# 这个参数,我在中文网络上就没见到说对的!搞懂了~ 20200117:

这个值影响master根据slave数量决定什么时候转为异步复制。

【在完全无事务进行的空业务环境下进行实验】。

原理:

  master会根据一定时间获取连接的slave数量(rpl_semi_sync_master_clients) ,同时用获取到的值与参数(rpl_semi_sync_master_wait_for_slave_count)进行对比,来决定使用怎样的复制方式。

实验:

  令存活的slave数量小于参数(rpl_semi_sync_master_wait_for_slave_count)值, 过一定时间后,master检测到真实slave数量(rpl_semi_sync_master_clients)小于参数(rpl_semi_sync_master_wait_for_slave_count)值——

如果该值为ON:

  master不会立即将半同步复制转为异步复制(Rpl_semi_sync_master_status=ON)。

  此时开启事务,只要在超时时间范围内(rpl_semi_sync_master_timeout)应答该事物的slave达到参数(rpl_semi_sync_master_wait_for_slave_count)值,master就会一直保持半同步。

  也就是说,直到事务提交超时前,master都不会根据检测到的slave数量变更复制模式。

如果该值为OFF:

  master会立即转为异步复制(Rpl_semi_sync_master_status=OFF)。

  也就是说,只要master检测到的slave数量低于count参数的设定,便立即变更复制模式。

  off的话, 如果master根据检测slave数量自行降为异步, 那么开始事务的时候就不用等超时(直接异步了,事务不用等待)。 如果是on的话,master会超时后再降为异步,事务会等待。

  但是询问发现,生产环境都是ON,且默认值就是ON,为什么呢?这个我还不知道。

【8.0文档】

Controls whether the master waits for the timeout period configured by rpl_semi_sync_master_timeout to expire, even if the slave count drops to less than the number of slaves configured by rpl_semi_sync_master_wait_for_slave_count during the timeout period.

When the value of rpl_semi_sync_master_wait_no_slave is ON (the default), it is permissible for the slave count to drop to less than rpl_semi_sync_master_wait_for_slave_count during the timeout period. As long as enough slaves acknowledge the transaction before the timeout period expires, semisynchronous replication continues.

When the value of rpl_semi_sync_master_wait_no_slave is OFF, if the slave count drops to less than the number configured in rpl_semi_sync_master_wait_for_slave_count at any time during the timeout period configured by rpl_semi_sync_master_timeout, the master reverts to normal replication.

This variable is available only if the master-side semisynchronous replication plugin is installed.


| rpl_semi_sync_master_wait_point           | AFTER_SYNC |


#5.7默认AFTER_SYNC,在得到slave的应答后再commit,可选值AFTER_COMMIT。


| rpl_semi_sync_slave_enabled               | OFF        |


#(从库)是否启动半同步


| rpl_semi_sync_slave_trace_level           | 32         |


| sync_binlog                               | 1          |


| sync_frm                                  | ON         |


| sync_master_info                          | 10000      |


| sync_relay_log                            | 10000      |


| sync_relay_log_info                       | 10000      |

          

  4.维护

    •   从上面得知,如果slave无法连接,那么master会等待至超时后,将该slave转为异步模式;当从库重新连接后,在rpl_semi_sync_master_wait_no_slave=ON时(默认),从库会自动转换为半同步模式。
    •   长时间断开的从库,重新连接后,要等待追完全部事务后,手动开启半同步模式,而不是启动后直接切换。

    从库断开后的重连维护:

      start slave io_thread;

      show slave status \G        #查看 Retrieved_Gtid_Set、Executed_Gtid_Set,前者应该接收到master的gtid,后者没有

      start slave sql_thread;

      show slave status \G        #查看 Retrieved_Gtid_Set、Executed_Gtid_Set,此时二者相同,追到master的GTID。

      set rpl_semi_sync_slave_enabled = 1;     #开启半同步

      stop io_thread;

      start io_thread;

原文地址:https://www.cnblogs.com/konggg/p/12204874.html

时间: 2024-10-09 03:30:52

MySQL增强半同步的搭建实验,和一些参数的个人理解的相关文章

mysql5.7 开启增强半同步复制

前提是主从异步复制环境要提前搭建好,然后再开启mysql增强半同步 环境:mysql5.7.26 主从异步复制早已部署好. 1.加载plugin插件 建议master和slave上全部执行(考虑到MHA的主从自动切换的环境) 在主库安装semisync_master.so和semisync_slave.so插件: mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; mysql> INSTALL PLUG

MySQL 5.7 新特性之增强半同步复制

1. 背景介绍 半同步复制 普通的replication,即mysql的异步复制,依靠mysql二进制日志也即binary log进行数据复制.比如两台机器,一台主机(master),另外一台是从机(slave). 正常的复制为:事务一(t1)写入binlog buffer:dumper 线程通知slave有新的事务t1:binlog buffer 进行checkpoint:slave的io线程接收到t1并写入到自己的的relay log:slave的sql线程写入到本地数据库. 这时,mast

MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中,该如何选择?

一.生产环境中: 几种复制场景都有存在的价值.下面分别描述一下: 从成熟度上来选择,推荐:异步复制(GTID+ROW) 从数据安全及更高性能上选择:增强半同步 (在这个结构下也可以把innodb_flush_log_trx_commit调整到非1, 从而获得更好的性能) 对于主从切换控制觉的不好管理,又对数据一致性要求特别高的场景,可以使用MGR 二.理由: 异步复制,相对来讲非常成熟,对于环境运维也比较容易上手 增强半同步复制,可以安全的保证数据传输到从库上,对于单节点的配置上不用要求太严格,

PostgreSQL的同步级别与MySQL的半同步after_sync比较

MySQL的半同步中通过binlog进行流复制,同步级别和PostgreSQL对比可以发现: PostgreSQL                MySQL off local                         after_commit          remote_write            after_sync remote_apply on 所以,整体来说MySQL的日志同步上还是没有PostgreSQL做的严谨,在金融系统中,PostgreSQL的日志同步级别都是设

MariaDB(MySQL):半同步复制+ssl+复制过滤

一.半同步复制   1.mysql的复制 通过记录主服务器的二进制日志,并在从服务器上进行重放(replay)完成复制,默认都是异步进行的. 2.半同步复制 半同步复制是google贡献给MySQL的一个补丁,在MySQL 5.5之后就支持了,MariaDB都是支持的. MySQL的插件,一般在MySQL安装目录下; 半同步复制插件默认没有启用,需要自己安装,/usr/local/mysql/lib/plugin可以看到semisync_master.so和semisync_slave.so和其

mysql 主从半同步模式和数据库同步过滤

在mysql主从架构中,默认采用的是异步模式,也就是在master中将数据保存在数据库,再将操作写到bin-log中即响应给客户端.至于slave是否同步了二进制文件,是否完成了本地操作,master无从得知.异步模式固然能以最快的速度响应给客户端,减少用户的等待时间,但在一些数据同步.安全性较高的场景,要求slave中的数据要尽最大能力与master保持一致,那么半同步模式就可以用上了. mysql的半同步模式是以插件的方式由google提供的.主要文件在${mysql_home}/lib/p

MySQL主从复制半同步复制原理及搭建

在MySQL5.5之前的版本中,MySQL的复制是异步复制,主库和从库的数据之间存在一定的延迟,比如网络故障等各种原因,这样子容易存在隐患就是:当在主库写入一个事务成功后并提交了,但是由于从库延迟没有及时得到主库推送的Binlog日志时,主库突然宕机了,那么此时从库就可能损失这个事务,从而造成主从不一致的状况. 因此我们MySQL5.5版本之后引入了半同步复制的概念 半同步复制的原理: 半同步复制时,为了保证主库上的每一个Binlog事务都能够被可靠的复制到从库上,主库在每次事务成功提交时,并不

mysql GTID 半同步复制

1)什么是GTID GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号.GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标 识,保存在mysql数据目录下的auto.cnf文件里.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增.下面是一个GTID的具 体形式:3E11FA47-71CA-11E1-9E33-C80AA9429562:23.2)GTID的作用 根据GTID可以知道事务最初是在哪

MySQL--------基于半同步复制搭建主从

1. 背景 * MySQL Replication默认都是异步(asynchronous),当主库在执行完一些事务后,是不会管备库的进度的.如果备库不幸落后,而更不幸的是主库此时又出现Crash(例如宕机),这时备库中的数据就是不完整的.简而言之,在主库发生故障的时候,我们无法使用备库来继续提供数据一致的服务了. * Semi sync Replication在一定程度上保证提交的事务已经传给了至少一个备库. * Semi sync Replication仅仅保证事务的已经传递到备库上,但是并不