菜单

[MySQL Reference Manual]17 Group Replication

2019年5月23日 - sqlite

17.4.2 协调Recovery

当1个新的成员要插足到group,会连接到3个适龄的donor并且获取数据,成员会一向获得直到状态变为online。

Donor选择

Donor选取是随便的在group中选二个分子。同2个成员不会被增选数十次。假诺连续到donor战败,那么会自动或去老是新的donor,壹旦超越连接重试限制就能报错。

强制自动Donor切换

出现以下问题的时候会自行切换成贰个新的donor,并尝试连接:

一.    清理数据场景,假设被选取的donor包蕴数据清理,但是是recovery要求的,那么会生出错误并且,获取三个新的donor。

2.    重复数据,假如一个joiner已经包涵了壹部分数据,和selected的有争执,那么也会告诉错误,并且接纳二个新的donor。

3.    别的错误,任何recovery线程的失实都会接触,连接叁个新的donor。

Donor连接重试

Recovery数据的传导是依赖binlog和现有的MySQL复制框架,由此大概会有局地传输难点导致receiver大概applier格外。那年会有donor切换。

重试次数

暗中同意从donor pool里面能够尝尝13遍三番五次,也可以通过参数修改,一下本子设置成了1四遍:

SET GLOBAL group_replication_recovery_retry_count= 10;

Sleep Routines

因此参数设置:

SET GLOBAL group_replication_recovery_reconnect_interval= 120;

安装为120秒,唯有当joiner尝试连接了具有的donor,不过并未有适合的,并且未有多余的,那么根据参数来sleep。

壹柒.5.一 Ip地址白名单

IP白名单,是允许其余程序依旧服务连接group
Replication的安装。暗许是内网,show的时候显示AUTOMATIC,参数是grou_replication_ip_whitelist。若s一装置了,s二连接的时候,会先去查看白名单,然后再思念是不是接受s二的连接。

暗许配置呈现AUTOMATIC,可以通过荒谬日志查看:

2016-07-07T06:40:49.320686Z 4 [Note] Plugin group_replication
reported: ‘Added automatically \\

IP ranges 10.120.40.237/18,10.178.59.44/22,127.0.0.1/8 to the whitelist’

为了进一步安全能够手动设置那么些白名单

mysql> STOP GROUP_REPLICATION;

mysql> SET GLOBAL group_replication_ip_whitelist=”10.120.40.237/18,10.178.59.44/22,127.0.0.1/8″;

mysql> START GROUP_REPLICATION;

一柒.四.三 网络隔开分离

17.5 Group Replication安全性

1七.七 前提和界定

一柒.二.1.三 用户授权

Group Replication使用异步复制的说道,管理布满的过来,来共同就要参预group的积极分子。遍布的借尸还魂管理依赖于复制通道,group_replication_recovery 用来在group成员之内做传输。因而须求三个复制用户和丰盛的权能,用户成员之内的过来复制通道。

始建三个持有REPLICATION_SLAVE权限的用户,可是那几个历程不能够被binlog捕获。

mysql> SET SQL_LOG_BIN=0;

Query OK, 0 rows affected (0,00 sec)

 

mysql> CREATE USER rpl_user@’%’ IDENTIFIED BY ‘rpl_pass’;

Query OK, 0 rows affected (0,00 sec)

 

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@’%’;

Query OK, 0 rows affected, 1 warning (0,00 sec)

 

mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0,00 sec)

 

mysql> SET SQL_LOG_BIN=1;

Query OK, 0 rows affected (0,00 sec)

配备好将来,使用change master to语句配置服务

mysql> CHANGE MASTER TO MASTER_USER=’rpl_user’, MASTER_PASSWORD=’rpl_pass’ \\

              FOR CHANNEL ‘group_replication_recovery’;

Query OK, 0 rows affected, 2 warnings (0,01 sec)

布满式复苏的首先步正是把服务进入到Group中,如果账号和权杖设置的不对那么无法运维复苏进程,最注重的是心有余而力不足加入到group。类似的,假设成员不可能科学的通过host识别别的成员那么恢复生机进度也会错误。能够由此performance_schema.
replication_group_members查看host。能够利用report_host分裂开来。

17.2 Getting Start

17 Group Replication

17 Group Replication..
1

17.1 Group Replication后台…
1

17.1.1 Replication技术…
1

一七.一.一.一 主从复制…

17.1.1.2 Group Replication..
1

17.一.二 Group Replication使用场景…
1

17.1.3 Group Replication细节…
1

一7.1.3.一 错误开采…

17.1.3.2 Group成员…
1

一⑦.1.三.三 错误容忍…

17.2 Getting Start1

一7.2.一 Group Replication陈设单主形式…

17.2.1.1 部署Group Replication实例…
1

壹七.二.一.二 为三个实例配置Group Replication..

一7.贰.一.三 用户授权…

17.2.1.4 执行Group Replication..
1

一7.贰.一.五 扩展三个实例到Group..

17.3 监控Group Replication..
1

17.3.1 Replication_group_member_stats.
1

17.3.2 Replication_group_members.
1

17.3.3 Replication_connection_status.
1

17.3.4 Replication_applier_status.
1

17.3.5 Group Replication Server States.
1

17.4 Group Replication操作…
1

一柒.4.一布局多主或许单主格局…

一7.四.一.1 单主格局…
1

17.四.1.二 多主方式…

17.4.1.3 查找Primary.
1

17.4.2 协调Recovery.
1

①柒.肆.三 网络隔开…

一7.肆.三.一 开掘互连网隔绝…

17.4.3.2 Unblocking a Partition..
1

17.5 Group Replication安全性…
1

1七.伍.1 Ip地址白名单…

17.5.2 SSL支持…
1

17.6 Group Replication变量…
1

一7.7 前提和限制…
1

17.7.1 Group Replication前提…
1

17.7.2 Group Replication限制…
1

17.8 FAQ..
1

一⑦.9 Group Replication技术细节…

1柒.九.一 Group Replication插件的构造…

17.9.2 The Group..
1

17.9.3 Data Manipulation Statements.
1

17.9.4 Data Definition Statements.
1

一柒.9.伍 布满式恢复生机…

17.5.9.1 Group Replication基础…
1

17.5.9.2 Recovering From a Point-in-time.
1

17.5.9.3 View Change.
1

一柒.玖.5.四 使用提构和分布式Recovery的限制…
1

17.9.6 可见性…
1

17.9.7 Group Replication性能…
1

壹7.九.七.一 调优Group交互线程…

17.玖.7.二 信息压缩…

一七.九.7.3 流量调节…
1

 

17.1.1 Replication技术

1柒.四.叁 互连网隔开分离

一7.贰.一.5 扩张2个实例到Group

其不时候曾经有1个分子了s1,已经有了有些多少,今后进入其它节点到Group

追加s二 到group,设置配置文件,基本和s一的直白,修改server_id,因为文书档案中是地面多实例,供给修改datadir等音信。

安装用于复制的用户:

SET SQL_LOG_BIN=0;

CREATE USER [email protected]‘%’;

GRANT REPLICATION SLAVE ON *.* TO [email protected]‘%’ IDENTIFIED BY ‘rpl_pass’;

SET SQL_LOG_BIN=1;

CHANGE MASTER TO MASTER_USER=’rpl_user’, MASTER_PASSWORD=’rpl_pass’ \\

    FOR CHANNEL ‘group_replication_recovery’;

接下来运营

mysql> INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;

Query OK, 0 rows affected (0,01 sec)

这里和s一区别等的地点是无需。

通过 performance_schema.replication_group_members 检查成员是还是不是常规。

查看从前s一插入的数据时候已经完全同步过来。

17.5.2 SSL支持

MySQL Group Replication支持openssl和yassl。Group连接和recovery连接都得以动用ssl。

Recovery配置SSL

Recovery是透过古板的异步复制连接实践的。一旦选择好了donor,就可以创立一个异步复制连接。那么须要给用户配置ssl。

donor> SET SQL_LOG_BIN=0;

donor> CREATE USER ‘rec_ssl_user’@’%’ REQUIRE SSL;

donor> GRANT replication slave ON *.* TO ‘rec_ssl_user’@’%’;

donor> SET SQL_LOG_BIN=1;

接下来配置部分相关参数。

new_member> SET GLOBAL group_replication_recovery_use_ssl=1;

new_member> SET GLOBAL group_replication_recovery_ssl_ca= ‘…/cacert.pem’;

new_member> SET GLOBAL group_replication_recovery_ssl_cert= ‘…/client-cert.pem’;

new_member> SET GLOBAL group_replication_recovery_ssl_key= ‘…/client-key.pem’;

下一场在change master to 连接过去。

new_member> CHANGE MASTER TO MASTER_USER=”rec_ssl_user” FOR CHANNEL “group_replication_recovery”;

new_member> START GROUP_REPLICATION;

Group连接配置SSL

Group 连接配置ssl和劳动有关,要是服务支撑,那么group也就协助,那么配置服务的SSL须求布署这一个参数:

[mysqld]

ssl_ca = “cacert.pem”

ssl_capath = “/…/ca_directory”

ssl_cert = “server-cert.pem”

ssl_cipher = “DHE-RSA-AEs256-SHA”

ssl_crl = “crl-server-revoked.crl”

ssl_crlpath = “/…/crl_directory”

ssl_key = “server-key.pem”

group_replication_ssl_mode= REQUIRED

17.9.一 Group Replication插件的布局

Group Replication是MySQL的二个插件,基于binary log,行形式,GTID。集成了现阶段的MySQL平台,举例performance schema,Group Replication结构如图:

图片 1

从图的方面初始,

Capture组件:用来跟着事务实行的上下文

Applier组件:负担实施长途事务

Recovery组件:当服务join到group的时候,用来回复数据,并且捕获错误。

下边是复制协议逻辑,管理争论会诊,接受和散播工作到group。

上面黑灰是为地点高档别的API提供底层服务。

17.1.3.2 Group成员

MySQL Group Replication管理到Group成员服务,那一个服务是放手的插件,定义了非平常衣服务是在线的,能够投票的。在线的服务被叫作view。由此各种group内的劳务都有三个同等的view,表示相当服务是移动的。

具备服务要求联合的不单单是事务提交,还应该有当前的view。因而一旦具备同意3个新的劳务的到场,然后Group重新配置,插足那些服务,并且出发view的修改。当服务离开group的时候也会生出,然后group重排配置,并且出发view的修改。

当2个成员自觉的距离group,会先伊始化Group的重新配置。然后起身二个经过,除了1开的服务之外,其余服务都要允许,假如成员是因为故障1开的,错误开采体制开掘难题,并且爆发重新配置的提出。供给具备的劳务同意,要是不可能同意那么group的陈设就不可能修改。也正是说管理员供给手工业来修补。

17.2.1.1 部署Group Replication实例

首先步不是八个实例。Group Replication是MySQL内部的插件,MySQL 伍.柒.一七之后版本都起来有。

mkdir data

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s1

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s2

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s3

一七.九.柒.三 流量调整

https://dev.mysql.com/doc/refman/5.7/en/group-replication-flow-control.html

 

17.3.2 Replication_group_members

Field

Description

Channel_name

通道名

Member_id

成员uuid

Member_host

成员host

Member_port

分子端口

Member_state

分子状态 (which can
be ONLINE, E安德拉ROWrangler, RECOVE奥迪Q7ING, OFFLINE or UNREACHABLE).

17.4 Group Replication操作

17.9.4 Data Definition Statements

DDL语句,近些日子不援助原子性可能事务性,由此假若施行,假如不用了不能够回滚。由此DDL的言辞实施,包罗了这些object的数码的退换要在同七个劳动上。单主的group Replication是不会有题指标。

MySQL DDL是不协助工作的。服务实行提交没有group的允许的,由此必须把DDL和含有那一个object的DML放在二个服务上运转。

1七.四.一配备多主或然单主方式

Group Replication有三个不一致的形式:

一.    单主方式

二.    多主方式

私下认可是单主方式的,不能够的格局不能够冒出在二个group中,比方二个分子是单主,二个成员是多主。切换形式须求重新配置,然后重启。不管怎么样方式,Group
Replication都不帮助failover。那些必须由程序自个儿来拍卖,或然用别样中间件。

当不是了多主,语句是足以包容的,当在多主格局,以下景况是会被检查语句的:

一.    即使贰个事务施行在serializable隔开分离品级,可是交给退步

贰.    假设事情试行的表有外键,可是付出失利

道理当然是这样的检查能够通过group_replication_enforce_update_everywhere_checks来关闭。

17.1.1.2 Group Replication

Group Replication可以用来容错系统,是1组相互交互的劳务。交互层提供了机制有限帮衬新闻的原子性和音信的并行。

Group Replication完结了多主的复制。复制组由两个劳务组合,每一个服务都能够运营专门的职业。读写的时候之后group承认之后技艺交到。只读事务因为无需和group交互,因而交到异常的快。也便是说关于写入事务,group须求调节职业是或不是交付,而不是原始的服务单独分明的。当原始服务希图付出,服务会自动播放。然后专业的全局顺序被确立。那个很关键,也便是说全数的劳务在同一的业务逐项下,收到了同样的事务。那样也就保障了group的多少1致性。

自然分歧的劳动出现的执行职业也许有争论。这种争辩出现在检查不一样写入集结的面世事务。那个历程叫做certification 。假设2个冒出事务在分化的服务上运维,更新了同等的行,那么就是发生抵触了。消除措施是交给顺序在头里的,另外一个就回滚。

图片 2
Group Replication也是一个shared-nothing系统,对全部数据的二个副本。

17.3 监控Group Replication

行使performance schema 上的表来监察和控制Group Replication,借使有performance_ schema那么就能在上头创立来个表:

·         performance_schema.replication_group_member_stats

·         performance_schema.replication_group_members

·         performance_schema.replication_connection_status

·         performance_schema.replication_applier_status

·         group_replication_recovery 

·         group_replication_applier

17.3.1 Replication_group_member_stats

Field

Description

Channel_name

Group Replication通道名

Member_id

成员的uuid

Count_transactions_in_queue

未通过争执检查的事务数量

Count_transactions_checked

通过顶牛检查的事体数量

Count_conflicts_detected

从没经过争辩检查的职业数量

Count_transactions_rows_validating

争辩检查数据库的尺寸

Transactions_committed_all_members

马到成功交付到成员的事情数量

Last_conflict_free_transaction

末段叁次龃龉,被释放的职业

1柒.玖.伍.4 使用建议和布满式Recovery的范围

遍及式Recovery有1部分限量,正是因为是基于异步复制的,由此只要当使用较老的备份大概镜像来做新的分子,就能够导致阶段一的时光会十分短。因而提出利用较新的备份和镜像,收缩阶段1的大运。

壹柒.玖.5 遍布式复苏

17.3.3 Replication_connection_status

Field

Description

Channel_name

通道名

Group_name

Group名

Source_UUID

Group的标识

Service_state

翻看服务是还是不是是group成员{ON, OFF
and CONNECTING};

Received_transaction_set

1度被该成员接受的gtid集

17.1.3.2 Group成员

MySQL Group Replication管理到Group成员服务,这么些服务是放置的插件,定义了要命服务是在线的,能够投票的。在线的劳务被称之为view。因而每一种group内的劳动都有二个一样的view,表示十分服务是活动的。

持有服务供给统一的不单单是事务提交,还或然有当前的view。因而只要全数同意三个新的劳动的插足,然后Group重新配置,加入那一个服务,并且出发view的修改。当服务离开group的时候也会时有爆发,然后group重排配置,并且出发view的改造。

当三个成员自觉的相距group,会先开首化Group的重新配置。然后起身八个进度,除了壹开的劳动之外,其余服务都要允许,假若成员是因为故障1开的,错误开掘体制开掘标题,并且发生重新配置的提议。必要具有的劳动同意,假诺无法同意那么group的配备就不可能修改。也便是说管理员须要手工业来修复。

一7.9.七.壹 调优Group交互线程

Group交互线程GCT,是循环运营的。FCT接受来自group和插件的音信,调控quorum和错误发掘,发送一些keep alive音讯,并且管理进出的业务。GCT等待incoming新闻队列。当未有消失的时候,GCT会等待,让GCT在进入sleep,多自旋壹会儿只怕在一些case会更加好些。因为sleep会切出cpu。能够透过参数来设置自旋的岁月:

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

一7.玖.柒.2 音讯压缩

当出现互联网带宽的瓶颈,新闻压缩在group交互层能够提供30-十分四的吞吐量提高。

TCP是点对点的,当有N个连接,那么快要发N次新闻。因为binary
log量大,压缩率也相当高,由此对大事务来讲是贰个强制的表征。

图片 3

压缩爆发在group交互引擎层,在多少被GCT管理前,所以他的上下文是mysql用户会电话线程。压缩依照阀值来铺排,暗中同意都以收缩的。也远非供给group中持有的分子都必须运维削减技能应用。当接到贰个音信的时候,成员检查消息头,看看是还是不是减掉的,如果是那么举行解压。

压缩算法使用LZ四。暗许压缩阀值是1000000字节。压缩阀值能够经过参数设置,1旦失误超越这些阀值就能够被收缩。

STOP GROUP_REPLICATION;

SET GLOBAL group_replication_compression_threshold= 2097152;

START GROUP_REPLICATION;

此处压缩阀值是二MB,假诺工作复制的消息大于二MB,就能减弱。把参数设置为0来撤消压缩。

17.3.2 Replication_group_members

Field

Description

Channel_name

通道名

Member_id

成员uuid

Member_host

成员host

Member_port

成员端口

Member_state

分子状态 (which can
be ONLINE, E纳瓦拉RO瑞虎, RECOVE索罗德ING, OFFLINE or UNREACHABLE).

壹7.玖 Group Replication本事细节

17.9.2 The Group

MySQL Group Replication,是一群服务组合。有三个uuid的group名。Group是动态的劳动能够相差或然参预。Group会服务进入大概离开的时候调治本人。

若果3个劳动投入group,会自动从曾经存在的服务上获取数据,追上来。那么些合伙状态是异步的。借使服务离开group,剩下的劳动会发觉并且重新配置group。

17.7.1 Group Replication前提

基本功供给:

一.    innodb存款和储蓄引擎:因为一旦出现争辩要求回滚,那么存款和储蓄引擎要帮助工作。

贰.    主键,因为推断是还是不是争持供给用到主键

三.    IPv肆,近来只帮忙ipv4

四.    互连网品质,因为group Replication是贰个集群所以对互连网带宽须求只怕比较高。

劳动参数设置:

一.    运维binlog,因为group
Replication如故注重binlog实行数量同步的。

二.    Slave update logs,因为新参与的服务要求recovery,须求用到binlog,如若当选了donor是slave,那么就有用了

三.    运维GTID,group
Replication的event应用都是正视GTID的。

4.    复制音信囤积格局,复制新闻都务求保留在表上。

五.    Transaction write set extraction,写作业提取,这里都用XXHASH6肆.

陆.    10二线程,group成员能够开拾二线程 applier。供给安装2个参数
slave-parallel-workers=N:线程数量
slave-preserve-commit-order=一:因为group
Replication要保管成员工作提交顺序要和primary同样,由此须求安装。
slave-parallel-type=logical_clock表示能够出现的专业

一七.二.一.贰 为一个实例配置Group Replication

配备服务的骨干配备:

[mysqld]

 

# server configuration

datadir=<full_path_to_data>/data/s1

basedir=<full_path_to_bin>/mysql-5.7/

 

port=24801

socket=<full_path_to_sock_dir>/s1.sock

布局复制相关,并运营GTID

server_id=1

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW

Group Replication配置

transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name=”aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= “127.0.0.1:24901”

loose-group_replication_group_seeds= “127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”

loose-group_replication_bootstrap_group= off

第一行:全体的写入的业务的write set使用XXHASH6肆进行编码。

其次行:要进入的group的名字

其3行:服务运行后,不活动运营

第⑥行:使用1二7.0.0.一,端口为2490一,来接入group成员的连年。

第陆行:当进入贰个group时,要求连续的host,只须要再而三三个,然后该阶段会供给group重新配置,允许服务器投入到group。当几个劳务同时须要进入group,保险用的seed已经在group 中。

第四行:插件是还是不是涉嫌到group,这一个参数很入眼,必须只有叁个劳务应用,不然会油不过生主差异的图景,就是区别的group有同样的Group名字。第一个劳务实例online之后就剥夺那么些选项。

17.5.9.3 View Change

开始:稳定的Group

始于是1组稳固的online的group,各种服务都以online的。

图片 4

View Change:成员进入

当有一个新的积极分子加入,view change 早先推行,每种online服务队会队列二个view
change log event。为何要队列,因为有此外东西可能也在队列上,并且是属于老的view的。

不单单如此,joiner会接纳2个group 里面包车型客车online成员作为donor,来一块数据.

图片 5

发端传输:Catching Up

假若joiner选用了三个donor,就能够成立贰个异步的复制连接,用来同步binlog数据。直到线程管理到view change log event。

图片 6

View id会在同有时间传输到全部的分子,joiner知道到丰盛view id复制要她结束。View
id能够料定,哪些数据属于哪个view。当joiner同步donor的数据的时候也会缓存,过来的职业。同步结束后,会利用这一个职业。

图片 7

最后:Caught Up

当joiner开掘view change log
event是意料的view id,连接受donor会被搁浅,并起首使用缓存的作业。就算在binlog中只是二个标识,表示view修改。也能用来确认新成员参预到group。假诺未有,joiner就从未丰硕的音讯来规定,参与之后的事情。

Catch up的时日,由专业生成的速度调控。在选择到时候是不会潜移默化别的成员的事务。

图片 8

17.3.1 Replication_group_member_stats

Field

Description

Channel_name

Group Replication通道名

Member_id

成员的uuid

Count_transactions_in_queue

未通过争论检查的政工数量

Count_transactions_checked

经过争辨检查的作业数量

Count_conflicts_detected

未有经过争辨检查的事务数量

Count_transactions_rows_validating

争论检查数据库的轻重缓急

Transactions_committed_all_members

马到功成交付到成员的作业数量

Last_conflict_free_transaction

最后贰回冲突,被释放的事情

17.3.5 Group Replication Server States

表replication_group_members在view发生变化的时候就能够修改,比如group的布局动态变化。若是出现网络分离,大概服务离开group,消息就能够被报告,依照不通的劳动获得的消息闭塞。注意若是服务离开了group,那么就无法得到任何服务的新闻。假使爆发疏离,举个例子quorum丢失,服务就不能够相互进行同步。相当于说会报告unreachable而不会一个假设状态。

Field

Description

Group Synchronized

ONLINE

服务online能够提供全方位劳动

Yes

RECOVERING

分子正在复苏,之后会形成online黄台

No

OFFLINE

插件已经安装,可是成员不属于别的group

No

ERROR

在recovery阶段可能应用修改的时候,出现错误

No

UNREACHABLE

荒谬排查可疑服务不可能连接。

No

 

一七.二.壹.伍 扩展3个实例到Group

本条时候曾经有一个成员了s壹,已经有了部分数据,以往加入其它节点到Group

扩展s二 到group,设置配置文件,基本和s1的一向,修改server_id,因为文书档案中是地点多实例,供给修改datadir等新闻。

设置用于复制的用户:

SET SQL_LOG_BIN=0;

CREATE USER rpl_user@’%’;

GRANT REPLICATION SLAVE ON *.* TO rpl_user@’%’ IDENTIFIED BY ‘rpl_pass’;

SET SQL_LOG_BIN=1;

CHANGE MASTER TO MASTER_USER=’rpl_user’, MASTER_PASSWORD=’rpl_pass’ \\

    FOR CHANNEL ‘group_replication_recovery’;

然后运营

mysql> INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;

Query OK, 0 rows affected (0,01 sec)

此处和s壹不壹致的地点。

START
GROUP_REPLICATION;

通过 performance_schema.replication_group_members 检查成员是还是不是正规。

翻看在此之前s一插入的数目时候已经完全同步过来。

17.4.3.2 Unblocking a Partition

Group Replication能够强制成员配置来重新恢复设置。一下场馆唯有S1,S二,就足以强制成员列表,通过设置变量group_replication_force_members变量。

图片 9

假若S一,S2存活,其他都非预期退出group,想要强制成员只有S1,S二。

首先查看S壹上的成员列表:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |      
13004 | UNREACHABLE  |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

然后从S1,S2中获取@@group_replication_local_address,然后设置到变量中

mysql> SELECT @@group_replication_local_address;

+———————————–+

| @@group_replication_local_address |

+———————————–+

| 127.0.0.1:10000                   |

+———————————–+

1 row in set (0,00 sec)

mysql> SELECT @@group_replication_local_address;

+———————————–+

| @@group_replication_local_address |

+———————————–+

| 127.0.0.1:10001                   |

+———————————–+

1 row in set (0,00 sec)

mysql> SET GLOBAL group_replication_force_members=”127.0.0.1:10000,127.0.0.1:10001″;

Query OK, 0 rows affected (7,13 sec)

检查members

mysql> select * from performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

+—————————+————————————–+————-+————-+————–+

2 rows in set (0,00 sec)

当强制贰个新的积极分子配置,要保管别的服务是终止了。在情景中S三,S四,S五假若不是真的unreachable其实是online的,那么她们自个儿就能已变成二个作用分区。那样强制成员只怕会导致主分隔的意况。由此保险其余服务是关门的很要紧,假若未有,那么就手工业关闭他们。

17.7.1 Group Replication前提

基础供给:

一.    innodb存款和储蓄引擎:因为纵然出现争辩要求回滚,那么存款和储蓄引擎要帮助专门的职业。

二.    主键,因为判定是不是顶牛必要用到主键

三.    IPv④,近期只扶助ipv4

4.    网络品质,因为group Replication是二个集群所以对网络带宽须求大概相比较高。

劳动参数设置:

一.    运行binlog,因为group
Replication依旧依赖binlog举办数量同步的。

二.    Slave update logs,因为新进入的服务必要recovery,需求用到binlog,固然当选了donor是slave,那么就有用了

3.    运行GTID,group
Replication的event应用都以依附GTID的。

四.    复制消息存款和储蓄格局,复制新闻都须求保存在表上。

伍.    Transaction write set extraction,写作业提取,这里都用XXHASH64.

六.    八线程,group成员能够开八线程 applier。须求设置2个参数
slave-parallel-workers=N:线程数量
slave-preserve-commit-order=一:因为group
Replication要保管成员专门的学问提交顺序要和primary同样,因而须求设置。
slave-parallel-type=logical_clock代表可以出现的工作

一七.2.一.三 用户授权

Group Replication使用异步复制的构和,管理布满的还原,来一齐将要进入group的分子。遍布的复原管理注重于复制通道,group_replication_recovery 用来在group成员之内做传输。由此必要三个复制用户和丰硕的权限,用户成员之内的还原复制通道。

开创1个享有REPLICATION_SLAVE权限的用户,不过那些进度无法被binlog捕获。

mysql> SET SQL_LOG_BIN=0;

Query OK, 0 rows affected (0,00 sec)

 

mysql> CREATE USER [email protected]‘%’ IDENTIFIED BY ‘rpl_pass’;

Query OK, 0 rows affected (0,00 sec)

 

mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]‘%’;

Query OK, 0 rows affected, 1 warning (0,00 sec)

 

mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0,00 sec)

 

mysql> SET SQL_LOG_BIN=1;

Query OK, 0 rows affected (0,00 sec)

计划好未来,使用change master to语句配置服务

mysql> CHANGE MASTER TO MASTER_USER=’rpl_user’, MASTER_PASSWORD=’rpl_pass’ \\

              FOR CHANNEL ‘group_replication_recovery’;

Query OK, 0 rows affected, 2 warnings (0,01 sec)

布满式苏醒的第三步就是把劳动进入到Group中,假若账号和权限设置的不对那么不能运维恢复进度,最重要的是无力回天插手到group。类似的,如若成员无法科学的经过host识别别的成员那么苏醒进程也会错误。能够因此performance_schema.
replication_group_members查看host。能够动用report_host不一样开来。

一7.4.一.2 多主情势

在多主格局下,和单主不通,无需公投产生多主,服务未有特定的角色。全部的服务都以可读写的。

图片 10

一柒.1.一.一 主从复制

MySQL古板的主从复制。有贰个主,多个从。主实施专业,提交然后发送到从,重新施行。是shared-nothing系统,全数的劳动暗中认可是full copy的。

图片 11

以此是半1块复制,在协议中加进了2个联袂的不走。也正是说主在提交时会等待从的通知。然后主继续提交操作。
图片 12

17.5.9.3 View Change

开始:稳定的Group

开端是1组稳固的online的group,各样服务都以online的。

图片 13

View Change:成员参与

当有多个新的分子进入,view change 开首施行,每种online服务队会队列两个view
change log event。为何要队列,因为有别的东西只怕也在队列上,并且是属于老的view的。

不单单如此,joiner会选拔三个group 里面包车型客车online成员作为donor,来共同数据.

图片 14

开端传输:Catching Up

假若joiner选拔了3个donor,就能创立3个异步的复制连接,用来同步binlog数据。直到线程管理到view change log event。

图片 15

View id会在同不经常候传输到具有的成员,joiner知道到10分view id复制要他适可而止。View
id能够一览理解,哪些数据属于哪个view。当joiner同步donor的多寡的时候也会缓存,过来的思想政治工作。同步截止后,会利用那么些业务。

图片 16

最后:Caught Up

当joiner开掘view change log
event是预期的view id,连接受donor会被中止,并初叶采用缓存的政工。固然在binlog中只是贰个符号,表示view修改。也能用来承认新成员参加到group。就算未有,joiner就从不丰硕的新闻来规定,参预之后的事务。

Catch up的时间,由业务生成的快慢调控。在动用到时候是不会影响别的成员的业务。

图片 17

17.4.1.3 查找Primary

Primary 能够经过show status 只怕select查找:

mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= ‘group_replication_primary_member’;

+————————————–+

| VARIABLE_VALUE                       |

+————————————–+

| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |

+————————————–+

1 row in set (0,00 sec)

一柒.九.① Group Replication插件的布局

Group Replication是MySQL的一个插件,基于binary log,行方式,GTID。集成了现阶段的MySQL平台,比方performance schema,Group Replication结构如图:

图片 18

从图的方面开头,

Capture组件:用来跟着事务施行的上下文

Applier组件:肩负实施长途事务

Recovery组件:当服务join到group的时候,用来回复数据,并且捕获错误。

上边是复制协议逻辑,管理冲突检查判断,接受和散布工作到group。

下边中湖蓝是为地点高档其余API提供底层服务。

17.9.7 Group Replication性能

一7.一.贰 Group Replication使用情状

略,具体看:

https://dev.mysql.com/doc/refman/5.7/en/group-replication-use-cases.html

17.9.2 The Group

MySQL Group Replication,是一堆服务组合。有三个uuid的group名。Group是动态的劳动能够相差可能到场。Group会服务投入大概离开的时候调度和谐。

设若二个劳动进入group,会活动从曾经存在的服务上获取数据,追上来。这几个合伙状态是异步的。假如服务离开group,剩下的劳动会发觉并且重新配置group。

17.8 FAQ

https://dev.mysql.com/doc/refman/5.7/en/group-replication-frequently-asked-questions.html

1七.肆.一.贰 多主情势

在多主格局下,和单主不通,无需大选发生多主,服务未有特定的剧中人物。全体的劳务都以可读写的。

图片 19

17.2 Getting Start

17.四.一布局多主只怕单主形式

Group Replication有1个不等的情势:

一.    单主格局

二.    多主方式

暗中同意是单主形式的,无法的格局无法现身在一个group中,举例一个分子是单主,三个分子是多主。切换形式供给重新配置,然后重启。不管怎么样形式,Group
Replication都不支持failover。这几个必须由程序自身来拍卖,也许用此外中间件。

当不是了多主,语句是足以匹配的,当在多主形式,以下情状是会被检查语句的:

壹.    假使1个作业试行在serializable隔绝等第,不过付出战败

二.    即便工作试行的表有外键,不过付出退步

自然检查能够经过group_replication_enforce_update_everywhere_checks来关闭。

一七.一.三.三 错误容忍

Group Replication实现了Paxos分布式算法来提供服务的布满式服务。需求大部分的劳务活动以高达大许多,来做个调节。直接影响了系统可以容忍的不当容错公司如下,服务器n,容错f:n = 二 x f +
1

也便是说,容忍三个荒谬那么group必须求有三个分子。因为尽管有三个错了,还会有3个,任然能够产生大很多来拍卖部分作业。假如此外二个也挂,
那么就剩下一个,不发形成大大多(大于四分之壹)。

Group Size

Majority

Instant Failures Tolerated

1

1

0

2

2

0

3

2

1

4

3

1

5

3

2

6

4

2

7

4

3

1七.一.三.一 错误发掘

有二个荒谬发掘体制,用来找寻告诉丰盛服务是静默的,然后1旦为早已挂了。错误发掘其实布满式服务用来提供劳动的移动新闻。之后group决定服务实在弄错,那么余下的group成员就能化解这几个成员。

当服务静默,错误开掘体制就能被触发。当服务A未有接到来自服务B的,而且超时就能够触发。

假如服务被有着的分子隔绝,并猜疑持有的node都是漏洞百出的。就不能被group尊敬,可疑是没用的。当服务被可疑,那么就无法再施行另内地点专门的职业。

17.1.1 Replication技术

17 Group Replication

17 Group Replication.. 1

17.1 Group Replication后台… 1

17.1.1 Replication技术… 1

壹7.1.1.一 主从复制… 一

17.1.1.2 Group Replication.. 1

1柒.一.2 Group Replication使用场景… 一

17.1.3 Group Replication细节… 1

壹七.1.3.一 错误开采… 一

17.1.3.2 Group成员… 1

17.一.三.三 错误容忍… 1

17.2 Getting Start1

17.贰.1 Group Replication铺排单主形式… 壹

17.2.1.1 部署Group Replication实例… 1

1七.二.1.二 为二个实例配置Group Replication.. 一

一七.2.一.3 用户授权… 1

17.2.1.4 执行Group Replication.. 1

壹7.二.一.5 扩大一个实例到Group.. 一

17.3 监控Group Replication.. 1

17.3.1 Replication_group_member_stats. 1

17.3.2 Replication_group_members. 1

17.3.3 Replication_connection_status. 1

17.3.4 Replication_applier_status. 1

17.3.5 Group Replication Server States. 1

17.4 Group Replication操作… 1

1七.4.一配备多主大概单主形式… 一

1柒.四.一.1 单主方式… 一

壹七.四.一.2 多主方式… 一

17.4.1.3 查找Primary. 1

17.4.2 协调Recovery. 1

一七.4.三 互连网隔开… 一

壹七.四.三.1 发现互连网隔断… 一

17.4.3.2 Unblocking a Partition.. 1

17.5 Group Replication安全性… 1

1七.5.壹 Ip地址白名单… 壹

17.5.2 SSL支持… 1

17.6 Group Replication变量… 1

一柒.7 前提和限制… 一

17.7.1 Group Replication前提… 1

17.7.2 Group Replication限制… 1

17.8 FAQ.. 1

17.玖 Group Replication手艺细节… 一

一柒.玖.一 Group Replication插件的布局… 一

17.9.2 The Group.. 1

17.9.3 Data Manipulation Statements. 1

17.9.4 Data Definition Statements. 1

1柒.玖.5 布满式复苏… 一

17.5.9.1 Group Replication基础… 1

17.5.9.2 Recovering From a Point-in-time. 1

17.5.9.3 View Change. 1

一7.玖.5.四 使用提议和布满式Recovery的限制… 一

17.9.6 可见性… 1

17.9.7 Group Replication性能… 1

17.9.柒.1 调优Group交互线程… 一

一七.九.七.2 音信压缩… 一

一7.9.7.3 流量调整… 1

 

一7.四.三.壹 发现互联网隔开分离

Replication_group_members包罗了现阶段view里面包车型地铁兼具服务的和劳动的事态。大诸多状态下服务运作是健康的,所以那些表对全体服务来讲是同一的。借使出现网络隔开,那么quorum就能够丢掉,然后表上回展现UNREACHABLE。

图片 20

比如有个情景有四个服务,然后因为事故,个中一个丢失:

·         Server s1 with member
identifier 199b2df7-4aaf-11e6-bb16-28b2bd168d07

·         Server s2 with member
identifier 199bb88e-4aaf-11e6-babe-28b2bd168d07

·         Server s3 with member
identifier 1999b9fb-4aaf-11e6-bb54-28b2bd168d07

·         Server s4 with member
identifier 19ab72fc-4aaf-11e6-bb51-28b2bd168d07

·         Server s5 with member
identifier 19b33846-4aaf-11e6-ba81-28b2bd168d07

丢掉从前的情状:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | ONLINE       |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | ONLINE       |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |      
13004 | ONLINE       |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

下一场因为事故quorum丢失:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |   
   13004 | UNREACHABLE  |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

因为许多一度丢掉,所以Group就不可能持续运转。为了让Group复苏运维供给复位group成员列表。也许关闭s1,s2的group replication,然后消除s3,s四,s伍并发的主题材料,然后重启group replication。

17.8 FAQ

https://dev.mysql.com/doc/refman/5.7/en/group-replication-frequently-asked-questions.html

17.3.4 Replication_applier_status

Field

Description

Channel_name

通道名

Service_state

劳务场合

Remaining_delay

是还是不是安排了延期

Count_transactions_retries

重试实施的事务个数

Received_transaction_set

壹度被摄取的gtid集

一七.5.一 Ip地址白名单

IP白名单,是允许其余程序依旧服务连接group
Replication的设置。私下认可是内网,show的时候突显AUTOMATIC,参数是grou_replication_ip_whitelist。若s一安装了,s2连接的时候,会先去查看白名单,然后再怀恋是或不是接受s二的连天。

暗中同意配置展现AUTOMATIC,能够通过荒谬日志查看:

2016-07-07T06:40:49.320686Z 4 [Note] Plugin group_replication
reported: ‘Added automatically \\

IP ranges 10.120.40.237/18,10.178.59.44/22,127.0.0.1/8 to the whitelist’

为了进一步安全能够手动设置那个白名单

mysql> STOP GROUP_REPLICATION;

mysql> SET GLOBAL group_replication_ip_whitelist=”10.120.40.237/18,10.178.59.44/22,127.0.0.1/8″;

mysql> START GROUP_REPLICATION;

一七.一.一.壹 主从复制

MySQL古板的主从复制。有1个主,多个从。主试行工作,提交然后发送到从,重新施行。是shared-nothing系统,全体的服务暗许是full copy的。

图片 21

以此是半联合签名复制,在商榷中加进了2个同台的不走。也等于说主在提交时会等待从的照顾。然后主继续提交操作。

图片 22

17.2.1.4 执行Group Replication

弄完上边的配备,并且运营后,连接受服务,推行一下命令:

INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;

安装好未来能够经过show plugins查看,即便设置成功就能够在回去中。

启航group,让s一关系group并且运行Group Replication。那些涉及要单个服务器完毕,并且只可以运营壹次。所以这几个布局无法保留在布署文件中,如若保留了,下一次运行会自动关联到第一个Group,并且名字是一模一样的。假设按钮plugin,但是参数是ON的也可能有其壹主题素材。

SET GLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

SET GLOBAL group_replication_bootstrap_group=OFF;

假使start完毕,就足以查到成员了:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+—————+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |

+—————————+————————————–+————-+————-+—————+

| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost      |      
24801 | ONLINE        |

+—————————+————————————–+————-+————-+—————+

1 row in set (0,00 sec)

追加一些数额:

mysql> CREATE DATABASE test;

Query OK, 1 row affected (0,00 sec)

 

mysql> use test

Database changed

mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);

Query OK, 0 rows affected (0,00 sec)

 

mysql> INSERT INTO t1 VALUES (1, ‘Luis’);

Query OK, 1 row affected (0,01 sec)

17.5.9.2 Recovering From a Point-in-time

利用donor把 joiner同步到钦点的点,donor和joiner使用GTID机制。不过单单GTID是远远不足的,因为GTID只可以提供joiner丢失哪个事务。不能够用来标志,要更新到哪个点,也不可能用来传输认证音信。

View 和 View Change

View:当前可用服务的列表

View change:表示产生修改的产生,举个例子join或然leave

View标志符:是view的并世无双标志,在view修改的时候生成。

在group交互层,view修改会有各自的view id来不相同修改view的退换前和退换后。

View标记符由一个部分组成:一.随机数,由group生成,二.自增。Group生成的轻巧数,会直接保存知道group消亡,第贰局地在view每一回修改的时候都会自增。

动用二个部分来表示view标记符,主假使为了表示知道group修改,实际上,只使用自增会导致view标记符和事先的group重复,破坏了binary
log数据的唯壹性。

17.1.二 Group Replication使用情形

略,具体看:

https://dev.mysql.com/doc/refman/5.7/en/group-replication-use-cases.html

17.9.4 Data Definition Statements

DDL语句,近些日子不援助原子性大概事务性,因而只要实行,借使不用了不能够回滚。由此DDL的言语执行,包罗了那么些object的数指标修改要在同三个劳务上。单主的group Replication是不会一时的。

MySQL DDL是不帮助专门的学业的。服务实践提交未有group的允许的,因而必须把DDL和带有这一个object的DML放在1个劳动上运转。

壹7.四.叁.1 开掘互联网隔断

Replication_group_members包罗了近日view里面包车型大巴保有服务的和服务的动静。大繁多场馆下服务运营是正规的,所以这些表对全体服务以来是一律的。若是出现互联网隔断,那么quorum就能够丢掉,然后表上回突显UNREACHABLE。

图片 23

诸如有个现象有6个劳务,然后因为事故,当中三个丢失:

·         Server s1 with member
identifier 199b2df7-4aaf-11e6-bb16-28b2bd168d07

·         Server s2 with member
identifier 199bb88e-4aaf-11e6-babe-28b2bd168d07

·         Server s3 with member
identifier 1999b9fb-4aaf-11e6-bb54-28b2bd168d07

·         Server s4 with member
identifier 19ab72fc-4aaf-11e6-bb51-28b2bd168d07

·         Server s5 with member
identifier 19b33846-4aaf-11e6-ba81-28b2bd168d07

丢失在此以前的状态:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | ONLINE       |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | ONLINE       |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |      
13004 | ONLINE       |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

然后因为事故quorum丢失:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |   
   13004 | UNREACHABLE  |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

因为多数已经不见,所以Group就不可能持续运营。为了让Group复苏运维供给重新载入参数group成员列表。只怕关闭s一,s二的group replication,然后消除s3,s4,s5涌出的题目,然后重启group replication。

壹柒.一.叁.一 错误开掘

有二个指鹿为马发掘体制,用来找寻告诉非平常服装务是静默的,然后一旦为曾经挂了。错误开采实际上布满式服务用来提供劳务的运动音信。之后group决定服务确实弄错,那么余下的group成员就能够去掉那一个成员。

当服务静默,错误开掘体制就能够被触发。当服务A未有接过来自服务B的,而且超时就能够接触。

假诺服务被抱有的积极分子隔断,并可疑持有的node都是破绽百出的。就无法被group拥戴,可疑是行不通的。当服务被可疑,那么就不可能再举行另各州点专门的学业。

一7.1.三.3 错误容忍

Group Replication达成了Paxos分布式算法来提供服务的分布式服务。供给抢先5四%的劳务活动以高达大很多,来做个调整。直接影响了系统可以容忍的荒唐容错集团如下,服务器n,容错f:n = 贰 x f +

也正是说,容忍1个荒谬那么group须求求有一个分子。因为纵然有二个错了,还应该有二个,任然能够产生大诸多来拍卖部分作业。假设其余三个也挂,
那么就剩下一个,不发产生大许多(大于四5%)。

Group Size

Majority

Instant Failures Tolerated

1

1

0

2

2

0

3

2

1

4

3

1

5

3

2

6

4

2

7

4

3

一柒.九.5 遍布式复苏

17.5.9.2 Recovering From a Point-in-time

选拔donor把 joiner同步到钦点的点,donor和joiner使用GTID机制。然而单单GTID是远远不够的,因为GTID只可以提供joiner丢失哪个事务。不可能用来标志,要更新到哪个点,也不可能用来传输认证音信。

View 和 View Change

View:当前可用服务的列表

View change:表示产生修改的产生,比如join或许leave

View标志符:是view的独占鳌头标志,在view修改的时候生成。

在group交互层,view修改会有各自的view id来分裂修改view的改换前和更改后。

View标志符由3个部分组成:一.随机数,由group生成,贰.自增。Group生成的任性数,会一贯保留知道group消亡,第壹有的在view每便修改的时候都会自增。

动用3个部分来表示view标志符,首借使为了表示领悟group修改,实际上,只行使自增会导致view标识符和事先的group重复,破坏了binary
log数据的唯一性。

17.4.2 协调Recovery

当1个新的分子要投入到group,会连接到1个适宜的donor并且获取数据,成员会一贯获得直到状态变为online。

Donor选择

Donor选择是任性的在group中选三个分子。同三个分子不会被增选数次。若是连接到donor失败,那么会自动或去老是新的donor,1旦超越连接重试限制就能够报错。

强制自动Donor切换

并发以下难题的时候会活动切换成三个新的donor,并尝试连接:

壹.    清理数据场景,假使被挑选的donor包罗数据清理,可是是recovery须求的,那么会时有爆发错误并且,获取一个新的donor。

二.    重复数据,假如五个joiner已经包涵了部分多少,和selected的有争持,那么也会报告错误,并且接纳多少个新的donor。

三.    其余错误,任何recovery线程的不当都会触发,连接2个新的donor。

Donor连接重试

Recovery数据的传导是重视binlog和现有的MySQL复制框架,由此也许会有一部分传输难题导致receiver或许applier不不荒谬。这年会有donor切换。

重试次数

暗中同意从donor pool里面可以尝试10回再三再四,也足以由此参数修改,一下本子设置成了十三遍:

SET GLOBAL group_replication_recovery_retry_count= 10;

Sleep Routines

经过参数设置:

SET GLOBAL group_replication_recovery_reconnect_interval= 120;

安装为120秒,唯有当joiner尝试连接了具备的donor,可是从未适当的,并且未有剩余的,那么遵照参数来sleep。

17.9.3 Data Manipulation Statements

在多主下,任何服务都足以插入数据,任何服务在尚未协和下都可以运维专业,不过事情提交需要劳务和煦并操纵专门的学业去留。

和煦的指标:

1.    检查专门的学问是或不是相应被交付

贰.    传播专门的学业到其余服务并且动用

业务传播是原子性的,要不全体承受,要不全体不收受。若接受就能以同1的依次接受职业。争辩发掘是通过相比和检查事务的写入集达成。纵然出现冲突消除措施是保存第三个提交的思想政治工作。

壹7.四.1.一 单主情势

在单主方式下,唯有主是能够读写的,别的都不得不读取。这一个装置是机关的。主日常是关乎到group的,别的的分子join,自动学习主,并且安装为只读。

图片 24

在单主格局下,多主的检查被撤废,因为系统唯有三个服务是可写的。当主成员退步,自动主大选机制会选用新的主。然后台南根据成员的uuid举办排序然后选拔第三个。

当主离开Group,也会选出新主,一旦新主被选出来之后,就能安装可读写,其余任然是从。

17.四.1.1 单主格局

在单主形式下,唯有主是能够读写的,其余都只可以读取。那么些设置是机动的。主平日是关系到group的,其余的积极分子join,自动学习主,并且安装为只读。

图片 25

在单主情势下,多主的自己商量被打消,因为系统唯有二个劳务是可写的。当主成员退步,自动主大选机制会选取新的主。然后台北依据成员的uuid进行排序然后选取第三个。

当主离开Group,也会选出新主,一旦新主被选出来之后,就能够安装可读写,其余任然是从。

17.1.1.2 Group Replication

Group Replication能够用来容错系统,是一组相互交互的劳务。交互层提供了体制确认保障音讯的原子性和音信的相互。

Group Replication完结了多主的复制。复制组由多个服务组合,每种服务都能够运作专门的职业。读写的时候之后group认同之后技巧交付。只读事务因为无需和group交互,由此交到一点也不慢。也正是说关于写入事务,group须求调控工作是不是交付,而不是本来的劳务单独分明的。当原始服务图谋提交,服务会活动播放。然后专业的大局顺序被确立。这几个很注重,也正是说全数的劳务在同等的事情逐项下,收到了扳平的事体。这样也就保险了group的多寡1致性。

本来差异的服务出现的推行专业也许有冲突。这种抵触出现在检讨区别写入会集的现身事务。那几个进度叫做certification 。假如3个冒出事务在不一致的劳务上运转,更新了1致的行,那么正是发生争辨了。化解格局是提交顺序在前面包车型地铁,其余一个就回滚。

图片 26

Group Replication也是一个shared-nothing系统,对全数数据的1个别本。

17.5.2 SSL支持

MySQL Group Replication帮衬openssl和yassl。Group连接和recovery连接都得以使用ssl。

Recovery配置SSL

Recovery是由此守旧的异步复制连接实践的。1旦采取好了donor,就能创建三个异步复制连接。那么需求给用户配置ssl。

donor> SET SQL_LOG_BIN=0;

donor> CREATE USER ‘rec_ssl_user’@’%’ REQUIRE SSL;

donor> GRANT replication slave ON *.* TO ‘rec_ssl_user’@’%’;

donor> SET SQL_LOG_BIN=1;

下一场配置部分有关参数。

new_member> SET GLOBAL group_replication_recovery_use_ssl=1;

new_member> SET GLOBAL group_replication_recovery_ssl_ca= ‘…/cacert.pem’;

new_member> SET GLOBAL group_replication_recovery_ssl_cert= ‘…/client-cert.pem’;

new_member> SET GLOBAL group_replication_recovery_ssl_key= ‘…/client-key.pem’;

下一场在change master to 连接过去。

new_member> CHANGE MASTER TO MASTER_USER=”rec_ssl_user” FOR CHANNEL “group_replication_recovery”;

new_member> START GROUP_REPLICATION;

Group连接配置SSL

Group 连接配置ssl和劳务有关,假若服务帮助,那么group也就援救,那么配置服务的SSL要求配备那几个参数:

[mysqld]

ssl_ca = “cacert.pem”

ssl_capath = “/…/ca_directory”

ssl_cert = “server-cert.pem”

ssl_cipher = “DHE-RSA-AEs256-SHA”

ssl_crl = “crl-server-revoked.crl”

ssl_crlpath = “/…/crl_directory”

ssl_key = “server-key.pem”

group_replication_ssl_mode= REQUIRED

一七.九.七.贰 信息压缩

当出现网络带宽的瓶颈,信息压缩在group交互层能够提供30-十分四的吞吐量进步。

TCP是点对点的,当有N个连接,那么快要发N次音信。因为binary
log量大,压缩率也非常高,由此对大事务来讲是二个胁制的特色。

图片 27

减去爆发在group交互引擎层,在数量被GCT管理前,所以他的上下文是mysql用户会电话线程。压缩依据阀值来配置,暗许都以削减的。也尚无须求group中负有的积极分子都必须运转削减手艺使用。当收到多少个音信的时候,成员检查音信头,看看是否缩减的,借使是那么实行解压。

压缩算法使用LZ4。暗许压缩阀值是一千000字节。压缩阀值可以通过参数设置,一旦失误抢先这一个阀值就能够被核减。

STOP GROUP_REPLICATION;

SET GLOBAL group_replication_compression_threshold= 2097152;

START GROUP_REPLICATION;

那边压缩阀值是二MB,若是事情复制的信息大于二MB,就能回落。把参数设置为0来打消压缩。

[MySQL Reference Manual]17 Group Replication,manualreplication

17.6 Group Replication变量

略,自己看:

https://dev.mysql.com/doc/refman/5.7/en/group-replication-options.html

一7.九.7.3 流量调节

https://dev.mysql.com/doc/refman/5.7/en/group-replication-flow-control.html

 

http://www.bkjia.com/Mysql/1306046.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/1306046.htmlTechArticle\[MySQL Reference Manual]17 Group
Replication,manualreplication 17 Group Replication 17 Group Replication
.. 1 17.1 Group Replication 后台 … 1 17.1.1 Replication 技术 …
1…

壹7.二.1 Group Replication布署单主格局

各类实例能够运作在单个机器上,能够在同3个机器上。

图片 28

17.3 监控Group Replication

使用performance schema 上的表来监察和控制Group Replication,假如有performance_ schema那么就能够在地点成立来个表:

·         performance_schema.replication_group_member_stats

·         performance_schema.replication_group_members

·         performance_schema.replication_connection_status

·         performance_schema.replication_applier_status

·         group_replication_recovery 

·         group_replication_applier

1柒.七 前提和限量

壹⑦.九.⑦.壹 调优Group交互线程

Group交互线程GCT,是循环运维的。FCT接受来自group和插件的音信,调整quorum和不当开掘,发送一些keep alive消息,并且管理进出的事情。GCT等待incoming消息队列。当未有未有的时候,GCT会等待,让GCT在进入sleep,多自旋壹会儿或然在好几case会越来越好些。因为sleep会切出cpu。能够由此参数来设置自旋的时光:

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

17.4.1.3 查找Primary

Primary 能够由此show status 大概select查找:

mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= ‘group_replication_primary_member’;

+————————————–+

| VARIABLE_VALUE                       |

+————————————–+

| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |

+————————————–+

1 row in set (0,00 sec)

17.1.3 Group Replication细节

壹七.⑨ Group Replication技巧细节

17.9.6 可见性

https://dev.mysql.com/doc/refman/5.7/en/group-replication-observability.html

17.9.7 Group Replication性能

17.6 Group Replication变量

略,自己看:

https://dev.mysql.com/doc/refman/5.7/en/group-replication-options.html

17.1 Group Replication后台

最常用创立容错系统是运用手段来冗余组件,也正是说组件能够被删去,可是系统可能平时运转。复制的数据库必须面前蒙受的三个难题,他们须求维护和管制四个实例,还会有服务组合在一同成立,把整个其余守旧一分配布式系统组合的难点也亟须消除。

最重大的主题素材是抱着数据库和数指标复制在多少个服务合作下,逻辑是1律的还就算简简单单的。也正是说,三个劳务同意系统和数据的状态,并且同意系统发展时的每一种修改。正是劳务在种种数据库的传导的情景都必须同意,全体的管理就如在2个数据库恐怕未来会覆盖的其它数据库到平等的气象。

MySQL Group Replication提供了布满式复制,使用server之间的强连接,若是服务在师心自用的group,那么久会自行延续上。Group能够是单主,也能够是多主的。

有三个编写翻译好的劳务,在大4时间点,能够看group的一致性和可用性。服务能够插足,离开group,并且view会有照望的创新。一时候服务会极其离开group,那么错误诊断机制会发觉并且布告组并且修改view,这几个都以半自动的。

对于专门的学问提交,须求大许多允许。事务提交和回滚达成是由独立服务鲜明的,不是富有的劳动决定。倘诺有四个network
partition,那么就能招致崩溃,成员不能相互通讯,因此系统不能够管理,知道难题被化解。当然也可以有停放的,自动的主分歧尊敬的体制。

17.3.4 Replication_applier_status

Field

Description

Channel_name

通道名

Service_state

服务境况

Remaining_delay

是还是不是布署了延期

Count_transactions_retries

重试实践的事体个数

Received_transaction_set

现已被接收的gtid集

17.1.3 Group Replication细节

17.1 Group Replication后台

最常用创制容错系统是运用花招来冗余组件,也正是说组件能够被去除,可是系统只怕好端端运维。复制的数据库必须面对的二个难题,他们要求爱慕和管理五个实例,还应该有服务组合在联合创办,把整个其余古板一分配布式系统组合的难点也非得消除。

最要害的主题素材是抱着数据库和数据的复制在多少个劳务同盟下,逻辑是平等的同时是粗略的。也正是说,多少个劳务同意系统和数码的图景,并且同意系统提升时的各种修改。正是劳务在每种数据库的传输的情形都必须允许,全数的拍卖就邻近在一个数据库也许未来会覆盖的其余数据库到平等的事态。

MySQL Group Replication提供了布满式复制,使用server之间的强连接,要是服务在同1的group,那么久会自行连接上。Group可以是单主,也能够是多主的。

有3个编写翻译好的劳务,在随便时间点,能够看group的壹致性和可用性。服务能够参加,离开group,并且view会有关照的翻新。不时候服务会万分离开group,那么错误检查判断机制会发觉并且公告组并且修改view,这么些都以机关的。

对此事情提交,须求大大多允许。事务提交和回滚完毕是由独立服务明显的,不是享有的劳动决定。假若有三个network
partition,那么就能够招致崩溃,成员不能够相互通讯,由此系统无法管理,知道难题被消除。当然也许有内置的,自动的主差距爱护的体制。

17.7.2 Group Replication限制

Group Replication有这样一些范围:

一.    replication event checksum,因为涉嫌的难点,group replication无法动用event checksum

二.    gap lock,查验进度不选用gap lock,因为技术越来越好的反省争论难题。

三.    表锁和命名锁,核准进度不采用表锁和命名锁。

四.    SELANDIALIZABLE隔开分离品级,在多主group
replication私下认可是不援救的,如若设置了就能够不让提交。

5.    并发DDL和DML,多主DDL和DML在区别服务器出现是不帮忙的。那样不一样服务施行一样object的DDL和DML会唤起争持。

陆.    外键和级联,多主形式下不协理多等级的外键信赖,特别是概念了级联的外键。因为外键约束,多主情形下,外键的级联操作会形成不能够确诊的争持难题,所以建议使用group_replication_enforce_update_everywhere_checks=ON来消除不行发掘的冲突难题。

七.    大事务,因为事情太大,会产生无法在成员间5分钟内复制完,那么就能够生出错误。

17.5 Group Replication安全性

17.9.6 可见性

https://dev.mysql.com/doc/refman/5.7/en/group-replication-observability.html

17.二.一.2 为三个实例配置Group Replication

布置服务的基本配置:

[mysqld]

 

# server configuration

datadir=<full_path_to_data>/data/s1

basedir=<full_path_to_bin>/mysql-5.7/

 

port=24801

socket=<full_path_to_sock_dir>/s1.sock

安排复制相关,并运转GTID

server_id=1

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW

Group Replication配置

transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name=”aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= “127.0.0.1:24901”

loose-group_replication_group_seeds= “127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”

loose-group_replication_bootstrap_group= off

先是行:全体的写入的作业的write set使用XXHASH6四进行编码。

第二行:要到场的group的名字

其三行:服务运行后,不自行运行

第五行:使用127.0.0.一,端口为24901,来接入group成员的连日。

第四行:当进入四个group时,须求连接的host,只需求连接二个,然后该阶段会供给group重新配置,允许服务器进入到group。当八个服务相同的时间需要参预group,保险用的seed已经在group 中。

第4行:插件是还是不是涉嫌到group,这些参数很重大,必须只有3个劳动使用,不然晤面世主差异的图景,正是分化的group有1致的Group名字。第二个服务实例online之后就剥夺这些选项。

17.3.5 Group Replication Server States

表replication_group_members在view爆发变化的时候就能够修改,比方group的配备动态变化。假使出现互连网分离,或许服务离开group,信息就能够被告知,依照不通的劳动得到的音信闭塞。注意假设服务离开了group,那么就十分小概得到任何服务的音讯。如若产生疏离,举例quorum丢失,服务就不可能相互进行共同。也正是说会报告unreachable而不会一个万1状态。

Field

Description

Group Synchronized

ONLINE

服务online能够提供全套劳动

Yes

RECOVERING

分子正在复苏,之后会形成online黄台

No

OFFLINE

插件已经安装,不过成员不属于其余group

No

ERROR

在recovery阶段或许利用修改的时候,出现谬误

No

UNREACHABLE

不当排查狐疑服务无法连接。

No

 

一柒.二.一 Group Replication陈设单主方式

种种实例能够运营在单个机器上,能够在同叁个机械上。

图片 29

17.2.1.1 部署Group Replication实例

首先步不是四个实例。Group Replication是MySQL内部的插件,MySQL ⑤.七.17事后版本都起初有。

mkdir data

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s1

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s2

mysql-5.7/bin/mysqld –initialize-insecure –basedir=$PWD/mysql-5.7 –datadir=$PWD/data/s3

17.5.9.1 Group Replication基础

Group Replication布满式recovery进度,用来同步joiner和donor之间的数码。差不多分为三个步骤:

阶段1

其一品级joiner选用3个group中的成员作为donor,然后donor把joiner未有的数量同步给joiner,这些合伙是异步的。主借使通过binary log实行共同数据。

在binary log同步的时候,joiner会缓存group沟通的事体。当从donor的binary log运转完现在,进入第贰品级

阶段2

这么些等第joiner,应用以前缓存起来的事务,应用实现今后,定义为online

Resilience

在品级1,Recovery进程遇到donor出现谬误的时候,会切换来别的三个新的donor。

17.2.1.4 执行Group Replication

弄完上边的配置,并且运维后,连接受服务,试行一下发令:

INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;

设置好之后方可经过show plugins查看,假使设置成功就能在回去中。

初阶group,让s一涉及group并且运转Group Replication。这几个涉及要单个服务器实现,并且不得不运营贰次。所以那个布局不能够保存在配备文件中,假设保留了,下一次运维会自动关联到第四个Group,并且名字是一样的。若是按键plugin,不过参数是ON的也许有其一标题。

SET GLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

SET GLOBAL group_replication_bootstrap_group=OFF;

倘使start完毕,就足以查到成员了:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+—————+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |

+—————————+————————————–+————-+————-+—————+

| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost      |      
24801 | ONLINE        |

+—————————+————————————–+————-+————-+—————+

1 row in set (0,00 sec)

日增一些数目:

mysql> CREATE DATABASE test;

Query OK, 1 row affected (0,00 sec)

 

mysql> use test

Database changed

mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);

Query OK, 0 rows affected (0,00 sec)

 

mysql> INSERT INTO t1 VALUES (1, ‘Luis’);

Query OK, 1 row affected (0,01 sec)

壹七.九.伍.肆 使用提出和布满式Recovery的限量

布满式Recovery有局地范围,正是因为是基于异步复制的,由此即使当使用较老的备份或许镜像来做新的分子,就能招致阶段壹的岁月会相当长。因而提议选用较新的备份和镜像,减弱阶段一的时间。

17.5.9.1 Group Replication基础

Group Replication布满式recovery进度,用来同步joiner和donor之间的数量。大致分为一个步骤:

阶段1

以此阶段joiner选拔1个group中的成员作为donor,然后donor把joiner未有的多寡同步给joiner,这些合伙是异步的。首如果经过binary log进行联合数据。

在binary log同步的时候,joiner会缓存group交流的事情。当从donor的binary log运转完之后,进入第二阶段

阶段2

其1阶段joiner,应用以前缓存起来的作业,应用完毕之后,定义为online

Resilience

在品级壹,Recovery进程境遇donor出现错误的时候,会切换来别的多少个新的donor。

17.3.3 Replication_connection_status

Field

Description

Channel_name

通道名

Group_name

Group名

Source_UUID

Group的标识

Service_state

翻开服务是不是是group成员{ON, OFF
and CONNECTING};

Received_transaction_set

早就被该成员接受的gtid集

17.9.3 Data Manipulation Statements

在多主下,任何劳动都得以插入数据,任何服务在未有谐和下都足以运作工作,可是专门的学业提交需求服务谐和并调控工作去留。

协和的目标:

1.    检查事务是不是应该被提交

二.    传播职业到其它服务并且利用

职业传播是原子性的,要不全部经受,要不全部不接受。若接受就能够以一样的一1接受业务。冲突开掘是经过比较和反省作业的写入集实现。纵然出现争辨消除方式是保留第多少个提交的工作。

17.7.2 Group Replication限制

Group Replication有如此一些限制:

1.    replication event checksum,因为涉及的主题素材,group replication不可能选取event checksum

二.    gap lock,核准进度不行使gap lock,因为手艺越来越好的反省争辩难题。

三.    表锁和命名锁,核查进度不利用表锁和命名锁。

四.    SESportageIALIZABLE隔开分离等第,在多主group
replication默许是不援救的,借使设置了就能够不让提交。

五.    并发DDL和DML,多主DDL和DML在分裂服务器出现是不帮忙的。那样不一样服务奉行同样object的DDL和DML会挑起顶牛。

6.    外键和级联,多主格局下不帮助多品级的外键重视,特别是概念了级联的外键。因为外键约束,多主情状下,外键的级联操作会形成无法确诊的争辨难题,所以提出利用group_replication_enforce_update_everywhere_checks=ON来化解不行发掘的争执难题。

7.    大事务,因为事情太大,会导致不能在成员间5分钟内复制完,那么就能发生错误。

17.4.3.2 Unblocking a Partition

Group Replication能够强制成员配置来重新载入参数。一下情景只有S一,S二,就能够强制成员列表,通过设置变量group_replication_force_members变量。

图片 30

假诺S一,S贰存活,别的都非预期退出group,想要强制成员唯有S1,S二。

率先查看S一上的成员列表:

mysql> SELECT * FROM performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |      
13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |      
13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |      
13004 | UNREACHABLE  |

+—————————+————————————–+————-+————-+————–+

5 rows in set (0,00 sec)

然后从S1,S2中获取@@group_replication_local_address,然后设置到变量中

mysql> SELECT @@group_replication_local_address;

+———————————–+

| @@group_replication_local_address |

+———————————–+

| 127.0.0.1:10000                   |

+———————————–+

1 row in set (0,00 sec)

mysql> SELECT @@group_replication_local_address;

+———————————–+

| @@group_replication_local_address |

+———————————–+

| 127.0.0.1:10001                   |

+———————————–+

1 row in set (0,00 sec)

mysql> SET GLOBAL group_replication_force_members=”127.0.0.1:10000,127.0.0.1:10001″;

Query OK, 0 rows affected (7,13 sec)

检查members

mysql> select * from performance_schema.replication_group_members;

+—————————+————————————–+————-+————-+————–+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+—————————+————————————–+————-+————-+————–+

| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1   |      
13000 | ONLINE       |

| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1   |      
13001 | ONLINE       |

+—————————+————————————–+————-+————-+————–+

2 rows in set (0,00 sec)

当强制三个新的分子配置,要确认保证别的服务是甘休了。在地方中S三,S4,S5假如不是真的unreachable其实是online的,那么他们友善就能已造成二个效应分区。那样强制成员恐怕会促成主分隔的动静。由此保证其余服务是关闭的很要紧,即使未有,那么就手工业关闭他们。

17.4 Group Replication操作

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图