您的位置:新葡亰496net > 网络数据库 > 配备维护故障处理全集,Mysql主主同步

配备维护故障处理全集,Mysql主主同步

发布时间:2019-07-05 13:05编辑:网络数据库浏览(157)

    在安顿第一台服务器

    START GROUP_REPLICATION;
    

    后出现以下难点:

    ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
    

    开采,本机十分小概ping通,修改/etc/sysconfig/network-scripts/ifcfg-eth0(eth0为您上网用的网卡),设置好本机ip、子网掩码、网关,之后重启network就行

     

     

    纤弱研商MySQL Group Replicaiton — 配置维护故障管理全集,replicagroup

             本文首要描述 MySQL Group Replication的粗略原理、搭建进程以及故障维护管理内容。由于是新技术,未在生育情形使用过,本文均是虚构机测验,大概存在思虑不周跟思路有误情形,迎接调换指正。   倘若转发,请声明博文来源: www.cnblogs.com/xinysu/   ,版权归 博客园苏家小萝卜 全体。望各位帮助! 新葡亰496net 1

    二、第二台服务器一贯处于RECOVESportageING状态

    本条主题材料比较复杂,很有极大恐怕是因为出现部分荒谬意况导致服务器之间连接不成事,一般MySQL会尝试连接11遍,之后后起的服务器会处于ETiggoROLAND状态。

    假设一个实例进入EEvoqueRO宝马7系状态,该实例super_read_only选项棉被服装置为ON。要相差E哈弗RO揽胜极光状态,必须手动配置实例super_read_only=OFF。

     

     

    1 What's Group Replication 

        主从复制,一主多从,主库提供读写功效,从库提供写功效。当多少个事情在master 提交成功时,会把binlog文件同步到从库服务器上落地为relay log给slave端实施,那一个历程主库是不牵挂从库是或不是有抽出到binlog文件,有非常大恐怕出现这种场地,当主库commit八个业务后,数据库发生宕机,刚好它的binlog还没赶趟传送到slave端,那年选任何三个slave端都会遗弃这么些业务,形成数据不一致情况。原理图如下:  新葡亰496net 2        为了幸免出现主从数据不均等的景况,MySQL引进了半联合复制,添增加了三个从库反馈机制,这些有二种办法设置:

    • 主库施行完业务后,同步binlog给从库,从库ack反馈收到到binlog,主库提交commit,反馈给客户端,释放会话;
    • 主库试行完事情后,主库提交commit ,同步binlog给从库,从库ack反馈收到到binlog,反馈给客户端,释放会话;

    新葡亰496net 3

     

        可是,可是,可是,难题来了,即使满意了一主多从,读写深入分析,数据一致,不过,依旧有八个缺欠

    • 写操作集中在MASTEPAJERO服务器上;
    • MASTE奥迪Q7宕机后,要求人工选用新主同等对待新给别的的slave端推行change master(可机关写第三方工具完结,可是mysql的复制正是没提供,所以也终于破绽)

        于是乎,官方感应到民间怨气以及产业界压力,于二〇一五年5月十八日规范颁发了MySQL Group Replication,此处应该掌声 新葡亰496net 4     那么,MySQL Group Replication能够提供什么样职能吗?

    • 多主,在同二个group里边的持有实例,每一个实例可以实行写操作,也正是各样实例都实践Read-Write
      • 留意一点,多主境况下,当实施二个事务时,必要保障同个组内的各种实例都承认这些工作无争辩相当,才方可commit,要是设置的是单主,别的实例ReadOnly,则不供给打开上边的论断
      • 多主意况下,事务并发争论难题就显示出来了,怎么着幸免吗?数据库内部有一个验证程序,当不一样实例并发对同一行发起修改,在同个组内广播认同时,会见世并发争论,那么会安分守己先实行的提交,后进行的回滚
    • 弹性,同个Group Replication中,节点的加盟或然移除都以机动调度;要是新参预八个节点,该节点会自行从Group的其他节点同步数据,直到与别的节点一致;假使移除八个节点,那么余下的实例会自动更新,不再向那几个节点广播事务操作,当然,这里要留心,要是多少个Group的节点有n个(max(n)=9,同个Group最多节点数为9),移除只怕宕机的节点数应该小于等于 floor((n-1)/2) ,注意是向下取整;假设是单主形式,宕机的是单主,则人为选拔新主后,别的节点也会自动从新主同步数据。
    • 越来越高质量的同步机制

     新葡亰496net 5

     

    事关知识点 故障探测( Failure Detection): Group Replication中有叁个故障检查实验机制,会提供一些节点或者死掉的新闻,然后广播给同贰个Group的次第节点,要是鲜明宕机,那么组内的节点就能与它隔绝开来,该节点即十分小概共同别的节点的传递过来的binlog events,也力不能够及施行另内地点工作。 此地有个难点,故障探测中,假诺N个节点,三个节点故障,是应用好些个投票机制照旧整个同样投票机制?  

    Mysql主主复制

    情况1:

    防火墙和selinux没关,那是否难题,关掉就行。

         本文重要陈诉 MySQL Group Replication的轻巧原理、搭建进程以及故障维护管理内容。由于是新手艺,未在生育意况使用过,本文均是设想机测量检验,大概存在思量不周跟思路有误景况,迎接交换指正。

         本文重要描述 MySQL Group Replication的轻巧原理、搭建进度以及故障维护处理内容。由于是新本事,未在生产意况使用过,本文均是设想机测量检验,只怕存在思索不周跟思路有误景况,接待交换指正。

    2 配置须求与范围

    一、意况描述

    情况2:

    两台服务器主机名一样,mysql不可能通过DNS找到呼应服务器。

    化解措施:
    在my.cnf文件中安装

    report-host=192.168.50.22 #后面跟的ip是本机的ip
    

    要么撤销掉mysql通过DNS查找服务器的政策,当然,也得以修改hosts文件,方French Open上能够找到的。当然,最棒是安装report-host。
    还有server_id每台服务器应当要不等。

     

     

    2.1 数据库须求

    服务器A   192.168.1.108

    情况3:

    查看mysql日志,发掘两台服务器直接一向在尝试连接,一贯总是不上。尝试13回之后,产生ERROPRADO状态。

    VM Ware的锅,概率不高。

    下一场本身运气倒霉,碰着了,折磨了自家四个礼拜,网络根本找不到化解措施,最终换来Virtual博克斯就好了,实际生产条件应当不会有诸有此类坑爹的标题,大约是VM Ware设想机互连网通讯机制的标题,推测或者还应该有防火墙,同事用VM Ware做成功了,差非常的少是本子难题大概另外的,具体原因查不出去。

    自己后来在用二个纯净的中坚未有自配的服务的centos镜像在VM Ware下装机,连网卡都运营不来后才猜出来的,然后决断下了个VirtualBox,重新配,就没难点了。

    千帆竞发以为说不定是管理员权限的原因,VM Ware和Win 10都该背锅。

    一旦转发,请评释博文来源: www.cnblogs.com/xinysu/   ,版权归 乐乎 苏家小萝卜 全体。望各位协助! 新葡亰496net 6

    假诺转载,请表明博文来源: www.cnblogs.com/xinysu/   ,版权归 天涯论坛 苏家小萝卜 全部。望各位辅助! 新葡亰496net 7

    2.1.1 innodb引擎

        为啥须要选择innodb引擎呢?在MySQL Group Replication中,事务以乐观格局进行,可是在提交时检查争辩,若是存在争论,则会在一些实例上回滚事务,保持各样实例的数据一致性,那么,那就供给利用到 事务存款和储蓄引擎,同事Innodb提供部相当加的效果与利益,能够更加好的管制和管理争论,所以提出 业务使用表格使用inndb存款和储蓄引擎,类似于系统表格mysql.user使用MyISAM引擎的报表,因为极少修改及增进,极少出现争论景况。

           服务器B   192.168.1.110

    情况4:

    加载的sql查询文件语法不包容组复制,比如建表未有主键,创制的带再次来到值的函数未有注脚DETERMINISTIC之类的,查MySQL日志大致能查出来。

    1 What's Group Replication 

        主从复制,一主多从,主库提供读写功效,从库提供写作用。当贰个政工在master 提交成功时,会把binlog文件同步到从库服务器上落地为relay log给slave端实行,那几个进程主库是不思量从库是或不是有接受到binlog文件,有希望出现这种情景,当主库commit二个业务后,数据库发生宕机,刚好它的binlog还没赶趟传送到slave端,今年选任何三个slave端都会放任这些事情,变成数据不均等景况。原理图如下:

     新葡亰496net 8

     

         为了制止现身主从数据不一致等的情状,MySQL引入了半一并复制,添扩展了三个从库反馈机制,那几个有三种方法设置:

    • 主库实践完事情后,同步binlog给从库,从库ack反馈收到到binlog,主库提交commit,反馈给客户端,释放会话;
    • 主库实践完职业后,主库提交commit ,同步binlog给从库,从库ack反馈收到到binlog,反馈给客户端,释放会话;

    新葡亰496net 9

     

        而是,可是,可是,难点来了,就算满意了一主多从,读写深入分析,数据一致,可是,依然有四个缺陷

    • 写操作集中在MASTE兰德纳瓦拉服务器上;
    • MASTE卡宴宕机后,要求人工选用新主一碗水端平新给任何的slave端施行change master(可自动写第三方工具完成,但是mysql的复制就是没提供,所以也终归缺欠)

        于是乎,官方感应到民间怨气以及产业界压力,于2015年八月二18日行业内部公布了MySQL Group Replication,此处应该掌声 新葡亰496net 10

        那么,MySQL Group Replication能够提供哪些效用吗?

    • 多主,在同叁个group里边的全数实例,每二个实例能够推行写操作,也正是每一个实例都试行Read-Write
      • 只顾一点,多主情形下,当实施一个事务时,供给确定保障同个组内的每一个实例都认可这一个业务无争持格外,才足以commit,固然设置的是单主,别的实例ReadOnly,则无需进行上面的判定
      • 多主情况下,事务并发争论难题就呈现出来了,怎么着防止吗?数据库内部有三个注解程序,当分化实例并发对同一行发起修改,在同个组内广播认可时,会出现并发争论,那么会遵守先进行的交给,后实行的回滚
    • 弹性,同个Group Replication中,节点的步向或然移除都以自动调解;即使新投入叁个节点,该节点会自动从Group的别的节点同步数据,直到与任何节点一致;假若移除贰个节点,那么余下的实例会自动更新,不再向这一个节点广播事务操作,当然,这里要当心,如若三个Group的节点有n个(max(n)=9,同个Group最多节点数为9),移除或然宕机的节点数应该小于等于 floor((n-1)/2) ,注意是向下取整;要是是单主形式,宕机的是单主,则人为选拔新主后,别的节点也会自动从新主同步数据。
    • 更加高品质的联合机制

     新葡亰496net 11

     

    关联知识点

    故障探测( Failure Detection):

    Group Replication中有二个故障检查测量试验机制,会提供一些节点大概死掉的新闻,然后广播给同一个Group的次第节点,借使明确宕机,那么组内的节点就能与它隔绝开来,该节点即不恐怕同步其余节点的传递过来的binlog events,也无法实践其他市方职业。

    这里有个难题,故障探测中,要是N个节点,一个节点故障,是运用非常多投票机制照旧整个同一投票机制?

     

    1 What's Group Replication 

        主从复制,一主多从,主库提供读写作用,从库提供写功用。当多少个事情在master 提交成功时,会把binlog文件同步到从库服务器上落地为relay log给slave端实行,那么些进度主库是不思考从库是或不是有接受到binlog文件,有十分的大可能率出现这种情状,当主库commit一个业务后,数据库发生宕机,刚好它的binlog还没赶趟传送到slave端,那个时候选任何贰个slave端都会屏弃这些事情,变成数据区别情况。原理图如下:

     新葡亰496net 12

     

         为了防止出现主从数据不雷同的状态,MySQL引进了半一头复制,添扩充了多少个从库反馈机制,那些有二种方式设置:

    • 主库试行完事情后,同步binlog给从库,从库ack反馈收到到binlog,主库提交commit,反馈给客户端,释放会话;
    • 主库实施完职业后,主库提交commit ,同步binlog给从库,从库ack反馈收到到binlog,反馈给客户端,释放会话;

    新葡亰496net 13

     

        唯独,可是,但是,难点来了,就算知足了一主多从,读写分析,数据一致,不过,还是有多个破绽

    • 写操作聚集在MASTE科雷傲服务器上;
    • MASTE奥迪Q5宕机后,供给人工接纳新主比量齐观新给其余的slave端推行change master(可自动写第三方工具达成,然则mysql的复制正是没提供,所以也终究缺陷)

        于是乎,官方感应到民间怨气以及产业界压力,于2014年一月十七日规范颁发了MySQL Group Replication,此处应该掌声 新葡亰496net 14

        那么,MySQL Group Replication能够提供什么样作用吗?

    • 多主,在同一个group里边的全部实例,每贰个实例能够实践写操作,相当于各种实例都实践Read-Write
      • 留神一点,多主情形下,当实施八个事务时,需求确认保证同个组内的各种实例都认可这么些业务无争执非常,才方可commit,假设设置的是单主,其余实例ReadOnly,则无需进行上面包车型大巴剖断
      • 多主情状下,事务并发争辩难点就展现出来了,怎么样制止吗?数据库内部有一个验证程序,当分化实例并发对同一行发起修改,在同个组内广播承认时,会出现并发争辩,那么会遵守先施行的提交,后实行的回滚
    • 弹性,同个Group Replication中,节点的加盟只怕移除都是活动调节;若是新参加一个节点,该节点会活动从Group的其余节点同步数据,直到与别的节点一致;要是移除一个节点,那么余下的实例会自动更新,不再向这些节点广播事务操作,当然,这里要注意,即使二个Group的节点有n个(max(n)=9,同个Group最多节点数为9),移除只怕宕机的节点数应该小于等于 floor((n-1)/2) ,注意是向下取整;假若是单主方式,宕机的是单主,则人为选择新主后,其余节点也会活动从新主同步数据。
    • 越来越高品质的一块机制

     新葡亰496net 15

     

    提到知识点

    故障探测( Failure Detection):

    Group Replication中有三个故障检查评定机制,会提供一些节点可能死掉的音信,然后广播给同一个Group的各类节点,假使明确宕机,那么组内的节点就能够与它隔开开来,该节点即不可能共同别的节点的传递过来的binlog events,也力不能支奉行另各市点职业。

    此地有个难点,故障探测中,要是N个节点,多个节点故障,是选择许多投票机制如故整个一律投票机制?

     

    **2.1.2 主键**

        每一个须求复制的表格都必须定义贰个显式主键,注意跟隐式主键区分(使用Innodb引擎的报表,若无一点名主键,默许选项第二个非空的独步一时索引作为主键,若无,则自动创立二个6个字节的rowid隐式主键)。这几个主键能在争辨时有爆发时运转非常重要的效果与利益,同有时间,能够行得通增强relay log的实践功能。

           Mysql版本:5.1.26

    倘诺用设想机模拟组复制,那么,最佳不用一向克隆一台已经布署好的设想机,至少,不能够克隆已经初步化了mysql的虚构机,不然会招致两台服务器的MEMBE奇骏_ID一样,导致两台服务器不或者找到对方。

    2 配置须求与范围

    2 配置供给与范围

    **2.1.3 隔绝品级**

        官方网址建议选用READ COMMITTED等第,除非应用程序重视于REPLEATABLE READ,RC情势下并未有GAP LOCK,比较好支持Innodb自己的抵触检查实验机制何组复制的中间遍及式检查测试机制一齐协同职业。不帮忙SE酷路泽IALIZABLE隔开等第。

           System OS:CentOS release 5.4

    四、自增量

    万一在数据库内利用到了自增的字段,最佳在/etc/my.cnf中增添auto_increment_increment、auto_increment_offset多个参数,幸免产生事情冲突(MGR其实本人就有防护自增量事务争论的力量,运用了GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT那几个参数,但如果不去手动设置,自增量的区间会异常想获得)。

    auto_increment_increment为自增量的间距,auto_increment_offset为自增量的上马地点。

    从官方网址查到的文书档案上,建议最棒为:

    auto_increment_increment=n(组内成员数)
    auto_increment_offset=server_id(这里的server_id最好为1,2,3这样的自增量,且每台都不同)
    

    那般自然能缓慢解决事情冲突的主题素材,不过,那样,为了让自增量每回都以 1,必须得DB1插表,然后DB2,接着DB3...假诺直白是DB1(恐怕随意一台组内的服务器)插表,会变成自增量每一次是 n。假使有情感障碍,会很伤心...

    网络也会有这么做的:

    auto_increment_increment=1
    auto_increment_offset=2
    

    如此那般,大家做名爵Escort的时候也试过,还试过auto_increment_offset等于其余大于1的值,基本上自增量每一次都是 1,也从未出现事务争执,凑合着是能够用的,但逻辑上多少意外,不明了会不会有藏匿的难点。

    至于

    auto_increment_increment=1
    auto_increment_offset=1
    

    如此那般的做法,鲜明是哪位老哥用官方网址络的做法写的DB1示例后,被人各类无脑Ctrl C、Ctrl V之后的做法。

    如此会促成每趟自增的间距为7,不论在哪台服务器上。

    至于怎会如此,貌似是GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT这么些参数默许是7,而MGCR-V暗许的逃脱自增量导致的事务争持的办法中auto_increment_increment=GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT。

    那样做,还不及用合法建议的陈设。

    现在,大家在公司里,用的是:

    # auto_increment_increment=1
    auto_increment_offset=9
    

    这里auto_increment_increment参数被我们疏解掉了,在测量检验的时候基本也没出问题,不知情到时候到生育意况会什么。

    自增字段的大大小小注重于group replication组中成员的略微。

    auto_increment_offset值,最棒是大于等于组内成员数,假使段的高低也正是组内成员的数码,则有着的自增值都会被使用。

    auto_increment_offset值稍低于组内成员数,我们有试过,可是不亮堂是我们测量检验的虚构机数量太少,照旧情况考虑的不周,临时没什么难题,然而以免万一,依旧不要这么操作。

    有关组复制设置自增量间隔,推荐能够看:

    WL#8445: Group Replication: Auto-increment configuration/handling

    笨小孩的dba之路-MySQL group replication介绍

    再有自行Google,至于百度固然了,没什么用。

    2.1 数据库需要

    2.1 数据库须要

    **2.1.4 外键**

        不提议利用级联外键,假设旧库自身有外键,业务上不或许去除并且使用的是多主形式,那么,请配置 group_replication_enforce_update_everywhere_check ,强制检查各样组成员的级联合检查查,制止多主格局下实行级联操作形成的质量评定不到的争辨。

     

    五、设置read_only

    因为以私下认可的方法(不设置loose-group_replication_single_primary_mode=FALSE)运转组复制时后起服务器没用写的权力,所以要在MySQL shell上输入

    set global read_only=0;
    

    但是,最佳在服务器ONLINE之后再推行,否则,同步会冒出难题。

    查看日志/var/log/mysqld.log,大批量产出:

    [ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication is recovering. Try again when the server is ONLINE.'
    [ERROR] Run function 'before_commit' in plugin 'group_replication' failed
    

    当然如此照旧有概率能ONLINE,可是比较浪费时间,并且也是有相当的大致率退步。

    具备生产情形极度不用在劳务器RECOVE兰德酷路泽ING时设置read_only=0。

    2.1.1 innodb引擎

        为何须要运用innodb引擎呢?在MySQL Group Replication中,事务以开阔方式举行,不过在交付时检查抵触,倘诺存在争辩,则会在好几实例上回滚事务,保持种种实例的数目一致性,那么,那就需求采纳到 事务存款和储蓄引擎,同事Innodb提供部分拾叁分的效率,能够越来越好的管住和拍卖争辩,所以建议 业务使用表格使用inndb存款和储蓄引擎,类似于系统表格mysql.user使用MyISAM引擎的表格,因为极少修改及增加,极少现身争执情状。

    2.1.1 innodb引擎

        为啥须要运用innodb引擎呢?在MySQL Group Replication中,事务以开阔情势实行,可是在付给时检查争辨,如果存在争执,则会在少数实例上回滚事务,保持各样实例的多寡一致性,那么,那就要求选取到 事务存款和储蓄引擎,同事Innodb提供一些外加的功力,能够越来越好的管理和拍卖争辨,所以建议 业务应用表格使用inndb存款和储蓄引擎,类似于系统表格mysql.user使用MyISAM引擎的表格,因为极少修改及丰盛,极少出现争执景况。

    **2.1.5 IPv4网络,互连网质量稳固延迟小带宽丰富**

    二、主主配置进程

    **2.1.2 主键**

        每一种必要复制的表格都必须定义三个显式主键,注意跟隐式主键区分(使用Innodb引擎的报表,若无一些名主键,暗许选项第贰个非空的唯一索引作为主键,若无,则自动成立三个6个字节的rowid隐式主键)。那个主键能在冲突时有发生时运行非常主要的意义,同期,能够行得通提升relay log的实践功效。

    **2.1.2 主键**

        每一个须要复制的报表都不能不定义一个显式主键,注意跟隐式主键区分(使用Innodb引擎的报表,若无一些名主键,默许选项第二个非空的独一索引作为主键,若无,则自动成立三个6个字节的rowid隐式主键)。那些主键能在争辩产生时起步非常首要的效应,同不常候,能够使得增加relay log的试行作用。

    **2.1.6 自增跟步长**

        这里供给当心到,搭建group的时候,每一种实例中的auto_increment_increment跟auto_increment_offset的铺排情形。

    • auto_increment_increment,在GROUP中范围在1-9(因为一个GROUP最两只好有9个组成员),GROUP中设置的时候,默以为7;
    • auto_increment_offset,增幅,GROUP安装进程,是格外@@server_id的,然而注意有个准绳是,当 auto_increment_offset > auto_increment_increment的时候,则是忽视 auto_increment_offset的装置,第一个insert的从1开头,组内其余成员的开头值按照插入顺序 1 n*组员个数,若GROUP有3个成员,A,B,C,serverid分别为2243310,2243320,3423340,A先insert,C再insert,B最终insert,则开端值 A是1,B是9,C是6 (测量检验结论,未找到实际表明文书档案)
    1 mysql> show global variables like 'auto_inc%';
    2  -------------------------- --------- 
    3 | Variable_name            | Value   |
    4  -------------------------- --------- 
    5 | auto_increment_increment | 7       |
    6 | auto_increment_offset    | 2143340 |
    7  -------------------------- --------- 
    8 2 rows in set (0.00 sec)
    

     

           1、创造同步用户:

    **2.1.3 隔开等第**

        官方网址提出选取READ COMMITTED级别,除非应用程序正视于REPLEATABLE READ,RC形式下并未有GAP LOCK,相比好协助Innodb自个儿的争辩检验机制何组复制的当中布满式检验机制一齐协同专门的职业。不扶助SECR-VIALIZABLE隔绝品级。

    **2.1.3 隔开分离等第**

        官方网址建议使用READ COMMITTED等级,除非应用程序依赖于REPLEATABLE READ,RC格局下并未有GAP LOCK,相比好帮助Innodb自己的争辩检查实验机制何组复制的里边遍布式检测机制一同协同职业。不帮衬SE凯雷德IALIZABLE隔断品级。

    2.2 安装mysql_replication引擎前提

    • master info and relay log info repositories
      • master_info_repository
        • set global master_info_repository ='table';
      • relay_log_info_repository
        • set global relay_log_info_repository=‘table';
      • 万一不安装会报错,报错音信如下
        • [ERROR] For the creation of replication channels the master info and relay log info repositories must be set to TABLE
    • binlog_checksum
      • binlog的校验格局应该设置为none
      • 要是不设置,报错品质如下
      • [ERROR] Plugin group_replication reported: 'binlog_checksum should be NONE for Group Replication'

                  服务器A:

    **2.1.4 外键**

        不建议利用级联外键,假设旧库自身有外键,业务上不只怕去除况且利用的是多主形式,那么,请配置 group_replication_enforce_update_everywhere_check ,强制检查各类组成员的级联合检查查,制止多主方式下试行级联操作导致的检验不到的冲突。

    **2.1.4 外键**

        不建议选拔级联外键,如若旧库本人有外键,业务上不能够去除并且应用的是多主方式,那么,请配置 group_replication_enforce_update_everywhere_check ,强制检查每种组成员的级联合检查查,幸免多主方式下进行级联操作导致的检查评定不到的争辩。

    2.3 别的参数供给

    • binary log设置
      • 急需运营记录binary log,任何复制都供给使用到二进制内容
      • 在布置文件中增多 log-bin = [binlog存款和储蓄路线及命超方式]
      • 例子: log-bin = /data/mysql/mysql3310/logs/bin_log
    • log-slave-updates设置
      • 默认情状下,主库同步到从库实行的剧情,是不发出binlog日志的,一般开启该参数是为着满足多级复制,比方A->B->C(A是B的主库,B是C的主库),那么这一年B就要求开启那一个参数记录从A同步到B下面的具备操作到binary log中,那样才具完整的联手到C上。
      • 而在MGLacrosse中,组中的server必要记录从组接收和动用的装有事务,因为复苏的时候,是依赖域各样组的二进制日志内容的。
      • 那么那一年,只怕就有个疑问,在多主方式下,假如实例A ,B , C三新北,各类实例修改的原委都记录到binary log中,再一起给其余组成员,那在B上进行工作 tranb : update了一条龙数据,tranb提交后一并到 A跟C,各自实践后,由于起步了log-slave-updates设置,A跟C也生成了binary log,那么那么些日记借使再一齐回B,再举办一回,不就也许出现难点了呢?实际上这么些忧虑是剩下的,在MG帕杰罗中,运营了GTID格局,会检查GTID EXCUTED集结,如若是早就实施的,则不会重新试行。
    • binary log格式
      • 名爵途锐依赖以及与行复制格式
      • binlog_format=row
    • GTID方式运行
      • 组复制使用全局专门的学问标志符来记录哪些专门的工作已在具有server实例上交给,从而推断哪些是已提交业务哪些是争执事务,制止重新推行及数量不雷同
      • gtid_mode=ON
    • transaction_write_set_extraction
      • 新葡亰496net,其一美妙的参数5.7.6版本引进,用于定义一个记录事务的算法,这一个算法使用hash标记来记录事务。假诺运用MG福特Explorer,那么那些hash值须要用于布满式争执检查实验何管理,在60个人的系统,官方网址提出安装该参数使用 XXHASH64 算法。
      • transaction_write_set_extraction ='XXHASH64'
      • 官方网址解释:Defines the algorithm used to generate a hash identifying the writes associated with a transaction. If you are using Group Replication, the hash value is used for distributed conflict detection and handling. On 64-bit systems running Group Replication, we recommend setting this to XXHASH64 in order to avoid unnecessary hash collisions which result in certification failures and the roll back of user transactions

             grant replication slave,file on *.* to 'replication'@'192.168.1.110' identified by '123456';

    **2.1.5 IPv4网络,互连网品质稳固延迟小带宽充裕**

    **2.1.5 IPv4网络,网络品质牢固延迟小带宽充裕**

    3 搭建Mysql Group Replication

    此次搭建接纳3个实例,七个服务器,同八个网段,MG奥迪Q5的参数配置在配备文件中加上。

    • 瞩目通信端口号的布局,它用于组成员之间的简报应用
    • 请分明当前MySQL版本为5.7.17要么未来版本
    • 种种实例的serverid必须是独一标志,建议使用ip末端 端口描述

    基础音讯如下:  

    实例名 A B C
    IP 192.168.9.242 192.168.9.242 192.168.9.244
    实例端口号 3310 3320 3340
    Server-ID 2423310 2423320 2443340
    通讯端口号 24201 24202 24404
    MySQL Versoin 5.7.17 5.7.17 5.7.17
    MGR参数配置方式 修改配置文件 修改配置文件 修改配置文件

     

    flush privileges;

    **2.1.6 自增跟步长**

        这里须求专注到,搭建group的时候,各种实例中的auto_increment_increment跟auto_increment_offset的计划意况。

    • auto_increment_increment,在GROUP中范围在1-9(因为一个GROUP最八只好有9个组成员),GROUP中装置的时候,默许为7;
    • auto_increment_offset,增幅,GROUP安装进程,是相等@@server_id的,不过注意有个法则是,当 auto_increment_offset > auto_increment_increment的时候,则是忽视 auto_increment_offset的装置,第多少个insert的从1初步,组内别的成员的起头值遵照插入顺序 1 n*组员个数,若GROUP有3个成员,A,B,C,serverid分别为2243310,2243320,3423340,A先insert,C再insert,B最终insert,则伊始值 A是1,B是9,C是6 (测验结论,未找到实际表达文书档案)

      1 mysql> show global variables like 'auto_inc%'; 2 -------------------------- --------- 3 | Variable_name | Value | 4 -------------------------- --------- 5 | auto_increment_increment | 7 | 6 | auto_increment_offset | 2143340 | 7 -------------------------- --------- 8 2 rows in set (0.00 sec)

     

    **2.1.6 自增跟步长**

        这里要求注意到,搭建group的时候,各种实例中的auto_increment_increment跟auto_increment_offset的配置情况。

    • auto_increment_increment,在GROUP中范围在1-9(因为四个GROUP最四只好有9个组成员),GROUP中设置的时候,默感到7;
    • auto_increment_offset,增长幅度,GROUP安装进度,是相等@@server_id的,但是注意有个法则是,当 auto_increment_offset > auto_increment_increment的时候,则是忽视 auto_increment_offset的装置,第二个insert的从1始发,组内其余成员的早先值依据插入顺序 1 n*组员个数,若GROUP有3个分子,A,B,C,serverid分别为2243310,2243320,3423340,A先insert,C再insert,B最终insert,则开首值 A是1,B是9,C是6 (测验结论,未找到实际表达文书档案)

      1 mysql> show global variables like 'auto_inc%'; 2 -------------------------- --------- 3 | Variable_name | Value | 4 -------------------------- --------- 5 | auto_increment_increment | 7 | 6 | auto_increment_offset | 2143340 | 7 -------------------------- --------- 8 2 rows in set (0.00 sec)

     

    3.1 单主情势(group_replication_single_primary_mode =ON

    服务器B:

    2.2 安装mysql_replication引擎前提

    • master info and relay log info repositories
      • master_info_repository
        • set global master_info_repository ='table';
      • relay_log_info_repository
        • set global relay_log_info_repository=‘table';
      • 要是不设置会报错,报错消息如下
        • [ERROR] For the creation of replication channels the master info and relay log info repositories must be set to TABLE
    • binlog_checksum
      • binlog的校验格局应该安装为none
      • 举个例子不安装,报错质量如下
      • [ERROR] Plugin group_replication reported: 'binlog_checksum should be NONE for Group Replication'

    2.2 安装mysql_replication引擎前提

    • master info and relay log info repositories
      • master_info_repository
        • set global master_info_repository ='table';
      • relay_log_info_repository
        • set global relay_log_info_repository=‘table';
      • 若果不安装会报错,报错音讯如下
        • [ERROR] For the creation of replication channels the master info and relay log info repositories must be set to TABLE
    • binlog_checksum
      • binlog的校验情势应该安装为none
      • 设若不设置,报错品质如下
      • [ERROR] Plugin group_replication reported: 'binlog_checksum should be NONE for Group Replication'

    3.1.1 主机名修改

        为了有利于后续处理维护以及部分不须求的不当,刚强提议修改主机名,尤其是当同个GROUP里边的SEENVISIONVE奇骏主机名都以一模二样的事态下,由于本身在虚构机中测验,虚构机的主机名都是均等的,导致后续出现了部分主题素材,建议修改。 注目的在于两台SELacrosseVEOdyssey上都修改哈!

     1 #查看当前主机名
     2 hostname
     3 
     4 #修改主机名
     5 hostname sutest242
     6 
     7 #进入vim /etc/hosts 
     8 #添加记录,不要修改默认的 127.0.0.1跟::1的记录,其他的系统服务会使用到的
     9 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    10 ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    11 192.168.9.242 sutest242
    12 192.168.9.244 sutest244
    

    陈设后检查如下:  新葡亰496net 16

    grant replication slave,file on *.* to 'replication'@'192.168.1.108' identified by '123456';

    2.3 其余参数必要

    • binary log设置
      • 内需运营记录binary log,任何复制都亟需动用到二进制内容
      • 在陈设文件中增添 log-bin = [binlog存款和储蓄路径及命超格局]
      • 例子: log-bin = /data/mysql/mysql3310/logs/bin_log
    • log-slave-updates设置
      • 默许意况下,主库同步到从库试行的开始和结果,是不发出binlog日志的,一般开启该参数是为了满足多级复制,比方A->B->C(A是B的主库,B是C的主库),那么今年B就需求打开这一个参数记录从A同步到B上面包车型大巴保有操作到binary log中,这样本领完好的一块儿到C上。
      • 而在名爵R中,组中的server必要记录从组接收和采纳的持有职业,因为复苏的时候,是重视域种种组的二进制日志内容的。
      • 那正是说今年,恐怕就有个疑问,在多主形式下,要是实例A ,B , C三台南,各类实例修改的内容都记录到binary log中,再一齐给另外组成员,那在B上实施工作 tranb : update了一条龙数据,tranb提交后联手到 A跟C,各自实践后,由于起步了log-slave-updates设置,A跟C也生成了binary log,那么这一个日记假使再一并回B,再实践一次,不就大概现身难点了啊?实际上那一个忧虑是剩下的,在MG凯雷德中,运维了GTID情势,会检查GTID EXCUTED会集,即使是已经举办的,则不会再次施行。
    • binary log格式
      • MGMurano正视以及与行复制格式
      • binlog_format=row
    • GTID格局运维
      • 组复制使用全局专门的工作标志符来记录哪些事情已在具有server实例上提交,进而决断什么是已交由业务哪些是争持事务,防止双重推行及数据不等同
      • gtid_mode=ON
    • transaction_write_set_extraction
      • 那个美妙的参数5.7.6本子引进,用于定义一个记下事务的算法,这几个算法使用hash标志来记录事务。倘使接纳MG奥德赛,那么那个hash值需求用于布满式争辨检查实验何处理,在陆拾人的种类,官方网站建议设置该参数使用 XXHASH64 算法。
      • transaction_write_set_extraction ='XXHASH64'
      • 官方网站解释:Defines the algorithm used to generate a hash identifying the writes associated with a transaction. If you are using Group Replication, the hash value is used for distributed conflict detection and handling. On 64-bit systems running Group Replication, we recommend setting this to XXHASH64 in order to avoid unnecessary hash collisions which result in certification failures and the roll back of user transactions

    2.3 其余参数供给

    • binary log设置
      • 亟需运行记录binary log,任何复制都亟待运用到二进制内容
      • 在布署文件中加多 log-bin = [binlog存款和储蓄路线及命有名的模特式]
      • 例子: log-bin = /data/mysql/mysql3310/logs/bin_log
    • log-slave-updates设置
      • 私下认可意况下,主库同步到从库实践的从头到尾的经过,是不发出binlog日志的,一般开启该参数是为了满足多级复制,比方A->B->C(A是B的主库,B是C的主库),那么那一年B就须求张开那些参数记录从A同步到B上面的持有操作到binary log中,那样才具全体的一块儿到C上。
      • 而在MG凯雷德中,组中的server须要记录从组接收和行使的保有业务,因为复苏的时候,是注重域各种组的二进制日志内容的。
      • 那正是说今年,恐怕就有个疑问,在多主形式下,假诺实例A ,B , C三高雄,每种实例修改的开始和结果都记录到binary log中,再同台给任何组成员,那在B上举办职业 tranb : update了一行数据,tranb提交后一并到 A跟C,各自推行后,由于起步了log-slave-updates设置,A跟C也生成了binary log,那么这几个日记如若再同台回B,再实行贰遍,不就可能出现难点了呢?实际上这些顾忌是多余的,在MG福特Explorer中,运转了GTID形式,会检讨GTID EXCUTED群集,假设是现已施行的,则不会另行试行。
    • binary log格式
      • MGXC90信赖以及与行复制格式
      • binlog_format=row
    • GTID情势运转
      • 组复制使用全局职业标志符来记录哪些事情已在全数server实例上交给,进而剖断什么是已交由业务哪些是争论事务,防止再次试行及数量不雷同
      • gtid_mode=ON
    • transaction_write_set_extraction
      • 其一神奇的参数5.7.6版本引进,用于定义三个笔录事务的算法,这么些算法使用hash标记来记录事务。假使利用名爵Enclave,那么那几个hash值要求用于布满式龃龉检验何管理,在六贰十一个人的系统,官方网址提出安装该参数使用 XXHASH64 算法。
      • transaction_write_set_extraction ='XXHASH64'
      • 官方网站解释:Defines the algorithm used to generate a hash identifying the writes associated with a transaction. If you are using Group Replication, the hash value is used for distributed conflict detection and handling. On 64-bit systems running Group Replication, we recommend setting this to XXHASH64 in order to avoid unnecessary hash collisions which result in certification failures and the roll back of user transactions

    3.1.2 设置意况变量

    有关GTID及日志新闻记录相关参数(这一部分的参数设置含义能够查看 第二有的:配置供给与限定 gtid_mode=on enforce-gtid-consistency=on binlog_gtid_simple_recovery=1 log-slave-updates=1 binlog_checksum=NONE master_info_repository=TABLE relay_log_info_repository=TABLE   至于MGRAV4相关参数表达 transaction_write_set_extraction #记录事务的算法 group_replication_start_on_boot #是还是不是随服务器运营而机关运维组复制 group_replication_bootstrap_group #随机应变组成员的组,那些用于第一回搭建MGOdyssey跟重新搭建MGMurano的时候利用 group_replication_group_name  #此GROUP的名字,必须是一个得力的UUID,以此来区分整个内网里边的逐一不的GROUP group_replication_local_address #本土的IP地址字符串,host:port group_replication_group_seeds  #亟待经受本实例的音信服务器IP地址字符串 group_replication_single_primary_mode #是否运维单主形式,假使开发银行,则本实例是主库,提供读写,其余实例仅提供读 group_replication_enforce_update_everywhere_checks #多主形式下,强制检查每一个实例是或不是允许该操作   关于名爵RAV4相关参数配置

     1 #动态配置:
     2 set global transaction_write_set_extraction='XXHASH64';
     3 set global group_replication_start_on_boot=OFF;
     4 set global group_replication_bootstrap_group = OFF ;
     5 set global group_replication_group_name= '9ac06b4e-13aa-11e7-a62e-5254004347f9'; #某个UUID
     6 set global group_replication_local_address='192.168.9.242:24201';
     7 set global group_replication_group_seeds ='192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401';
     8 set global group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24';
     9 set global group_replication_single_primary_mode=True;
    10 set global group_replication_enforce_update_everywhere_checks=False;
    11  
    12 #cnf文件配置:
    13 server-id=12001
    14 transaction_write_set_extraction = XXHASH64
    15 loose-group_replication_group_name = '9ac06b4e-13aa-11e7-a62e-5254004347f9'
    16 loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24'
    17 loose-group_replication_start_on_boot = OFF
    18 loose-group_replication_local_address = '192.168.9.242:24201'
    19 loose-group_replication_group_seeds = '192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401'
    20 loose-group_replication_bootstrap_group = OFF
    21 loose-group_replication_single_primary_mode = true
    22 loose-group_replication_enforce_update_everywhere_checks = false
    

          这一步这里运用配备文件增添的情势,增添成功后重启数据库服务。  新葡亰496net 17

    flush privileges;

    3 搭建Mysql Group Replication

    本次搭建采纳3个实例,多个服务器,同二个网段,MG奥德赛的参数配置在配备文件中丰硕。

    • 小心通信端口号的布署,它用于组成员之间的报纸发表应用
    • 请明确当前MySQL版本为5.7.17要么现在版本
    • 各样实例的serverid必须是独一标记,建议采用ip末端 端口描述

    基本功消息如下:

     

    实例名
    A
    B
    C
    IP
    192.168.9.242
    192.168.9.242
    192.168.9.244
    实例端口号
    3310
    3320
    3340
    Server-ID
    2423310
    2423320
    2443340
    通讯端口号
    24201
    24202
    24404
    MySQL Versoin
    5.7.17
    5.7.17
    5.7.17
    MGR参数配置方式
    修改配置文件
    修改配置文件
    修改配置文件

     

    3 搭建Mysql Group Replication

    这次搭建选拔3个实例,七个服务器,同三个网段,MG奥迪Q5的参数配置在配置文件中充分。

    • 留心通信端口号的安顿,它用来组成员之间的通信应用
    • 请明确当前MySQL版本为5.7.17依旧未来版本
    • 各类实例的serverid必须是独占鳌头标记,提议选择ip末端 端口描述

    基本功新闻如下:

     

    实例名
    A
    B
    C
    IP
    192.168.9.242
    192.168.9.242
    192.168.9.244
    实例端口号
    3310
    3320
    3340
    Server-ID
    2423310
    2423320
    2443340
    通讯端口号
    24201
    24202
    24404
    MySQL Versoin
    5.7.17
    5.7.17
    5.7.17
    MGR参数配置方式
    修改配置文件
    修改配置文件
    修改配置文件

     

    3.1.3 建设构造复制账号

    GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.%' IDENTIFIED BY 'replforslave';

    2、修改mysql配置文件

    3.1 单主情势(group_replication_single_primary_mode =ON

    3.1 单主方式(group_replication_single_primary_mode =ON

    3.1.4 安装引擎

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';   就算出现1123荒谬,请查看当前的数据库版本是还是不是是5.7.17及其后的本子,只有这么些本子才有grou_replication插件 ERROR 1123 (HY000): Can't initialize function 'group_replication'; Plugin initialization function failed.   安装后,引擎私下认可会创制三个用户 _gr_user,提供group_replication引擎内部采用,其权力如下:  新葡亰496net 18 检查是否安装成功,show plugins;  新葡亰496net 19 来到了这一步,离成功已经相当近了,注意检查 步骤1-4,必须在各个实例大概server上都配备二遍。  

           A:

    3.1.1 主机名修改

        为了便利后续管理珍惜以及一些不供给的一无所能,刚烈提议修改主机名,特别是当同个GROUP里边的SERubiconVEOdyssey主机名都以千篇一律的意况下,由于作者在虚构机中测验,虚拟机的主机名都以同样的,导致持续出现了有的标题,建议修改。

    注意在两台SEHighlanderVE途乐上都修改哈!

     1 #查看当前主机名
     2 hostname
     3 
     4 #修改主机名
     5 hostname sutest242
     6 
     7 #进入vim /etc/hosts 
     8 #添加记录,不要修改默认的 127.0.0.1跟::1的记录,其他的系统服务会使用到的
     9 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    10 ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    11 192.168.9.242 sutest242
    12 192.168.9.244 sutest244
    

    布局后检查如下:

     新葡亰496net 20

    3.1.1 主机名修改

        为了方便后续管理有限支撑以及部分不须要的不当,刚毅提出修改主机名,越发是当同个GROUP里边的SE大切诺基VE福睿斯主机名没什么不一致的情事下,由于本人在设想机中测验,虚构机的主机名都以一致的,导致后续出现了一部分主题素材,提出修改。

    留目的在于两台SELANDVERubicon上都修改哈!

     1 #查看当前主机名
     2 hostname
     3 
     4 #修改主机名
     5 hostname sutest242
     6 
     7 #进入vim /etc/hosts 
     8 #添加记录,不要修改默认的 127.0.0.1跟::1的记录,其他的系统服务会使用到的
     9 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    10 ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    11 192.168.9.242 sutest242
    12 192.168.9.244 sutest244
    

    安排后检查如下:

     新葡亰496net 21

    3.1.5  配置Group

    依照先把实例A参与Group中,由于是首先个加盟Group中,必要运营group_replication_bootstrap_group,指导组,实例A参与成功后,时有时无投入实例B及实例C。   首先,对实例A举办操作:

     1 #实例A
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 启动 group_replication_bootstrap_group
     6 SET GLOBAL group_replication_bootstrap_group=ON;
     7  
     8 #3 配置MGR
     9 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    10  
    11 #4 启动MGR
    12 start group_replication;
    13  
    14 #5 查看Error log,截图如下
    15 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    16  
    17 #6 关闭 group_replication_bootstrap_group
    18 SET GLOBAL group_replication_bootstrap_group=OFF;
    

     新葡亰496net 22  步向到多少目录,开采新建了多少个文件:  新葡亰496net 23  *_apaplier.*  种类文件 提供 SQL_Thread 使用,存款和储蓄同个组内其余SE哈弗VE牧马人的binnary log,这几个文件在首先个组成员加入组的时候,可以在Error Log看到其设置新闻。 *_recovery.* 体系文件 是做什么样使用的啊,在首先个成员运转MGSportage的时候,并不曾观看其有关消息,稍后解疑! 先在实例A上上马造数据,建立数据库mgr,创建表格tb1,INSERT部分数据,操作如下: 新葡亰496net 24#实例A mysql> create database mgr; Query OK, 1 row affected (0.01 sec) mysql> use mgr Database changed mysql> create table tb1(id int primary key auto_increment not null,name varchar(100)); Query OK, 0 rows affected (0.10 sec) mysql> insert into tb1(name) select @@server_id; Query OK, 1 row affected (0.09 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> insert into tb1(name) select @@server_id; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> insert into tb1(name) select @@server_id; Query OK, 1 row affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> insert into tb1(name) select @@server_id; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> select * from tb1; ---- --------- | id | name | ---- --------- | 6 | 2423310 | | 13 | 2423310 | | 20 | 2423310 | | 27 | 2423310 | ---- --------- 4 rows in set (0.00 sec) mysql> show master status; ---------------- ---------- -------------- ------------------ ------------------------------------------ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | ---------------- ---------- -------------- ------------------ ------------------------------------------ | bin_log.000002 | 1795 | | | 9ac06b4e-13aa-11e7-a62e-5254004347f9:1-7 | ---------------- ---------- -------------- ------------------ ------------------------------------------ 1 row in set (0.00 sec) 模拟数据操作   接着,对实例B 进行操作:

     1 #实例B
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

     新葡亰496net 25

        通过errrlog,能够详细察看运维进度的享有手续信息,由于新扩大多少,导致实例B供给使用到 group_replication_recovery 通道来苏醒数据。然则是怎么二个回复进程吧?查看 *_recovery.* 种类文件 都以唯有文件头尚未binlog内容的公文。 在参加实例C此前,再一次在实例A上造数据,此番造多大多据。新建表格tb2,设置2个大字段,然后insert 2w 的数据量。

     1 #实例A
     2 mysql> use mgr
     3 Database changed
     4 mysql> create table tb2(id int auto_increment primary key not null,namea varchar(8000),nameb varchar(8000));
     5 Query OK, 0 rows affected (0.03 sec)
     6 
     7 mysql> insert into tb2(namea,nameb) select repeat('a',8000),repeat('b',8000);
     8 Query OK, 1 row affected (0.02 sec)
     9 Records: 1  Duplicates: 0  Warnings: 0
    10 
    11 #insert 自行操作,看试验需要,本次需要大量数据来recovery,所以后面采用 insert into tb2 .. select .. from tb2 方式造数据 2w 行
    

      最后,对实例C 进行操作:

     1 #实例C
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

    通过errrlog,能够详细察看运维进程的保有手续消息,由于新添多少,导致实例C须要选择到 group_replication_recovery 通道来还原数据,那跟实例B是一模一样的进度,可是,由于中期实例A造了大气的数额,所以在漫天recovery的历程中,能够查看到  *_recovery.* 体系文件 的成形情形。 新葡亰496net 26     通过error log大小的调换,是因此group_replication_recovery 通道来回复数据,须要恢复生机的binary log是存放在 *_recovery.* 类别文件 ,通过这次recovery 文件查看,开采,在recovery进程中,通道内的IO_THREAD拉去日志存款和储蓄在 *_recovery.* 连串文件 中,当通道内的 SQL_Thread 完结日志应用后,则会去除掉 *_recovery.* 类别文件 文件,新建空文件,代表曾经远非数据须要还原。     至此,单主方式已搭建达成,实例A可提供读写,但是实例B跟实例C仅提供读服务。     新葡亰496net 27

        在搭建的进度中,也理清了几个第一通道的利用境况:

    • group_replication_applier 通道 提供组内成员向 MASTE福特Explorer实时同步binlog日志使用,那些通道内IO_thread拉取到的日志贮存在 *_apaplier.* 体系文件中,再经过SQL_Thread应用到组内的一一SE索罗德VE揽胜上。
    • group_replication_recovery 通道 提供 第一遍参与GROUP或然重新插手GROUP时恢复生机数据利用,那些通道内 IO_thread拉取到的日记贮存在 *_recovery.* 连串文件中,再通过SQL_Thread应用到组内的依次SEPAJEROVE昂Cora上,应用截至后,删除全体  *_recovery.* 体系文件 ,重新创立新的 *_recovery.* 连串文件。

    能够因而P_S库中的表格查询利用状态:SELECT * FROM mysql.slave_relay_log_info  

    log-bin=mysql-bin
    server-id       = 1
    binlog-do-db=test
    binlog-ignore-db=mysql
    replicate-do-db=test
    replicate-ignore-db=mysql
    log-slave-updates
    sync_binlog=1
    auto_increment_increment=2
    auto_increment_offset=1

    3.1.2 设置情形变量

    至于GTID及日志音信记录相关参数(这部分的参数设置含义能够查看 第二有个别:配置须要与限定

    gtid_mode=on

    enforce-gtid-consistency=on

    binlog_gtid_simple_recovery=1

    log-slave-updates=1

    binlog_checksum=NONE

    配备维护故障处理全集,Mysql主主同步。master_info_repository=TABLE

    relay_log_info_repository=TABLE

     

    关于MG大切诺基相关参数表明

    transaction_write_set_extraction #记录事务的算法

    group_replication_start_on_boot #是否随服务器运营而机关运转组复制

    group_replication_bootstrap_group #根据各省的具体情况制定方案组成员的组,那一个用于第二次搭建MGSportage跟重新搭建MGCR-V的时候使用

    group_replication_group_name  #此GROUP的名字,必须是一个管用的UUID,以此来区分整个内网里边的次第不的GROUP

    group_replication_local_address #地面的IP地址字符串,host:port

    group_replication_group_seeds  #亟需经受本实例的音讯服务器IP地址字符串

    group_replication_single_primary_mode #是还是不是运转单主方式,若是开发银行,则本实例是主库,提供读写,其余实例仅提供读

    group_replication_enforce_update_everywhere_checks #多主格局下,强制检查每二个实例是还是不是允许该操作

     

    有关MG奥德赛相关参数配置

     1 #动态配置:
     2 set global transaction_write_set_extraction='XXHASH64';
     3 set global group_replication_start_on_boot=OFF;
     4 set global group_replication_bootstrap_group = OFF ;
     5 set global group_replication_group_name= '9ac06b4e-13aa-11e7-a62e-5254004347f9'; #某个UUID
     6 set global group_replication_local_address='192.168.9.242:24201';
     7 set global group_replication_group_seeds ='192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401';
     8 set global group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24';
     9 set global group_replication_single_primary_mode=True;
    10 set global group_replication_enforce_update_everywhere_checks=False;
    11  
    12 #cnf文件配置:
    13 server-id=12001
    14 transaction_write_set_extraction = XXHASH64
    15 loose-group_replication_group_name = '9ac06b4e-13aa-11e7-a62e-5254004347f9'
    16 loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24'
    17 loose-group_replication_start_on_boot = OFF
    18 loose-group_replication_local_address = '192.168.9.242:24201'
    19 loose-group_replication_group_seeds = '192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401'
    20 loose-group_replication_bootstrap_group = OFF
    21 loose-group_replication_single_primary_mode = true
    22 loose-group_replication_enforce_update_everywhere_checks = false
    

     

        这一步这里运用配备文件增加的艺术,加上成功后重启数据库服务。

     新葡亰496net 28

    3.1.2 设置情况变量

    有关GTID及日志音讯记录相关参数(那部分的参数设置含义能够查看 第二部分:配置须要与限定

    gtid_mode=on

    enforce-gtid-consistency=on

    binlog_gtid_simple_recovery=1

    log-slave-updates=1

    binlog_checksum=NONE

    master_info_repository=TABLE

    relay_log_info_repository=TABLE

     

    有关MG纳瓦拉相关参数表明

    transaction_write_set_extraction #笔录事务的算法

    group_replication_start_on_boot #是不是随服务器运营而自动运维组复制

    group_replication_bootstrap_group #引导组成员的组,那一个用于第叁回搭建MGRubicon跟重新搭建MG奥迪Q5的时候使用

    group_replication_group_name  #此GROUP的名字,必须是三个卓有功效的UUID,以此来分别整个内网里边的逐条不的GROUP

    group_replication_local_address #地点的IP地址字符串,host:port

    group_replication_group_seeds  #要求承受本实例的音讯服务器IP地址字符串

    group_replication_single_primary_mode #是否运维单主方式,假设开行,则本实例是主库,提供读写,其余实例仅提供读

    group_replication_enforce_update_everywhere_checks #多主格局下,强制检查每多少个实例是还是不是同意该操作

     

    至于MG中华V相关参数配置

     1 #动态配置:
     2 set global transaction_write_set_extraction='XXHASH64';
     3 set global group_replication_start_on_boot=OFF;
     4 set global group_replication_bootstrap_group = OFF ;
     5 set global group_replication_group_name= '9ac06b4e-13aa-11e7-a62e-5254004347f9'; #某个UUID
     6 set global group_replication_local_address='192.168.9.242:24201';
     7 set global group_replication_group_seeds ='192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401';
     8 set global group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24';
     9 set global group_replication_single_primary_mode=True;
    10 set global group_replication_enforce_update_everywhere_checks=False;
    11  
    12 #cnf文件配置:
    13 server-id=12001
    14 transaction_write_set_extraction = XXHASH64
    15 loose-group_replication_group_name = '9ac06b4e-13aa-11e7-a62e-5254004347f9'
    16 loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.9.0/24'
    17 loose-group_replication_start_on_boot = OFF
    18 loose-group_replication_local_address = '192.168.9.242:24201'
    19 loose-group_replication_group_seeds = '192.168.9.242:24201,192.168.9.242:24202,192.168.9.242:24401'
    20 loose-group_replication_bootstrap_group = OFF
    21 loose-group_replication_single_primary_mode = true
    22 loose-group_replication_enforce_update_everywhere_checks = false
    

     

        这一步这里运用配备文件增加的艺术,丰盛成功后重启数据库服务。

     新葡亰496net 29

    3.2 多主形式(group_replication_single_primary_mode =OFF

        多主形式如何安排呢,其实跟 单主方式的流程完全一样,只须求修改 3.1 单主情势 中第二部 配置情状变量中,把 group_replication_single_primary_mode 参数设置成关闭状态就可以,然后根据 单足格局的一向施行就足以了。

    # 动态修复方式
    set global group_replication_single_primary_mode=OFF;
    
    # 配置文件修改方式
    loose-group_replication_single_primary_mode = OFF
    

          但是,既然说起布置多主格局,除了从头就直接配置多主外,还只怕有一种处境是,本来是单主形式,今后涂改为多主格局,那一个转换进度,则是这有的要来描述的。     首先,思索到的是,能不能够直接在多主形式运维的事态下,就径直动态修改那个参数呢?因为这些参数是能够动态调解,BUT,在 GROUP_REPLICATION 运营的进度中,是不能够改改那么些参数的,会本身的唤起您:  新葡亰496net 30       所以,须要新停掉GROUP_REPLICATION。       操作流程:业务端连接IP管理-> GROUP内成员相继依次主动退出GROUP -> 关闭 group_replication_single_primary_mode参数-> 各种运行GROUP内的SEWranglerVE传祺

           B:

    3.1.3 创设复制账号

    GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.%' IDENTIFIED BY 'replforslave';

    3.1.3 创设复制账号

    GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.%' IDENTIFIED BY 'replforslave';

    3.2.1 业务端连接IP管理  

        对程序端端影响:要是是程序直连主库,则不须要操心这些历程,不过倘如若通过第三方工具检查GROUP中的主库是哪位的话,必要先修改第三方工具直连原主库,因为具备Group内的积极分子都要停下服务,假使都以机关判定的话,最终会找不到GROUP中的成员的,所以,在开端切换的时候,就须要业务方固定读写在实例A上。

    log-bin=mysql-bin
    server-id       = 2
    binlog-do-db=test
    binlog-ignore-db=mysql
    replicate-do-db=test
    replicate-ignore-db=mysql
    log-slave-updates
    sync_binlog=1
    auto_increment_increment=2
    auto_increment_offset=2

    3.1.4 安装引擎

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';

     

    假如出现1123错误,请查看当前的数据库版本是不是是5.7.17及以往的本子,独有那一个本子才有grou_replication插件

    ERROR 1123 (HY000): Can't initialize function 'group_replication'; Plugin initialization function failed.

     

    安装后,引擎私下认可会创设八个用户 _gr_user,提供group_replication引擎内部选取,其权力如下:

     新葡亰496net 31

    检查是还是不是安装成功,show plugins;

     新葡亰496net 32

    到来了这一步,离成功已经相当的近了,注意检查 步骤1-4,必须在各类实例可能server上都安排贰遍。

     

    3.1.4 安装引擎

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';

     

    举个例子出现1123荒唐,请查看当前的数据库版本是还是不是是5.7.17及然后的本子,独有那么些本子才有grou_replication插件

    ERROR 1123 (HY000): Can't initialize function 'group_replication'; Plugin initialization function failed.

     

    安装后,引擎默许会创造三个用户 _gr_user,提供group_replication引擎内部采用,其权力如下:

     新葡亰496net 33

    自己斟酌是不是安装成功,show plugins;

     新葡亰496net 34

    来到了这一步,离成功已经相当近了,注意检查 步骤1-4,必须在各类实例只怕server上都安顿贰次。

     

    3.2.2 GROUP内成员相继依次主动退出GROUP

    连日来实例A:

    1 #实例A
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

    Error Log内容如下:  新葡亰496net 35     那年,A可读写,可是不在group中,其binlog内容不会在组内同步;C晋级自动进级为主库,可读写,binlog会共同到B上。此地的主库升级,是看MEMBE奥迪Q3_ID的升序排序情状,最小的进级为主库。 在B上经过表格 replication_group_members跟global_status,能够查看今后的组成员以及主库是哪位。查看截图如下:  新葡亰496net 36   连接实例B:

    1 #实例B
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

     新葡亰496net 37     这一年,A,B均能够读写,然则不在GROUP中,业务方今在A上运维,C也足以读写,近些日子是主库。   连接实例C:

    #实例c
    stop group_replication;
    

    新葡亰496net 38         那年,整个GROUP内的有着成员都一一自动退出了GROUP。

     

    3.1.5  配置Group

    依据先把实例A出席Group中,由于是第三个投入Group中,须要运维group_replication_bootstrap_group,引导组,实例A参加成功后,陆陆续续出席实例B及实例C。

     

    首先,对实例A进行操作:

     1 #实例A
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 启动 group_replication_bootstrap_group
     6 SET GLOBAL group_replication_bootstrap_group=ON;
     7  
     8 #3 配置MGR
     9 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    10  
    11 #4 启动MGR
    12 start group_replication;
    13  
    14 #5 查看Error log,截图如下
    15 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    16  
    17 #6 关闭 group_replication_bootstrap_group
    18 SET GLOBAL group_replication_bootstrap_group=OFF;
    

     新葡亰496net 39 

    跻身到多少目录,开采新建了多少个文件:

     新葡亰496net 40 

    *_apaplier.*  种类文件 提供 SQL_Thread 使用,存款和储蓄同个组内其他SE奔驰G级VERubicon的binnary log,这些文件在首先个组成员插手组的时候,能够在Error Log看到其设置新闻。

    *_recovery.* 体系文件 是做什么样使用的吗,在首先个成员运营MG本田UR-V的时候,并不曾观看其有关消息,稍后解疑!

    先在实例A上上马造数据,构建数据库mgr,建构表格tb1,INSERT部分数据,操作如下:

    新葡亰496net 41新葡亰496net 42

    #实例A
    mysql> create database mgr;
    Query OK, 1 row affected (0.01 sec)
    
    mysql> use mgr
    Database changed
    mysql> create table tb1(id int primary key auto_increment not null,name varchar(100));
    Query OK, 0 rows affected (0.10 sec)
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.09 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.00 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.01 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.00 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> select * from tb1;
     ---- --------- 
    | id | name    |
     ---- --------- 
    |  6 | 2423310 |
    | 13 | 2423310 |
    | 20 | 2423310 |
    | 27 | 2423310 |
     ---- --------- 
    4 rows in set (0.00 sec)
    
    mysql> show master status;
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    | File           | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    | bin_log.000002 |     1795 |              |                  | 9ac06b4e-13aa-11e7-a62e-5254004347f9:1-7 |
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    1 row in set (0.00 sec)
    

    仿照数据操作

     

    继而,对实例B 进行操作:

     1 #实例B
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

     新葡亰496net 43

        通过errrlog,能够详细察看运维进度的具有手续消息,由于新扩展多少,导致实例B供给动用到 group_replication_recovery 通道来平复数据。不过是怎么叁个过来进度吧?查看 *_recovery.* 类别文件 都以独有文件头尚未binlog内容的公文。

    在到场实例C在此以前,再度在实例A上造数据,这一次造多相当多据。新建表格tb2,设置2个大字段,然后insert 2w 的数据量。

     1 #实例A
     2 mysql> use mgr
     3 Database changed
     4 mysql> create table tb2(id int auto_increment primary key not null,namea varchar(8000),nameb varchar(8000));
     5 Query OK, 0 rows affected (0.03 sec)
     6 
     7 mysql> insert into tb2(namea,nameb) select repeat('a',8000),repeat('b',8000);
     8 Query OK, 1 row affected (0.02 sec)
     9 Records: 1  Duplicates: 0  Warnings: 0
    10 
    11 #insert 自行操作,看试验需要,本次需要大量数据来recovery,所以后面采用 insert into tb2 .. select .. from tb2 方式造数据 2w 行
    

     

    末尾,对实例C 实行操作:

     1 #实例C
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

    透过errrlog,能够详细看看运转进度的兼具手续消息,由于新扩大加少,导致实例C供给使用到 group_replication_recovery 通道来过来数据,那跟实例B是一模二样的进度,可是,由于早期实例A造了大批量的多少,所以在任何recovery的经过中,能够查看到  *_recovery.* 类别文件 的更换景况。

    新葡亰496net 44

        通过error log大小的转移,是经过group_replication_recovery 通道来还原数据,需求恢复生机的binary log是贮存在 *_recovery.* 种类文件 ,通过此次recovery 文件查看,开采,在recovery进度中,通道内的IO_THREAD拉去日志存款和储蓄在 *_recovery.* 体系文件 中,当通道内的 SQL_Thread 完毕日志应用后,则会去除掉 *_recovery.* 连串文件 文件,新建空文件,代表已经未有数量必要还原。

        至此,单主形式已搭建完成,实例A可提供读写,但是实例B跟实例C仅提供读服务。

        新葡亰496net 45

        在搭建的过程中,也理清了七个首要通道的应用状态:

    • group_replication_applier 通道 提供组内成员向 MASTELAND实时同步binlog日志使用,这一个通道内IO_thread拉取到的日记寄存在 *_apaplier.* 类别文件中,再经过SQL_Thread应用到组内的逐条SE奥迪Q5VE福睿斯上。
    • group_replication_recovery 通道 提供 第一次投入GROUP大概重新参与GROUP时恢复生机数据选拔,这么些通道内 IO_thread拉取到的日志存放在 *_recovery.* 连串文件中,再经过SQL_Thread应用到组内的逐一SEEnclaveVELAND上,应用截止后,删除全部  *_recovery.* 类别文件 ,重新确立新的 *_recovery.* 种类文件。

    能够透过P_S库中的表格查询利用景况:SELECT * FROM mysql.slave_relay_log_info

     

    3.1.5  配置Group

    依据先把实例A加入Group中,由于是率先个参加Group中,须求运行group_replication_bootstrap_group,指引组,实例A出席成功后,陆陆续续出席实例B及实例C。

     

    先是,对实例A举办操作:

     1 #实例A
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 启动 group_replication_bootstrap_group
     6 SET GLOBAL group_replication_bootstrap_group=ON;
     7  
     8 #3 配置MGR
     9 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    10  
    11 #4 启动MGR
    12 start group_replication;
    13  
    14 #5 查看Error log,截图如下
    15 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    16  
    17 #6 关闭 group_replication_bootstrap_group
    18 SET GLOBAL group_replication_bootstrap_group=OFF;
    

     新葡亰496net 46 

    进去到数码目录,开掘新建了多少个公文:

     新葡亰496net 47 

    *_apaplier.*  种类文件 提供 SQL_Thread 使用,存款和储蓄同个组内其余SEEscortVEEscort的binnary log,这一个文件在第四个组成员参加组的时候,能够在Error Log看到其安装新闻。

    *_recovery.* 类别文件 是做哪些使用的吧,在首先个分子运转MG大切诺基的时候,并未观察其相关信息,稍后解疑!

    先在实例A上上马造数据,营造数据库mgr,创设表格tb1,INSERT部分数据,操作如下:

    新葡亰496net 48新葡亰496net 49

    #实例A
    mysql> create database mgr;
    Query OK, 1 row affected (0.01 sec)
    
    mysql> use mgr
    Database changed
    mysql> create table tb1(id int primary key auto_increment not null,name varchar(100));
    Query OK, 0 rows affected (0.10 sec)
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.09 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.00 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.01 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> insert into tb1(name) select @@server_id;
    Query OK, 1 row affected (0.00 sec)
    Records: 1  Duplicates: 0  Warnings: 0
    
    mysql> select * from tb1;
     ---- --------- 
    | id | name    |
     ---- --------- 
    |  6 | 2423310 |
    | 13 | 2423310 |
    | 20 | 2423310 |
    | 27 | 2423310 |
     ---- --------- 
    4 rows in set (0.00 sec)
    
    mysql> show master status;
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    | File           | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    | bin_log.000002 |     1795 |              |                  | 9ac06b4e-13aa-11e7-a62e-5254004347f9:1-7 |
     ---------------- ---------- -------------- ------------------ ------------------------------------------ 
    1 row in set (0.00 sec)
    

    模仿数据操作

     

    随即,对实例B 进行操作:

     1 #实例B
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

     新葡亰496net 50

        通过errrlog,能够详细察看运维进度的具有手续音讯,由于新添多少,导致实例B须要接纳到 group_replication_recovery 通道来平复数据。可是是怎么三个重操旧业进程吧?查看 *_recovery.* 系列文件 都以独有文件头尚未binlog内容的公文。

    在参预实例C此前,再次在实例A上造数据,此番造多非常多据。新建表格tb2,设置2个大字段,然后insert 2w 的数据量。

     1 #实例A
     2 mysql> use mgr
     3 Database changed
     4 mysql> create table tb2(id int auto_increment primary key not null,namea varchar(8000),nameb varchar(8000));
     5 Query OK, 0 rows affected (0.03 sec)
     6 
     7 mysql> insert into tb2(namea,nameb) select repeat('a',8000),repeat('b',8000);
     8 Query OK, 1 row affected (0.02 sec)
     9 Records: 1  Duplicates: 0  Warnings: 0
    10 
    11 #insert 自行操作,看试验需要,本次需要大量数据来recovery,所以后面采用 insert into tb2 .. select .. from tb2 方式造数据 2w 行
    

     

    最后,对实例C 实行操作:

     1 #实例C
     2 #1 查看当前的group replication相关参数是否配置有误
     3 show global variables like 'group%';
     4  
     5 #2 配置MGR
     6 CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
     7  
     8 #3 启动MGR
     9 start group_replication;
    10  
    11 #4 查看Error log,截图如下
    12 #error log如果有问题,拉到本文末端,对应找错误,如果没有解决,请google或者留言
    

    透过errrlog,能够详细看看运行进程的具备手续音信,由于新扩大多少,导致实例C须求动用到 group_replication_recovery 通道来苏醒数据,那跟实例B是一模二样的进程,可是,由于早先时代实例A造了大气的数量,所以在全路recovery的历程中,能够查看到  *_recovery.* 类别文件 的成形处境。

    新葡亰496net 51

        通过error log大小的变动,是经过group_replication_recovery 通道来回复数据,供给恢复生机的binary log是寄存在 *_recovery.* 连串文件 ,通过本次recovery 文件查看,发现,在recovery进程中,通道内的IO_THREAD拉去日志存款和储蓄在 *_recovery.* 连串文件 中,当通道内的 SQL_Thread 实现日志应用后,则会去除掉 *_recovery.* 类别文件 文件,新建空文件,代表已经远非多少必要还原。

        至此,单主格局已搭建达成,实例A可提供读写,可是实例B跟实例C仅提供读服务。

        新葡亰496net 52

        在搭建的进度中,也理清了四个十分重要通道的应用情形:

    • group_replication_applier 通道 提供组内成员向 MASTESportage实时同步binlog日志使用,那个通道内IO_thread拉取到的日记寄存在 *_apaplier.* 系列文件中,再通过SQL_Thread应用到组内的逐个SE日产GT-RVELacrosse上。
    • group_replication_recovery 通道 提供 第叁次投入GROUP或然重新插手GROUP时苏醒数据应用,那个通道内 IO_thread拉取到的日记寄存在 *_recovery.* 类别文件中,再经过SQL_Thread应用到组内的逐个SE奥迪Q5VELX570上,应用甘休后,删除全数  *_recovery.* 类别文件 ,重新确立新的 *_recovery.* 体系文件。

    能够透过P_S库中的表格查询利用状态:SELECT * FROM mysql.slave_relay_log_info

     

    3.2.3 关闭 group_replication_single_primary_mode参数

        要求修改2个地点,第二个是动态修改参数,第三个是到安顿文件中期维修改参数(幸免DB服务重启,参数失效)!

    #动态修改
    #实例A
    set global group_replication_single_primary_mode =OFF
    
    #实例B
    set global group_replication_single_primary_mode =OFF
    
    #实例C
    set global group_replication_single_primary_mode =OFF
    
    
    #配置文件添加
    #实例A的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例B的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例C的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    

      为了模仿有业务在实例A上操作,在实例A上创制表格 tb4,并导入tb2的具备数据  

    #实例A
    mysql> create table tb4 like tb2;
    Query OK, 0 rows affected (0.18 sec)
    
    mysql> insert into tb4 select * from tb2;
    Query OK, 20480 rows affected (33.13 sec)
    Records: 20480  Duplicates: 0  Warnings: 0
    

    参数选项表达:
    log-slave-updates    将推行的复制sql记录到二进制日志
    sync_binlog  当有二进制日志写入binlog文件的时候,mysql服务器将它一齐到磁盘上
    auto_increment_increment,auto_increment_offset 主要用于主主复制中,用来调控AUTO_INCREMENT列的操作

    3.2 多主形式(group_replication_single_primary_mode =OFF

        多主情势怎样安顿呢,其实跟 单主情势的流程一模一样,只须求修改 3.1 单主方式 中第二部 配置情况变量中,把 group_replication_single_primary_mode 参数设置成关闭状态就能够,然后依据 单足形式的一贯实践就足以了。

    # 动态修复方式
    set global group_replication_single_primary_mode=OFF;
    
    # 配置文件修改方式
    loose-group_replication_single_primary_mode = OFF
    

     

        不过,既然提起铺排多主方式,除了从头就径直配置多主外,还会有一种意况是,本来是单主情势,以往修改为多主格局,那一个调换进度,则是那有个别要来描述的。

        首先,思考到的是,能无法直接在多主方式运维的事态下,就径直动态修改那几个参数呢?因为这些参数是能够动态调整,BUT,在 GROUP_REPLICATION 运维的长河中,是不可能改改这一个参数的,会融洽的唤起您:

     新葡亰496net 53

     

        所以,必要新停掉GROUP_REPLICATION。

     

        操作流程:业务端连接IP管理 -> GROUP内成员相继依次主动退出GROUP -> 关闭 group_replication_single_primary_mode参数-> 每一个运营GROUP内的SE奥迪Q7VER

    3.2 多主方式(group_replication_single_primary_mode =OFF

        多主方式怎样布署呢,其实跟 单主方式的流水生产线大同小异,只须求修改 3.1 单主情势 中第二部 配置遭逢变量中,把 group_replication_single_primary_mode 参数设置成关闭状态就可以,然后遵照 单足形式的直白实行就能够了。

    # 动态修复方式
    set global group_replication_single_primary_mode=OFF;
    
    # 配置文件修改方式
    loose-group_replication_single_primary_mode = OFF
    

     

        不过,既然谈到计划多主情势,除了从头就径直配备多主外,还应该有一种景况是,本来是单主形式,现在涂改为多主格局,那几个转变进程,则是那有的要来描述的。

        首先,牵记到的是,能无法直接在多主情势运转的景况下,就直接动态修改那几个参数呢?因为那个参数是足以动态调解,BUT,在 GROUP_REPLICATION 运营的历程中,是不可能改改这些参数的,会融洽的提示您:

     新葡亰496net 54

     

        所以,要求新停掉GROUP_REPLICATION。

     

        操作流程:业务端连接IP处理 -> GROUP内成员相继依次主动退出GROUP -> 关闭 group_replication_single_primary_mode参数-> 各种运转GROUP内的SE奥迪Q3VEWrangler

    3.2.4 每个运营GROUP内的SE索罗德VEMurano

        首先针对实例A运行,然后运营实例B,紧接着运营实例C。这一个过程中,每投入三个组成员,记得去看error log是或不是有报错。 当A运行的时候,能够看看成了二个新的GROUP,B参加到时候,必要通过 group_replication_recovery 通道恢复生机数据,C到场到时候,也须要通过 group_replication_recovery 通道恢复生机数据,那有些的剧情跟 3.1. 5 配置Group 中的errorlog内容大概,这里就不做截图解析。  

    #实例A
    #需要启动 group_replication_bootstrap_group 引导组,启动后需要关闭,防止脑裂
    mysql> set global group_replication_bootstrap_group=ON;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.02 sec)
    
    mysql> START GROUP_REPLICATION;
    Query OK, 0 rows affected (1.16 sec)
    
    mysql> set global group_replication_bootstrap_group=Off;
    Query OK, 0 rows affected (0.00 sec)
    
    #实例B
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.04 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (4.31 sec)
    
    #实例C
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.07 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (3.83 sec)
    

          

    3.2.1 业务端连接IP管理  

        对先后端端影响:如若是先后直连主库,则没有须求顾虑这些进程,可是只若是经过第三方工具检查GROUP中的主库是哪些的话,要求先修改第三方工具直连原主库,因为具备Group内的成员都要适可而止服务,假若都以自动决断的话,最后会找不到GROUP中的成员的,所以,在起来切换的时候,就必要业务方固定读写在实例A上。

    3.2.1 业务端连接IP管理  

        对先后端端影响:假设是先后直连主库,则无需担忧那些进程,然而就算是因此第三方工具检查GROUP中的主库是哪些的话,供给先修改第三方工具直连原主库,因为具备Group内的成员都要适可而止服务,借使都以电动判定的话,最终会找不到GROUP中的成员的,所以,在上马切换的时候,就供给业务方固定读写在实例A上。

    3.2.5 检查今后GROUP情形

    当下GROUP中的种种成员都关门了super_read_only选项,提供了读写服务,由于多少个都为主库,属于多主情状,所以 global_status中不可能查看到主库是哪个,因为这么些GROUP中,每种SETiguanVE奇骏都是MASTE翼虎。  

    mysql> select * from performance_schema.replication_group_members;
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | group_replication_applier | 2ec0fecd-16a2-11e7-97e1-52540005b8e1 | sutest244   |        3340 | ONLINE       |
    | group_replication_applier | 94e39808-15ed-11e7-a7cf-52540005b8e2 | sutest242   |        3310 | ONLINE       |
    | group_replication_applier | 9b78d231-15ed-11e7-a82a-52540005b8e2 | sutest242   |        3320 | ONLINE       |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    3 rows in set (0.21 sec)
    
    mysql> select * from performance_schema.global_status where variable_name like '%group%';
     ---------------------------------- ---------------- 
    | VARIABLE_NAME                    | VARIABLE_VALUE |
     ---------------------------------- ---------------- 
    | group_replication_primary_member |                |
     ---------------------------------- ---------------- 
    1 row in set (0.35 sec)
    
    mysql> show global variables like 'group_replication_single_primary_mode';
     --------------------------------------- ------- 
    | Variable_name                         | Value |
     --------------------------------------- ------- 
    | group_replication_single_primary_mode | OFF   |
     --------------------------------------- ------- 
    1 row in set (0.33 sec)
    
    mysql> show global variables like 'super%';
     ----------------- ------- 
    | Variable_name   | Value |
     ----------------- ------- 
    | super_read_only | OFF   |
     ----------------- ------- 
    1 row in set (1.20 sec)
    

    时至前几天,多主情势已搭建达成,实例A、B、C均可提供读写。PS: 这里必要留心争辨管理体制,能够查阅第五片段的故障模拟。  新葡亰496net 55

           3、重启mysql服务后,步入mysql命令行,施行操作如下:

    3.2.2 GROUP内成员相继依次主动退出GROUP

    三翻五次实例A:

    1 #实例A
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

    Error Log内容如下:

     新葡亰496net 56

        那年,A可读写,不过不在group中,其binlog内容不会在组内同步;C晋级自动进级为主库,可读写,binlog会共同到B上。此地的主库进级,是看MEMBE兰德宝马7系_ID的升序排序景况,最小的升迁为主库

    在B上通过表格 replication_group_members跟global_status,能够查阅未来的组成员以及主库是哪位。查看截图如下: 

    新葡亰496net 57

     

    一连实例B:

    1 #实例B
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

     新葡亰496net 58

        今年,A,B均能够读写,不过不在GROUP中,业务这段日子在A上运转,C也足以读写,近日是主库。

     

    接连实例C:

    #实例c
    stop group_replication;
    

    新葡亰496net 59

       

        那年,整个GROUP内的保有成员都逐项自动退出了GROUP。

    3.2.2 GROUP内成员相继依次主动退出GROUP

    老是实例A:

    1 #实例A
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

    Error Log内容如下:

     新葡亰496net 60

        今年,A可读写,不过不在group中,其binlog内容不会在组内同步;C晋级自动晋级为主库,可读写,binlog会一同到B上。此间的主库进级,是看MEMBEQashqai_ID的升序排序处境,最小的升高为主库

    在B上经过表格 replication_group_members跟global_status,能够查阅现在的组成员以及主库是哪位。查看截图如下: 

    新葡亰496net 61

     

    老是实例B:

    1 #实例B
    2 stop group_replication;
    3  
    4 #检查实例B,C的error log,发现实例A主动退出,group成员删除实例A
    

     新葡亰496net 62

        这年,A,B均能够读写,然则不在GROUP中,业务近年来在A上运转,C也足以读写,近期是主库。

     

    连年实例C:

    #实例c
    stop group_replication;
    

    新葡亰496net 63

       

        那个时候,整个GROUP内的保有成员都逐项自动退出了GROUP。

    4 管理有限支持

    那有的内容重要涉嫌到几个种类表格,有一点类似于 SQL SE牧马人VEWrangler中的DMV视图,详见下表。

    id table_schema table_name type description
    1 performance_schema replication_group_members 重要,常用 查看GROUP成员。
    2 performance_schema replication_group_member_stats 重要,常用 当前SERVER在GROUP中的同步情况,查看applier通道的同步情况。
    3 performance_schema replication_connection_stats 重要,常用 当前server中各个通道的使用情况,applier通道是一定有显示,recovery通道看是否使用过,如果有则显示,没有则不显示。
    4 performance_schema replication_applier_stats 重要,常用 当前server中各个通道是否启用。
    5 performance_schema global_status 重要,常用 单主模式下,可以查看当前主库是哪个。
    6 performance_schema replication_applier_configuration 不常用,了解即可  
    7 performance_schema replication_applier_status_by_coordinator 不常用,了解即可  
    8 performance_schema replication_applier_status_by_worker 不常用,了解即可  
    9 performance_schema replication_connection_configuration 不常用,了解即可  
    10 mysql slave_master_info 重要,不常用 设置了master_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。
    11 mysql slave_relay_log_info 重要,不常用 设置了relay_log_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。

     

                  A:

    3.2.3 关闭 group_replication_single_primary_mode参数

        供给修改2个地点,第四个是动态修改参数,第一个是到布置文件中期维修改参数(幸免DB服务重启,参数失效)!

    #动态修改
    #实例A
    set global group_replication_single_primary_mode =OFF
    
    #实例B
    set global group_replication_single_primary_mode =OFF
    
    #实例C
    set global group_replication_single_primary_mode =OFF
    
    
    #配置文件添加
    #实例A的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例B的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例C的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    

     

    为了参考有作业在实例A上操作,在实例A上创制表格 tb4,并导入tb2的持有数据

     

    #实例A
    mysql> create table tb4 like tb2;
    Query OK, 0 rows affected (0.18 sec)
    
    mysql> insert into tb4 select * from tb2;
    Query OK, 20480 rows affected (33.13 sec)
    Records: 20480  Duplicates: 0  Warnings: 0
    

    3.2.3 关闭 group_replication_single_primary_mode参数

        须要修改2个地方,第贰个是动态修改参数,首个是到计划文件中期维修改参数(防止DB服务重启,参数失效)!

    #动态修改
    #实例A
    set global group_replication_single_primary_mode =OFF
    
    #实例B
    set global group_replication_single_primary_mode =OFF
    
    #实例C
    set global group_replication_single_primary_mode =OFF
    
    
    #配置文件添加
    #实例A的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例B的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    
    #实例C的cnf文件中修改
    loose-group_replication_single_primary_mode = OFF
    

     

    为了参考有作业在实例A上操作,在实例A上创设表格 tb4,并导入tb2的持有数据

     

    #实例A
    mysql> create table tb4 like tb2;
    Query OK, 0 rows affected (0.18 sec)
    
    mysql> insert into tb4 select * from tb2;
    Query OK, 20480 rows affected (33.13 sec)
    Records: 20480  Duplicates: 0  Warnings: 0
    

    4.1 查看GROUP中的成员有怎么着

    SELECT * FROM performance_schema.replication_group_members

                  mysql> flush tables with read lock;

    3.2.4 每一种运维GROUP内的SE奥迪Q7VELacrosse

        首先针对实例A运营,然后运营实例B,紧接着运维实例C。这么些进度中,每加入二个组成员,记得去看error log是不是有报错。

    当A运行的时候,能够见见成了一个新的GROUP,B参加到时候,须要经过 group_replication_recovery 通道苏醒数据,C出席到时候,也必要经过 group_replication_recovery 通道恢复生机数据,这部分的剧情跟 3.1. 5 配置Group 中的errorlog内容差不离,这里就不做截图剖判。

     

    #实例A
    #需要启动 group_replication_bootstrap_group 引导组,启动后需要关闭,防止脑裂
    mysql> set global group_replication_bootstrap_group=ON;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.02 sec)
    
    mysql> START GROUP_REPLICATION;
    Query OK, 0 rows affected (1.16 sec)
    
    mysql> set global group_replication_bootstrap_group=Off;
    Query OK, 0 rows affected (0.00 sec)
    
    #实例B
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.04 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (4.31 sec)
    
    #实例C
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.07 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (3.83 sec)
    

    3.2.4 每种运维GROUP内的SE大切诺基VEHaval

        首先针对实例A运维,然后运转实例B,紧接着运转实例C。这几个进度中,每出席贰个组成员,记得去看error log是或不是有报错。

    当A运营的时候,能够见见成了三个新的GROUP,B参与到时候,须要通过 group_replication_recovery 通道苏醒数据,C参加到时候,也须要经过 group_replication_recovery 通道复苏数据,这有个别的剧情跟 3.1. 5 配置Group 中的errorlog内容差不离,这里就不做截图解析。

     

    #实例A
    #需要启动 group_replication_bootstrap_group 引导组,启动后需要关闭,防止脑裂
    mysql> set global group_replication_bootstrap_group=ON;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.02 sec)
    
    mysql> START GROUP_REPLICATION;
    Query OK, 0 rows affected (1.16 sec)
    
    mysql> set global group_replication_bootstrap_group=Off;
    Query OK, 0 rows affected (0.00 sec)
    
    #实例B
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.04 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (4.31 sec)
    
    #实例C
    mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    Query OK, 0 rows affected, 2 warnings (0.07 sec)
    
    mysql> start group_replication;
    Query OK, 0 rows affected (3.83 sec)
    

    4.2 单主情势下主库是哪些

    SELECT * FROM performance_schema.replication_group_members; SELECT * FROM performance_schema. global_status; 五个查询出来的UUID一致的为 主库。 新葡亰496net 64

                  mysql> show master statusG

    3.2.5 检查以往GROUP情状

    时下GROUP中的各类成员都关门了super_read_only选项,提供了读写服务,由于三个都为主库,属于多主情形,所以 global_status中不可能查看到主库是哪些,因为这么些GROUP中,每一种SEKugaVE奥迪Q5都以MASTE奥迪Q5。

     

    mysql> select * from performance_schema.replication_group_members;
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | group_replication_applier | 2ec0fecd-16a2-11e7-97e1-52540005b8e1 | sutest244   |        3340 | ONLINE       |
    | group_replication_applier | 94e39808-15ed-11e7-a7cf-52540005b8e2 | sutest242   |        3310 | ONLINE       |
    | group_replication_applier | 9b78d231-15ed-11e7-a82a-52540005b8e2 | sutest242   |        3320 | ONLINE       |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    3 rows in set (0.21 sec)
    
    mysql> select * from performance_schema.global_status where variable_name like '%group%';
     ---------------------------------- ---------------- 
    | VARIABLE_NAME                    | VARIABLE_VALUE |
     ---------------------------------- ---------------- 
    | group_replication_primary_member |                |
     ---------------------------------- ---------------- 
    1 row in set (0.35 sec)
    
    mysql> show global variables like 'group_replication_single_primary_mode';
     --------------------------------------- ------- 
    | Variable_name                         | Value |
     --------------------------------------- ------- 
    | group_replication_single_primary_mode | OFF   |
     --------------------------------------- ------- 
    1 row in set (0.33 sec)
    
    mysql> show global variables like 'super%';
     ----------------- ------- 
    | Variable_name   | Value |
     ----------------- ------- 
    | super_read_only | OFF   |
     ----------------- ------- 
    1 row in set (1.20 sec)
    

    至此,多主形式已搭建实现,实例A、B、C均可提供读写。PS: 这里要求小心争辩管理机制,能够查看第五有的的故障模拟。

     新葡亰496net 65

    3.2.5 检查今后GROUP景况

    现阶段GROUP中的各类成员都关闭了super_read_only选项,提供了读写服务,由于两个都为主库,属于多主意况,所以 global_status中不能查看到主库是哪位,因为这几个GROUP中,每一种SE奥迪Q3VEXC60都以MASTE宝马X3。

     

    mysql> select * from performance_schema.replication_group_members;
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    | group_replication_applier | 2ec0fecd-16a2-11e7-97e1-52540005b8e1 | sutest244   |        3340 | ONLINE       |
    | group_replication_applier | 94e39808-15ed-11e7-a7cf-52540005b8e2 | sutest242   |        3310 | ONLINE       |
    | group_replication_applier | 9b78d231-15ed-11e7-a82a-52540005b8e2 | sutest242   |        3320 | ONLINE       |
     --------------------------- -------------------------------------- ------------- ------------- -------------- 
    3 rows in set (0.21 sec)
    
    mysql> select * from performance_schema.global_status where variable_name like '%group%';
     ---------------------------------- ---------------- 
    | VARIABLE_NAME                    | VARIABLE_VALUE |
     ---------------------------------- ---------------- 
    | group_replication_primary_member |                |
     ---------------------------------- ---------------- 
    1 row in set (0.35 sec)
    
    mysql> show global variables like 'group_replication_single_primary_mode';
     --------------------------------------- ------- 
    | Variable_name                         | Value |
     --------------------------------------- ------- 
    | group_replication_single_primary_mode | OFF   |
     --------------------------------------- ------- 
    1 row in set (0.33 sec)
    
    mysql> show global variables like 'super%';
     ----------------- ------- 
    | Variable_name   | Value |
     ----------------- ------- 
    | super_read_only | OFF   |
     ----------------- ------- 
    1 row in set (1.20 sec)
    

    迄今,多主格局已搭建达成,实例A、B、C均可提供读写。PS: 这里需求小心争执处理体制,能够查阅第五有的的故障模拟。

     新葡亰496net 66

    4.3 检查数据库是不是健康提供读写服务 

    show global variables like 'super%'; SELECT * FROM performance_schema.replication_group_members;   如果super_read_only是开发银行的,那么该成员仅提供读服务; 借使super_read_only是关闭的,何况 replication_group_members 中符合规律的分子n 满意 2n 1 > 整个GROUP成员个数,何况该成员的 member state是online,则该成员可提供读写服务。  

    *************************** 1. row ***************************

    4 管理爱抚

    那有些剧情首要涉及到多少个系统表格,有一点类似于 SQL SE奥迪Q5VEWrangler中的DMV视图,详见下表。

    id table_schema table_name type description
    1 performance_schema replication_group_members 重要,常用 查看GROUP成员。
    2 performance_schema replication_group_member_stats 重要,常用 当前SERVER在GROUP中的同步情况,查看applier通道的同步情况。
    3 performance_schema replication_connection_stats 重要,常用 当前server中各个通道的使用情况,applier通道是一定有显示,recovery通道看是否使用过,如果有则显示,没有则不显示。
    4 performance_schema replication_applier_stats 重要,常用 当前server中各个通道是否启用。
    5 performance_schema global_status 重要,常用 单主模式下,可以查看当前主库是哪个。
    6 performance_schema replication_applier_configuration 不常用,了解即可  
    7 performance_schema replication_applier_status_by_coordinator 不常用,了解即可  
    8 performance_schema replication_applier_status_by_worker 不常用,了解即可  
    9 performance_schema replication_connection_configuration 不常用,了解即可  
    10 mysql slave_master_info 重要,不常用 设置了master_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。
    11 mysql slave_relay_log_info 重要,不常用 设置了relay_log_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。

     

    4 管理有限支撑

    那部分内容重要涉及到多少个体系表格,有一点点类似于 SQL SEWranglerVE凯雷德中的DMV视图,详见下表。

    id table_schema table_name type description
    1 performance_schema replication_group_members 重要,常用 查看GROUP成员。
    2 performance_schema replication_group_member_stats 重要,常用 当前SERVER在GROUP中的同步情况,查看applier通道的同步情况。
    3 performance_schema replication_connection_stats 重要,常用 当前server中各个通道的使用情况,applier通道是一定有显示,recovery通道看是否使用过,如果有则显示,没有则不显示。
    4 performance_schema replication_applier_stats 重要,常用 当前server中各个通道是否启用。
    5 performance_schema global_status 重要,常用 单主模式下,可以查看当前主库是哪个。
    6 performance_schema replication_applier_configuration 不常用,了解即可  
    7 performance_schema replication_applier_status_by_coordinator 不常用,了解即可  
    8 performance_schema replication_applier_status_by_worker 不常用,了解即可  
    9 performance_schema replication_connection_configuration 不常用,了解即可  
    10 mysql slave_master_info 重要,不常用 设置了master_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。
    11 mysql slave_relay_log_info 重要,不常用 设置了relay_log_info_repository=TABLE,所以master的相关信息会存储在这个表格。
    如果使用GROUP中的SERVER备份数据库,恢复到时候,注意要清理这个表格。

     

    4.4 检查数据库是还是不是复制出现难题

    可以透过表格replication_group_members ,replication_group_member_stats ,replication_connection_stats ,replication_applier_stats 查看 注重注意各类 组成员的 E大切诺基RO奇骏LOG详细消息,因为报错描述最清楚都在此地了。

                File: mysql-bin.000028

    4.1 查看GROUP中的成员有怎么着

    SELECT * FROM performance_schema.replication_group_members

    4.1 查看GROUP中的成员有何

    SELECT * FROM performance_schema.replication_group_members

    5 故障模拟及管理

    节选测量试验进度的图,跟在此以前安顿的GROUP有个别不雷同,了解尊重思路就可以,部分测量检验细节尚未再度描述。

                Position: 866

    4.2 单主情势下主库是哪位

    SELECT * FROM performance_schema.replication_group_members;

    SELECT * FROM performance_schema. global_status;

    五个查询出来的UUID一致的为 主库。

    新葡亰496net 67

    4.2 单主格局下主库是哪个

    SELECT * FROM performance_schema.replication_group_members;

    SELECT * FROM performance_schema. global_status;

    五个查询出来的UUID一致的为 主库。

    新葡亰496net 68

    5.1 单主方式

                       Binlog_Do_DB: test

    4.3 检查数据库是还是不是平常提供读写服务 

    show global variables like 'super%';

    SELECT * FROM performance_schema.replication_group_members;

     

    如果super_read_only是运营的,那么该成员仅提供读服务;

    如果super_read_only是关门的,何况 replication_group_members 中健康的成员n 满足 2n 1 > 整个GROUP成员个数,而且该成员的 member state是online,则该成员可提供读写服务。

     

    4.3 检查数据库是否正规提供读写服务 

    show global variables like 'super%';

    SELECT * FROM performance_schema.replication_group_members;

     

    如果super_read_only是开发银行的,那么该成员仅提供读服务;

    如果super_read_only是关闭的,何况 replication_group_members 中符合规律的分子n 满意 2n 1 > 整个GROUP成员个数,并且该成员的 member state是online,则该成员可提供读写服务。

     

    5.1.1 主库宕机,如何自动选取新主库?各类实例之间的super_read_only形式如何切换?

    select * from performance_schema.replication_group_members;
    select * from performance_schema.global_status where VARIABLE_NAME='group_replication_primary_member';
    show global variables like 'server_uuid';
    show global variables like 'super%';
    
    select * from performance_schema.replication_connection_status;
    select * from performance_schema.replication_applier_status;
    

     新葡亰496net 69

     

    新葡亰496net 70

    新葡亰496net 71

    新葡亰496net 72

    新葡亰496net 73

         模拟group中,有四个实例,端口分别为 3320,3330,3340,用简称来 m3320、m3330、m3340来分不要叙述。

        m3330在属于主库,模拟其主库宕机,使用 kill 进程格局,当m3330宕机后,m3320及m3340检查到 timeout reading,则会从group_member中除去该实例,同一时等候检查验宕机实例是还是不是低于 floor((n-1)/2) (n为group中持有实例个数),借使知足,则运转新的GROUP,依据GROUP中逐条实例的UUID举行升序排序,选取第二个作为新的主库,由于新主库以前是super_read_only状态,仅援助只读,晋级为新主库后,会实行 ,不设置 super_read_only,关闭此参数,那么新主库则是可提供读写服务,原先的从库今后依然为从库,super_read_only照旧为运转状态,仅提供读服务。

    Binlog_Ignore_DB: mysql

    4.4 检查数据库是或不是复制出现难点

    能够透过表格replication_group_members ,replication_group_member_stats ,replication_connection_stats ,replication_applier_stats 查看

    重要注意种种 组成员的 E悍马H2RORAV4 LOG详细音信,因为报错描述最清楚都在此间了。

    4.4 检查数据库是不是复制出现难题

    能够由此表格replication_group_members ,replication_group_member_stats ,replication_connection_stats ,replication_applier_stats 查看

    一言九鼎注意种种 组成员的 ESportageRO大切诺基 LOG详细音信,因为报错描述最理解都在那边了。

    5.1.2 主库宕机后,恢复生机,重新参预group

        旧主库复苏后,检查GROUP_REPLICATION相关参数,是或不是设置有误,它须求以三个从库的情势插足,详见 GROUP配置的参数表明。 如若参数精确,实行change master,然后start 就能够。  

    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    新葡亰496net 74     其余多少个节点检查再三再四情状,连接准确后,加入group中,更新 GROUP Member,相同的时候开班联手差别binlog日志内容。

    1 row in set (0.00 sec)

    5 故障模拟及管理

    节选测量试验进度的图,跟从前布署的GROUP有些不平等,明白尊重思路就能够,部分测量试验细节尚未重新描述。

    5 故障模拟及管理

    节选测量试验进程的图,跟此前安顿的GROUP有些分歧等,领悟尊重思路即可,部分测验细节尚未再一次描述。

    5.1.3 从库宕机1台,影响事态

        kill 3330进程,模拟从库宕机,开采剩下实例检查实验到 m3330十分,从 group中剔除,主库m3320照常提供读写服务,从库m3340照常提供读服务。 新葡亰496net 75

    新葡亰496net 76

             mysql> unlock tables;

    5.1 单主情势

    5.1 单主方式

    5.1.4 从库宕机2台,影响事态

        基于3的基本功上,再度kill 3340经过,模拟从库宕机,主库3320检查到 m3340可怜,然而并未有去除该 成员,而是正是为 unreachable,注明该成员恐怕由于崩溃大概意想不到被断开而招致的不得访谈。 新葡亰496net 77     或然(七个从库宕机的每一天非常左近,则不如推断剔除出group)  新葡亰496net 78     对仅存活动 m3320 施行查询操作,是健康状态。不过DDL及DML 操作,均处于等候情形,并且,error log也无报错景况。  新葡亰496net 79

    新葡亰496net 80

        那个时候,假若想要苏醒主库读写服务,需终止group(这里有个难点,查看replication_applier_status,主库状态符合规律;但是不提供读写应该从哪些地方判定呢,难道是group_member的不奇怪个数不满足group的健康个数须要,则不提供服务?除了stop group_relication和新投入节点外,还或者有另外格局管理啊?**)**  新葡亰496net 81

    新葡亰496net 82

    新葡亰496net 83

                  mysql> stop slave;

    5.1.1 主库宕机,如何自动采纳新主库?种种实例之间的super_read_only情势怎么着切换?

    select * from performance_schema.replication_group_members;
    select * from performance_schema.global_status where VARIABLE_NAME='group_replication_primary_member';
    show global variables like 'server_uuid';
    show global variables like 'super%';
    
    select * from performance_schema.replication_connection_status;
    select * from performance_schema.replication_applier_status;
    

     新葡亰496net 84

     

    新葡亰496net 85

    新葡亰496net 86

    新葡亰496net 87

    新葡亰496net 88

         模拟group中,有四个实例,端口分别为 3320,3330,3340,用简称来 m3320、m3330、m3340来分别呈报。

        m3330在属于主库,模拟其主库宕机,使用 kill 进度形式,当m3330宕机后,m3320及m3340检查到 timeout reading,则会从group_member中删除该实例,同期检查测验宕机实例是或不是低于 floor((n-1)/2) (n为group中具备实例个数),就算满意,则运转新的GROUP,遵照GROUP中逐个实例的UUID进行升序排序,选用第两个作为新的主库,由于新主库在此以前是super_read_only状态,仅支持只读,进级为新主库后,会施行 ,不设置 super_read_only,关闭此参数,那么新主库则是可提供读写服务,原先的从库以后照旧为从库,super_read_only照旧为运转状态,仅提供读服务。

    5.1.1 主库宕机,怎么样自动选择新主库?各类实例之间的super_read_only情势怎么着切换?

    select * from performance_schema.replication_group_members;
    select * from performance_schema.global_status where VARIABLE_NAME='group_replication_primary_member';
    show global variables like 'server_uuid';
    show global variables like 'super%';
    
    select * from performance_schema.replication_connection_status;
    select * from performance_schema.replication_applier_status;
    

     新葡亰496net 89

     

    新葡亰496net 90

    新葡亰496net 91

    新葡亰496net 92

    新葡亰496net 93

         模拟group中,有五个实例,端口分别为 3320,3330,3340,用简称来 m3320、m3330、m3340来分不要叙述。

        m3330在属于主库,模拟其主库宕机,使用 kill 进度格局,当m3330宕机后,m3320及m3340检查到 timeout reading,则会从group_member中去除该实例,同期检查评定宕机实例是或不是低于 floor((n-1)/2) (n为group中兼有实例个数),假使满足,则运转新的GROUP,遵照GROUP中逐一实例的UUID举行升序排序,采纳首个作为新的主库,由于新主库以前是super_read_only状态,仅支持只读,升级为新主库后,会试行 ,不安装 super_read_only,关闭此参数,那么新主库则是可提供读写服务,原先的从库未来依然为从库,super_read_only照旧为运转状态,仅提供读服务。

    5.1.5 新增从库:innobackupex新增加(那一个须求专注)

        选拔在 m3320备份实例,备份甘休后apply log。

    1 innobackupex --datadir=/data/mysql/mysql3320/data/ --user=root --password=ycf.com --no-timestamp --socket=/tmp/mysql3320.sock /data/backup3320
    2 innobackupex --apply-log /data/backup3320
    

        第一遍运维数据库时,报错,找不到relay log文件,因为拷贝过来的时候 ,备份库钦赐参数如下,mysql库中的master_relay_log_info钦定了relay log的连带音讯,可是以后尚无找到文件,数据库会自行创立applier跟recovery种类文件。 master_info_repository=TABLE relay_log_info_repository=TABLE       所以须求步入数据库中,truncate 七个表格:mysql.slave_master_info, mysql.slave_relay_log_info ,然后删除 applier跟recovery类别文件 。

    1 truncate table mysql.slave_master_info
    2 truncate table mysql.slave_relay_log_info
    3  
    4 rm -rf applier系列文件
    5 rm -rf recovery系列文件
    

    查阅下备份的GTID集合,如下  新葡亰496net 94 重启数据库服务,步向数据库,重新配置GTID集结与备份中的一致,运维GROUP_REPLICATION。

    RESET MASTER;
    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-10';
    
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    mysql> change master to master_host='192.168.1.110',master_user='replication',master_password='123456',master_log_file='mysql-bin.000014', master_log_pos=704;

    5.1.2 主库宕机后,苏醒,重新插手group

        旧主库恢复生机后,检查GROUP_REPLICATION相关参数,是还是不是设置有误,它须要以一个从库的艺术参与,详见 GROUP配置的参数表明。

    若是参数准确,实行change master,然后start 就能够。

     

    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    新葡亰496net 95

        其余三个节点检查接二连三情状,连接精确后,参加group中,更新 GROUP Member,同不时常间开班共同差距binlog日志内容。

    5.1.2 主库宕机后,复苏,重新插足group

        旧主库复苏后,检查GROUP_REPLICATION相关参数,是还是不是设置有误,它供给以叁个从库的主意加盟,详见 GROUP配置的参数表达。

    比如参数精确,试行change master,然后start 就能够。

     

    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    新葡亰496net 96

        别的七个节点检查延续境况,连接精确后,到场group中,更新 GROUP Member,同一时间开班联手差别binlog日志内容。

    5.1.6 新添从库:mysqldump新添(那么些需求专注)

    备份数据库实例: /usr/local/mysql5717/bin/mysqldump --socket=/tmp/mysql3320.sock -uroot -p --all-databases > ~/mysql3320.sql  新葡亰496net 97     这里有个小TIPS,个人提出,建设构造叁个新的实例后,在新实例中装置 好 group_replication 引擎,不要等到source后再安装,那样的收益是:防止直接在平复的数据库实例上安装引擎,会并发各类错误。       在服务器上先安装 group_replication引擎,然后再source数据,防止source数据后由于条件问题形成group_replication引擎安装分外INSTALL PLUGIN group_replication SONAME 'group_replication.so';       成功后source /data/mysql3320.sql     检查当前的binlog跟gtid使用状态,show master status;     由于方今的利用意况跟mysqldump中的 gtid_purge不同,重新拷贝下mysql3320.sql中的 gtid_purged语句,注意,即便当前的gtid_excuted不为空,则需求重新载入参数下master相关消息,reset master后实行gtid_purge语句。  新葡亰496net 98

    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-18'; #看GTID集合是否一致
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

                  mysql> start slave;

    5.1.3 从库宕机1台,影响事态

        kill 3330进度,模拟从库宕机,开掘剩下实例检查实验到 m3330万分,从 group中删去,主库m3320照常提供读写服务,从库m3340照常提供读服务。

    新葡亰496net 99

    新葡亰496net 100

    5.1.3 从库宕机1台,影响事态

        kill 3330经过,模拟从库宕机,开采剩下实例检验到 m3330不行,从 group中除去,主库m3320照常提供读写服务,从库m3340照常提供读服务。

    新葡亰496net 101

    新葡亰496net 102

    5.2 多主形式

                 

    5.1.4 从库宕机2台,影响事态

        基于3的功底上,再一次kill 3340进度,模拟从库宕机,主库3320检查到 m3340丰裕,然则并未有去除该 成员,而是便是为 unreachable,注解该成员只怕由于崩溃恐怕意料之外被断开而招致的不得访谈。

    新葡亰496net 103

        可能(多个从库宕机的随时非常临近,则不如判别剔除出group)

     新葡亰496net 104

        对仅存活动 m3320 施行查询操作,是健康情况。然则DDL及DML 操作,均处在等候状态,何况,error log也无报错处境。

     新葡亰496net 105

    新葡亰496net 106

        那个时候,即便想要恢复生机主库读写服务,需终止group(这里有个疑问,查看replication_applier_status,主库状态符合规律;但是不提供读写应该从哪个地点推断呢,难道是group_member的健康个数不满足group的正规个数要求,则不提供劳务?除了stop group_relication和新投入节点外,还应该有别的格局处理呢?**)**

     新葡亰496net 107

    新葡亰496net 108

    新葡亰496net 109

    5.1.4 从库宕机2台,影响事态

        基于3的底蕴上,再度kill 3340历程,模拟从库宕机,主库3320检查到 m3340非常,但是未有去除该 成员,而是正是为 unreachable,申明该成员恐怕出于崩溃也许意想不到被断开而致使的不足访问。

    新葡亰496net 110

        大概(四个从库宕机的时刻非常周围,则比不上推断剔除出group)

     新葡亰496net 111

        对仅存活动 m3320 推行查询操作,是例市场价格况。不过DDL及DML 操作,均处于等候状态,并且,error log也无报错景况。

     新葡亰496net 112

    新葡亰496net 113

        那年,假诺想要恢复生机主库读写服务,需终止group(这里有个难点,查看replication_applier_status,主库状态平常;可是不提供读写应该从哪个地点剖断呢,难道是group_member的常规个数不满足group的常规个数须求,则不提供服务?除了stop group_relication和新参预节点外,还会有其余办法管理啊?**)**

     新葡亰496net 114

    新葡亰496net 115

    新葡亰496net 116

    5.2.1 单主形式切换多主形式

    这一部分参谋第三有的的第3节,多主情势。 简要步骤: 1 先由 从主库初阶,逐条逐条结束group replication 2 安装group_replication_single_primary_mode 关闭 3 依次运维GROUP replication   测量试验内容: 1 整个GROUP中每种SE奥迪Q5VERAV4同一时候实践一个DML语句 2 整个GROUP中种种SESportageVE帕杰罗同一时候实行贰个DDL语句   测量检验结论:     严重注意,如若在同期提交DDL语句,则在种种实例都以可以付出成功,可是共同到各类实例的时候会生出报错,group_replication出现error错误,所有实例运转super_read_only只读情形,整个group不提供 写操作,须要人工接入修复。所以DDL语句,建议在规划的时候,就特意独有二个实例能够实践DDL语句,人为暗许在某一台上实践DDL语句,并非每台都推行,防止不需求的争辨。

                  B:

    5.1.5 新扩张从库:innobackupex新添(这些要求专注)

        接纳在 m3320备份实例,备份停止后apply log。

    1 innobackupex --datadir=/data/mysql/mysql3320/data/ --user=root --password=ycf.com --no-timestamp --socket=/tmp/mysql3320.sock /data/backup3320
    2 innobackupex --apply-log /data/backup3320
    

        第贰回运转数据库时,报错,找不到relay log文件,因为拷贝过来的时候 ,备份库钦命参数如下,mysql库中的master_relay_log_info钦命了relay log的相干音信,不过未来未曾找到文件,数据库会活动创建applier跟recovery系列文件。

    master_info_repository=TABLE

    relay_log_info_repository=TABLE

     

        所以要求步入数据库中,truncate 八个表格:mysql.slave_master_info, mysql.slave_relay_log_info ,然后删除 applier跟recovery类别文件 。

    1 truncate table mysql.slave_master_info
    2 truncate table mysql.slave_relay_log_info
    3  
    4 rm -rf applier系列文件
    5 rm -rf recovery系列文件
    

    查看下备份的GTID会集,如下

     新葡亰496net 117

    重启数据库服务,步向数据库,重新配置GTID群集与备份中的一致,运营GROUP_REPLICATION。

    RESET MASTER;
    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-10';
    
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    5.1.5 增加产量从库:innobackupex新增添(这些供给注意)

        采用在 m3320备份实例,备份甘休后apply log。

    1 innobackupex --datadir=/data/mysql/mysql3320/data/ --user=root --password=ycf.com --no-timestamp --socket=/tmp/mysql3320.sock /data/backup3320
    2 innobackupex --apply-log /data/backup3320
    

        第一回开发银行数据库时,报错,找不到relay log文件,因为拷贝过来的时候 ,备份库钦命参数如下,mysql库中的master_relay_log_info钦赐了relay log的连锁新闻,可是现在平素不找到文件,数据库会自行创建applier跟recovery连串文件。

    master_info_repository=TABLE

    relay_log_info_repository=TABLE

     

        所以要求步向数据库中,truncate 八个表格:mysql.slave_master_info, mysql.slave_relay_log_info ,然后删除 applier跟recovery体系文件 。

    1 truncate table mysql.slave_master_info
    2 truncate table mysql.slave_relay_log_info
    3  
    4 rm -rf applier系列文件
    5 rm -rf recovery系列文件
    

    查看下备份的GTID集结,如下

     新葡亰496net 118

    重启数据库服务,走入数据库,重新配置GTID集结与备份中的一致,运营GROUP_REPLICATION。

    RESET MASTER;
    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-10';
    
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    5.2.2 宕机一台全体影响

    kill 进度,其他实例检车链接有标题后,剔除该节点,正常操作。 新葡亰496net 119

                  mysql> flush tables with read lock;

    5.1.6 增加产量从库:mysqldump新添(这么些要求小心)

    备份数据库实例:

    /usr/local/mysql5717/bin/mysqldump --socket=/tmp/mysql3320.sock -uroot -p --all-databases > ~/mysql3320.sql

     新葡亰496net 120

        这里有个小TIPS,个人提议,创立一个新的实例后,在新实例中设置 好 group_replication 引擎,不要等到source后再设置,那样的益处是:防止直接在恢复生机的数据库实例上设置引擎,会现出各个不当。

     

        在服务器上先安装 group_replication引擎,然后再source数据,幸免source数据后由于条件难题导致group_replication引擎安装有标题

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';

     

        成功后source /data/mysql3320.sql

        检查当前的binlog跟gtid使用状态,show master status;

        由于当下的选拔情形跟mysqldump中的 gtid_purge分歧,重新拷贝下mysql3320.sql中的 gtid_purged语句,注意,要是当前的gtid_excuted不为空,则供给重新设置下master相关音信,reset master后施行gtid_purge语句。

     新葡亰496net 121

    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-18'; #看GTID集合是否一致
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    5.1.6 新添从库:mysqldump新扩大(那么些要求专注)

    备份数据库实例:

    /usr/local/mysql5717/bin/mysqldump --socket=/tmp/mysql3320.sock -uroot -p --all-databases > ~/mysql3320.sql

     新葡亰496net 122

        这里有个小TIPS,个人提出,创建一个新的实例后,在新实例中安装 好 group_replication 引擎,不要等到source后再安装,那样的收益是:幸免直接在还原的数据库实例上安装引擎,会并发种种不当。

     

        在服务器上先安装 group_replication引擎,然后再source数据,幸免source数据后由于条件难题变成group_replication引擎安装有毛病

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';

     

        成功后source /data/mysql3320.sql

        检查当前的binlog跟gtid使用处境,show master status;

        由于前段时间的运用情状跟mysqldump中的 gtid_purge分歧,重新拷贝下mysql3320.sql中的 gtid_purged语句,注意,借使当前的gtid_excuted不为空,则须要重新初始化下master相关音讯,reset master后实践gtid_purge语句。

     新葡亰496net 123

    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-18'; #看GTID集合是否一致
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

    5.2.3 宕机后重新出席

    早先数据库实例后,记得检查 group_replication_single_primary_mode是不是是关闭状态,借使不是,注意运维,要不然会出于方式区别等报错, set global group_replication_single_primary_mode=OFF;   平常施行  CHANGE MASTETiguan TO MASTE凯雷德_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;

                  mysql> show master statusG

    5.2 多主情势

    5.2 多主格局

    5.2.4 宕机超越合理个数,全部影响(非三个个渐渐宕机,而是一口气宕机超越合理个数)

        5台server端,一口气停机了3台,则3台的status修改为UNREACHABLE,剩下的2台为ONLINE,即便super_read_only是关门的意况,但是这两台server不提供写成效,仅提供读功效。     这里注意下,倘使这一年,发生DML操作,则会挂起该操作,一贯处于等候情形,别的链接能够健康连接数据库进行操作;不过假若发生DDL操作,那年,不仅仅该会话处于等候意况,何况别的新的总是将不能够奉行user dbname(涉及操作的DBname)步向到该数据库中开展任何查询操作,不过足以在其余数据库上 使用 dbname.tbname 格局查询,譬如select * from dbgroup.alld!       仅剩下的一台主库居然不提供读写,除非关闭stop group_replication!       关闭后,error log中会提醒事务回滚音信。  

    *************************** 1. row ***************************

    5.2.1 单主方式切换多主形式

    那有的参照他事他说加以考察第三有个别的第2节,多主情势。

    简言之步骤:

    1 先由 从主库起初,逐个逐条结束group replication

    2 设置group_replication_single_primary_mode 关闭

    3 依次运营GROUP replication

     

    测量检验内容:

    1 整个GROUP中各类SE宝马X3VE奥迪Q7同期执行二个DML语句

    2 整个GROUP中每一种SE劲客VEGL450同期实行一个DDL语句

     

    测验结论:

        严重注意,假如在相同的时候提交DDL语句,则在每种实例都以能够提交成功,可是共同到各样实例的时候会时有产生报错,group_replication出现error错误,全部实例运营super_read_only只读景况,整个group不提供 写操作,要求人工接入修复。所以DDL语句,建议在设计的时候,就特意唯有三个实例能够进行DDL语句,人为暗许在某一台上实行DDL语句,实际不是每台都实践,防止不供给的顶牛。

    5.2.1 单主情势切换多主形式

    那部分参谋第4局地的第四节,多主方式。

    简短步骤:

    1 先由 从主库开端,逐个逐个停止group replication

    2 设置group_replication_single_primary_mode 关闭

    3 依次运营GROUP replication

     

    测量检验内容:

    1 整个GROUP中各样SE途睿欧VE大切诺基同一时候实行三个DML语句

    2 整个GROUP中各类SEPAJEROVE哈弗同期实行二个DDL语句

     

    测量检验结论:

        严重注意,假如在同反常间提交DDL语句,则在各样实例都以能够付出成功,可是共同到各样实例的时候会发出报错,group_replication出现error错误,全部实例运营super_read_only只读情状,整个group不提供 写操作,须要人工接入修复。所以DDL语句,提出在筹算的时候,就特别唯有二个实例能够推行DDL语句,人为暗中同意在某一台上施行DDL语句,而不是每台都施行,防止不供给的争执。

    5.2.5 新增DB:innobackupex新增

    轻巧易行步骤

    #部分参考SQL
    SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-26:1000004';
    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';
    START GROUP_REPLICATION;
    

                File: mysql-bin.000014

    5.2.2 宕机一台全体影响

    kill 进程,其余实例检车链接有标题后,剔除该节点,不荒谬操作。 新葡亰496net 124

    5.2.2 宕机一台全部影响

    kill 进程,其余实例检车链接有标题后,剔除该节点,平常操作。 新葡亰496net 125

    5.2.6 新增DB:mysqldump新增

    轻松步骤

                Position: 704

    5.2.3 宕机后重新插手

    启航数据库实例后,记得检查 group_replication_single_primary_mode是还是不是是关闭状态,借使不是,注意运维,要不然会由于情势不一致报错,

    set global group_replication_single_primary_mode=OFF;

     

    寻常执行 

    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';

    START GROUP_REPLICATION;

    5.2.3 宕机后重新参与

    启航数据库实例后,记得检查 group_replication_single_primary_mode是还是不是是关闭状态,假设不是,注意运行,要否则会由于情势分化样报错,

    set global group_replication_single_primary_mode=OFF;

     

    好端端施行 

    CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery';

    START GROUP_REPLICATION;

    6 主题材料记录

    1 ip间隔是 逗号

    2 不要有分店,本身就像此笨的开端!

    3 port是运用端口号 ,非实例端口号

    4 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16

    新葡亰496net 126

     [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16,9ac06b4e-13aa-11e7-a62e-5254004347f9:1'

     [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

    [Note] Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'

    • 解决
      • set global group_replication_allow_local_disjoint_gtids_join=ON;(但是实际上这种方法治标不治本)
      • 建议依然在搭建group_replication的时候,在start group_replication以前,reset master,复位全体binary log,这样就不会出现各种实例之间的日记超前影响;然而此地要想念是还是不是影响到旧主从。

    5 [ERROR] Plugin group_replication reported: 'Table te does not have any PRIMARY KEY. This is not compatible with Group Replication'

    报表需求加上主键

    6 mysql> insert into ct(id,name) select 2,'b'; ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement 

    只读情势下,不提供写服务。

    7 [ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication is on ERROR state. Check for errors and restart the plugin'   2017-03-29T15:46:13.619141Z 31 [ERROR] Run function 'before_commit' in plugin 'group_replication' failed 

    GROUP出错了,是否是重复实行争持了,好好处理下

                       Binlog_Do_DB: test

    5.2.4 宕机当先合理个数,全部影响(非三个个逐步宕机,而是一口气宕机超越合理个数)

        5台server端,一口气停机了3台,则3台的status修改为UNREACHABLE,剩下的2台为ONLINE,即使super_read_only是关闭的情况,不过这两台server不提供写功能,仅提供读成效。

        这里注意下,如若那一年,产生DML操作,则会挂起该操作,平昔处在等候情形,别的链接能够平时连接数据库举行操作;不过只要发生DDL操作,那一年,不止该会话处于等候景况,况兼其他新的总是将不能够实践user dbname(涉及操作的DBname)进入到该数据库中张开任何查询操作,可是足以在其余数据库上 使用 dbname.tbname 方式查询,举个例子select * from dbgroup.alld!

     

        仅剩余的一台主库居然不提供读写,除非关闭stop group_replication!

     

        关闭后,error log中会提醒事务回滚音讯。

     

    5.2.4 宕机抢先合理个数,全体影响(非三个个逐步宕机,而是一口气宕机抢先合理个数)

        5台server端,一口气停机了3台,则3台的status修改为UNREACHABLE,剩下的2台为ONLINE,固然super_read_only是倒闭的情景,可是这两台server不提供写成效,仅提供读效能。

        这里注意下,如若那一年,发生DML操作,则会挂起该操作,平昔处于等候情形,其余链接能够健康连接数据库实行操作;可是只要爆发DDL操作,这一年,不唯有该会话处于等候状态,况且其他新的总是将不能实施user dbname(涉及操作的DBname)走入到该数据库中开展任何查询操作,但是可以在别的数据库上 使用 dbname.tbname 格局查询,比方select * from dbgroup.alld!

     

        仅剩下的一台主库居然不提供读写,除非关闭stop group_replication!

     

        关闭后,error log中会提示事务回滚音讯。

     

    7  未缓和难点

    1 能够经过 show slaves status for channel 'group_replication_recovery' 查看recovery通道执生势况,但是怎么看 applier呢?(show slaves status for channel 'group_replication_applier'报错 ) 2 当宕机超过有效个数时,查看replication_applier_status,状态符合规律,不过ONLINE的server实际上不提供写服务,仅提供读服务,能够经过什么措施飞速判断呢?个人感觉是以下判定,是或不是有越来越好的章程?   show global variables like 'super%'; SELECT * FROM performance_schema.replication_group_members; 如果super_read_only是开发银行的,那么该成员仅提供读服务; 假使super_read_only是关门的,而且 replication_group_members 中正常的分子n 餍足 2n 1 > 整个GROUP成员个数,而且该成员的 member state是online,则该成员可提供读写服务。   3 当宕机超越有效个数时,ONLINE的server仅提供读服务,假如供给运维写服务,目前个人测试结果是唯有三种方案苏醒写服务:当前SE昂科威VE福特Explorer,执行stop group_replication;苏醒另外的特别SE奥迪Q3VE卡宴变符合规律。是或不是还会有别的方式?   4 GROUP中删除一个成员,要是N个节点,叁个节点故障,是行使许多投票机制照旧整个毫无二致投票机制?   参照他事他说加以考察文书档案: mysql官方在20151212正规发布了group replication版本,官方网址详细地址: 谢谢京东的汉译: ,某个地方字面直译,有个别倒霉驾驭,借使认为到精通有误,可比较之下看下德文文书档案。 翻译中文文书档案下载地址:  

    Group Replicaiton — 配置维护故障管理全集,replicagroup 本文首要描述MySQL Group Replication的回顾原理、搭建进程以及故障维护管理内...

    Binlog_Ignore_DB: mysql

    5.2.5 新增DB:innobackupex新增

    简单步骤

    1. 备份后实践apply log
    2. 新建实例,增加plugins引擎
    3. 轮换数据目录
    4. 起步数据库
    5. 清理relay-log文件,清理slave_master_info跟slave_relay_log_info信息
    6. 查阅当前的GTID序号是还是不是与 xtrabackup_binlog_info记录一致,假设不均等,试行 set gtid_purged
    7. 重启数据库服务
    8. 自作者批评group replication配置是或不是有误
    9. change master
    10. start group_replication

      #部分参谋SQL SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-26:1000004'; CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;

    5.2.5 新增DB:innobackupex新增

    简言之步骤

    1. 备份后试行apply log
    2. 新建实例,增添plugins引擎
    3. 轮换数据目录
    4. 开发银行数据库
    5. 清理relay-log文件,清理slave_master_info跟slave_relay_log_info信息
    6. 翻看当前的GTID序号是不是与 xtrabackup_binlog_info记录一致,假设分裂,实施 set gtid_purged
    7. 重启数据库服务
    8. 自己评论group replication配置是或不是有误
    9. change master
    10. start group_replication

      #部分参照他事他说加以考察SQL SET @@GLOBAL.GTID_PURGED='9ac06b4e-13aa-11e7-a62e-5254004347f9:1-26:1000004'; CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='replforslave' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;

    1 row in set (0.00 sec)

    5.2.6 新增DB:mysqldump新增

    简单易行步骤

    1. 新建实例,加多plugins引擎
    2. source 备份文件
    3. 清理relay-log文件,清理slave_master_info跟slave_relay_log_info信息
    4. 翻看当前的GTID序号是或不是与备份文件前边记录同一,假如分化样,推行 set gtid_purged
    5. 检查group replication配置是还是不是有误
    6. change master
    7. start group_replication

    5.2.6 新增DB:mysqldump新增

    一句话来讲步骤

    1. 新建实例,增添plugins引擎
    2. source 备份文件
    3. 清理relay-log文件,清理slave_master_info跟slave_relay_log_info信息
    4. 查看当前的GTID序号是否与备份文件前面记录同一,借使差别样,推行 set gtid_purged
    5. 自作者研商group replication配置是还是不是有误
    6. change master
    7. start group_replication

             mysql> unlock tables;

    6 题目记录

    1 ip间隔是 逗号

    2 不要有根据地,本身就这样笨的开头!

    3 port是运用端口号 ,非实例端口号

    4 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16

    新葡亰496net 127

     [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16,9ac06b4e-13aa-11e7-a62e-5254004347f9:1'

     [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

    [Note] Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'

    • 解决
      • set global group_replication_allow_local_disjoint_gtids_join=ON;(不过实际上这种办法治标不治本)
      • 建议还是在搭建group_replication的时候,在start group_replication此前,reset master,重新载入参数全部binary log,那样就不相会世各种实例之间的日记超前影响;可是此地要思量是不是影响到旧主从。

    5 [ERROR] Plugin group_replication reported: 'Table te does not have any PRIMARY KEY. This is not compatible with Group Replication'

    报表要求加上主键

    6 mysql> insert into ct(id,name) select 2,'b'; ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement 

    只读情势下,不提供写服务。

    7 [ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication is on ERROR state. Check for errors and restart the plugin'   2017-03-29T15:46:13.619141Z 31 [ERROR] Run function 'before_commit' in plugin 'group_replication' failed 

    GROUP出错了,是或不是是重复实施争执了,好好管理下

    6 难点记录

    1 ip间隔是 逗号

    2 不要有分店,自个儿就如此笨的启幕!

    3 port是应用端口号 ,非实例端口号

    4 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16

    新葡亰496net 128

     [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 32538cbf-12fc-11e7-af43-5254004347f9:1-5 > Group transactions: 2236bd6b-12fc-11e7-a706-5254004347f9:1-16,9ac06b4e-13aa-11e7-a62e-5254004347f9:1'

     [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

    [Note] Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'

    • 解决
      • set global group_replication_allow_local_disjoint_gtids_join=ON;(可是事实上这种措施治标不治本)
      • 建议依然在搭建group_replication的时候,在start group_replication在此之前,reset master,重新设置全体binary log,那样就不会冒出种种实例之间的日志超前影响;可是此间要思考是或不是影响到旧主从。

    5 [ERROR] Plugin group_replication reported: 'Table te does not have any PRIMARY KEY. This is not compatible with Group Replication'

    报表须要增添主键

    6 mysql> insert into ct(id,name) select 2,'b'; ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement 

    只读格局下,不提供写服务。

    7 [ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication is on ERROR state. Check for errors and restart the plugin'   2017-03-29T15:46:13.619141Z 31 [ERROR] Run function 'before_commit' in plugin 'group_replication' failed 

    GROUP出错了,是或不是是重复实行争持了,好好管理下

                  mysql> stop slave;

    7  未减轻难题

    1 能够通过 show slaves status for channel 'group_replication_recovery' 查看recovery通道执生势况,可是怎么看 applier呢?(show slaves status for channel 'group_replication_applier'报错 )

    2 当宕机超越有效个数时,查看replication_applier_status,状态平常,可是ONLINE的server实际上不提供写服务,仅提供读服务,能够由此什么样格局神速推断呢?个人以为是以下决断,是或不是有更加好的方法?

     

    show global variables like 'super%';

    SELECT * FROM performance_schema.replication_group_members;

    如果super_read_only是开发银行的,那么该成员仅提供读服务;

    如果super_read_only是停业的,並且 replication_group_members 中平常的分子n 满足 2n 1 > 整个GROUP成员个数,并且该成员的 member state是online,则该成员可提供读写服务。

     

    3 当宕机超越有效个数时,ONLINE的server仅提供读服务,假使急需运行写服务,前段时间个人测验结果是独有二种方案苏醒写服务:当前SEXC60VELacrosse,实施stop group_replication;复苏其余的特别SEEvoqueVEPAJERO变符合规律。是或不是还会有其余措施?

     

    4 GROUP中剔除一个分子,假使N个节点,一个节点故障,是应用非常多投票机制照旧整个一样投票机制?

     

    参谋文书档案:

    mysql官方在二〇一五1212行业内部宣告了group replication版本,官方网站详细地址:

    感激京东的汉语翻译: ,某些地点字面直译,某个倒霉明白,假如以为驾驭有误,可比照看下保加尼斯语文书档案。 翻译粤语文书档案下载地址:

     

    7  未减轻难题

    1 能够透过 show slaves status for channel 'group_replication_recovery' 查看recovery通道执市价况,然则怎么看 applier呢?(show slaves status for channel 'group_replication_applier'报错 )

    2 当宕机超越有效个数时,查看replication_applier_status,状态平常,不过ONLINE的server实际上不提供写服务,仅提供读服务,能够经过哪些艺术便捷判断呢?个人感觉是以下推断,是不是有越来越好的点子?

     

    show global variables like 'super%';

    SELECT * FROM performance_schema.replication_group_members;

    如果super_read_only是开发银行的,那么该成员仅提供读服务;

    如果super_read_only是关门的,何况 replication_group_members 中符合规律的积极分子n 知足 2n 1 > 整个GROUP成员个数,並且该成员的 member state是online,则该成员可提供读写服务。

     

    3 当宕机超过有效个数时,ONLINE的server仅提供读服务,假如须要运维写服务,近年来个人测量试验结果是唯有两种方案复苏写服务:当前SE福睿斯VELX570,施行stop group_replication;苏醒别的的不胜SE君越VEPRADO变不荒谬。是还是不是还会有别的办法?

     

    4 GROUP中删去二个分子,假诺N个节点,二个节点故障,是选拔好些个投票机制照旧整个等同投票机制?

     

    参考文书档案:

    mysql官方在20151212正经通告了group replication版本,官方网站详细地址:

    谢谢京东的粤语翻译: ,有个别地点字面直译,有个别倒霉通晓,假若感觉领会有误,可对照应下英语文书档案。 翻译普通话文书档案下载地址:

     

    mysql> change master to master_host='192.168.1.108',master_user='replication',master_password='123456',master_log_file='mysql-bin.000028', master_log_pos=866;

                  mysql> start slave;

     

           4、查看各服务器的图景:

                  mysql> show slave statusG;

                  出现:Slave_IO_Running: Yes

                  Slave_SQL_Running: Yes

                  则状态不奇怪,间接测量试验数据能或无法联合就OK了!

    本文由新葡亰496net发布于网络数据库,转载请注明出处:配备维护故障处理全集,Mysql主主同步

    关键词: