先配置好主从
配置主从详见上一篇博客，这里只是简单过一边
mysql> grant replication slave on *.* to 'haha'@'172.25.53.%' identified by 'YaoJing...123@';
Query OK, 0 rows affected, 1 warning (0.00 sec)
Server2链接server1
mysql> change master to master_host='172.25.53.1',master_user='haha',master_password='YaoJing...123@', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.30 sec)
```
<div class="se-preview-section-delimiter"></div>
然后更改server2配置文件并重启mysql
server-id=2
log-bin=mysql-bin
log-slave-updates
gtid_mode=ON
enforce_gtid_consistency=ON
“`
然后更改server2配置文件并重启mysql
server-id=2
log-bin=mysql-bin
log-slave-updates
gtid_mode=ON
enforce_gtid_consistency=ON
Server2发布
mysql> grant replication slave on *.* to 'haha'@'172.25.53.%' identified by 'YaoJing...123@';
Query OK, 0 rows affected, 1 warning (0.07 sec)
Server3链接server2
mysql> change master to master_host='172.25.53.2',master_user='haha',master_password='YaoJing...123@', MASTER_AUTO_POSITION=1;
测试
在server1中新建一个库
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.06 sec)
mysql> create database test;
Query OK, 1 row affected (0.08 sec)
mysql> use test;
Database changed
mysql> create table userlist(
-> username varchar(15) not null,
-> password varchar(25) not null);
Query OK, 0 rows affected (0.42 sec)
mysql> desc userlist;
+----------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| username | varchar(15) | NO | | NULL | |
| password | varchar(25) | NO | | NULL | |
+----------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
mysql> insert into userlist values ('user1','111');
Query OK, 1 row affected (0.65 sec)
mysql> insert into userlist values ('user2','222');
Query OK, 1 row affected (0.08 sec)
mysql> insert into userlist values ('user3','333');
Query OK, 1 row affected (0.17 sec)
Server2可以显示
Server3也可以显示
[root@server2 ~]# vim /etc/my.cnf
扫描二维码关注公众号，回复：
2755046 查看本文章
root@server2 ~]# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
准备工作做好，接下来就是半同步了
从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念
异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步复制原理图
半同步复制的潜在问题
客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种
事务还没发送到从库上
此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。
事务已经发送到从库上
此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。
无数据丢失的半同步复制
针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。
针对上面这个图，“Waiting Slave dump”被调整到“Storage Commit”之前。
当然，之前的半同步方案同样支持，MySQL 5.7.2引入了一个新的参数进行控制-rpl_semi_sync_master_wait_point
rpl_semi_sync_master_wait_point有两种取值
AFTER_SYNC
这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。
AFTER_COMMIT
老的半同步方案，如图所示。半同步复制的安装部署
要想使用半同步复制，必须满足以下几个条件：
MySQL 5.5及以上版本
变量have_dynamic_loading为YES
异步复制已经存在
Server1 master
Server2 master slave
Server3 slave
首先安装所需模块，并允许自启
启动半同步复制
在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步
主：
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
从：
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
以上的启动方式是在命令行操作，也可写在配置文件中。
Server1 安装master模块
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.10 sec)
mysql> set global rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
Server2安装master模块和slave模块
mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.11 sec)
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.06 sec)
mysql> set global rpl_semi_sync_slave_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
mysql> set global rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
Server3 安装slave模块
mysql> select plugin_name, plugin_status
-> from information_schema.plugins
-> where plugin_name like '%semi%';
重启io接口使生效
mysql> stop slave io_thread;
Query OK, 0 rows affected (0.08 sec)
mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)
Server1显示如下
mysql> show variables like 'rpl_semi_sync%';
Server2显示如下
mysql> show variables like ‘rpl_semi_sync%’;
mysql> show status like ‘Rpl_semi_sync%’;
Server3显示如下
插入
mysql> use test
Database changed
mysql> insert into userlist values ('user4','444');
Query OK, 1 row affected (0.08 sec)
mysql> insert into userlist values ('user5','555');
Query OK, 1 row affected (0.12 sec)
有几个状态改变了
Server3可显示同步的数据
事实上，半同步复制并不是严格意义上的半同步复制
当半同步复制发生超时时（由rpl_semi_sync_master_timeout参数控制，单位是毫秒，默认为10000，即10s），会暂时关闭半同步复制，转而使用异步复制。当master dump线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为半同步复制。
关掉server2的io接口，server1创建会有十秒的延迟（默认10s）
没有io接口，数据库肯定不会同步
打开了就同步了
总结
在一主多从的架构中，如果要开启半同步复制，并不要求所有的从都是半同步复制。
MySQL 5.7极大的提升了半同步复制的性能。
5.6版本的半同步复制，dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS 。
5.7版本的半同步复制中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。
Group Replication Background（组复制技术原理）
创建容错系统的最常见方法是使组件冗余，换句话说，部分组件可以删除，系统应该继续按预期运行。这产生了一系列挑战，将这种系统的复杂性提高到一个完全不同的水平。具体来说，复制的数据库必须处理这样的情况，即它们需要维护和管理几个服务器而不是一个。此外，由于多个服务器组成了一个“组”的概念来相互协同工作，必须处理几个其他经典分布式系统问题，诸如网络划分或裂脑情况。
因此，最终的挑战是将数据库的逻辑和多个实例之间的数据复制，以一致和简单的方式融合好。换句话说，使多个服务器同意系统的状态和系统经历的每个改变的数据。这可以被概括为使所有服务器在每个数据库实例状态转换上达成一致，使得它们都作为一个单个数据库能否正常运行或者它们最终收敛到相同状态。意味着整个集群下的每个节点需要作为一个（分布式）状态机操作。
MySQL组复制提供分布式状态机复制，在服务器之间具有强协调。当数据库服务器是属于同一组时，组复制机制可以自动协调它们。该组可以在具有自动选择新主库功能的单主模式下操作，这种情况下一个组只有主节点才可以做写操作。或者，对于更高级的用户，该组可以以多主模式部署，即多个节点都可以做写操作，即使它们是同时发过来的写请求。不过这种情况下，应用层会有部分额外的限制。
有一个内置的组成员服务称为group membership service，用以确保在任何给定的时间点该组的可用性和一致性的视图。各个节点可以脱离和加入该组，并相应地更新该视图。有时，组成员可能会意外脱离组，在这种情况下，故障检测机制会检测到此情况，并通知组视图已更改。以上这些都是自动的。
一个事务要提交时，必须通过查看它在全局事务序列中的顺序，并在得到大多数组成员同意的情况下按照该顺序提交。决定提交或废弃一个已经执行过的事务是由每个成员单独完成的，但所有成员必须做出相同的决定。假设这种情况，存在一个存在网络分区，导致成员无法达成协议的分割，则系统将不会进行，直到此问题解决。因此，还有一个内置的，自动的，裂脑保护机制。
所有上述功能都由组通信协议实现。它提供了故障检测机制failure detection mechanism，组成员服务group membership service以及安全和完全有序的消息传递。所有这些属性是保证创建出来的系统在多个节点之间进行复制时的数据一致性的关键。该技术的核心是Paxos算法的实现，它充当群组通信系统引擎。
ReplicationTechnologies（复制技术对比）
Primary-Secondary Replication（传统主从复制）
传统的MySQL复制提供了一种简单的主 – 从复制架构。它有一个primary节点（master节点）和一个或多个secondary节点（slave节点）。主节点执行写操作，然后将该写操作稍后（因此异步地）发送到从节点，从节点重新执行该SQL（在基于语句的复制中）或应用该操作影响的结果行（在基于行的复制中）。它是一个shared-nothing系统，默认情况下所有节点都有一个完整的数据副本。
还有一个半同步复制，它向异步复制协议添加一个同步步骤。这意味着主节点在提交时等待从节点ACK确认它已经接收到事务。只有这样，主节点才恢复提交操作。
在上面的两个图片中，您可以看到经典异步MySQL复制协议（以及它的半同步变体）的图。蓝色箭头表示在数据节点之间交换的消息或者在服务器和客户端应用之间交换的消息。
Group Replication（组复制）
组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的服务器组。通信层提供了很多保证，例如原子消息和总消息序号的传递。通过这些强大的特性，我们可以构建更高级的数据库复制解决方案。
MySQL组复制构建在这些属性和抽象之上，并实现多主复制协议的更新。实质上，复制组由多个数据库实例组成，并且组中的每个实例都可以独立地执行事务。但是所有读写（RW）事务只有在被组批准后才会提交。只读（RO）事务不需要在组内协调，因此立即提交。换句话说，对于任何RW事务，组需要决定是否提交，因此提交操作不是来自始发服务器的单向决定。准确地说，当事务准备好在始发服务器上提交时，该始发服务器原子地广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后为该事务建立一个全局总序号。最终，这意味着所有服务器以相同的顺序接收同一组事务。因此，所有服务器以相同的顺序应用相同的一组更改，因此它们在组内保持一致。
但是，在不同服务器上并发执行的事务之间可能存在冲突。通过检查两个不同的并发事务的写集合来检测这样的冲突，这个检查过程称为认证（certification）。如果在不同的服务器上执行的两个并发事务更新同一行，则会出现冲突。解析过程会这么做，首先发起的事务在所有服务器上提交，而后发起的事务将在源服务器上回滚，并由组中的其他服务器删除。这实际上是一个分布式环境下“优先提交者赢”的规则。
最后，组复制是一种无共享复制方案（shared_nothing），即每个服务器都有自己的整个数据副本。 上图描述了MySQL组复制协议，并通过将其与MySQL复制（或甚至MySQL半同步复制）进行比较，您可以看到一些差异。注意，为了清楚起见，这个图片中缺少一些基本的共识和Paxos相关信息。
Group ReplicationUse Cases（组复制应用场景）
组复制使您能够通过在一组服务器中复制系统状态来创建具有冗余的容错系统。因此，即使一些服务器发生故障，只要它不是全部或大多数，虽然可能降低系统性能或可扩展性，但系统仍然可用。单一服务器故障是隔离和独立的。它们由group membership service跟踪，它依赖于分布式故障检测器，分布式故障检测器能够在任何节点成员自愿地或由于意外停止而离开群组时发出信号。分布式恢复过程能够确保当有新节点加入组时，该节点会自动更新到最新。Multi-master特性确保即使在单个服务器故障的情况下也不会阻止更新。因此，MySQL组复制保证数据库服务持续可用。
不过需要重点理解，尽管组复制存在高可用，但连接到它的客户端必须被重定向或故障转移到不同的服务器。这不是组复制尝试解决的问题，而是连接器，负载均衡器，路由器或一些其他中间件更适合处理这个问题。
总而言之，MySQL组复制提供了高可用性，高弹性，可靠的MySQL服务。
Examples of Use Case Scenarios（应用案例）
·弹性复制 - 需要非常流畅的复制基础架构的环境，其中服务器的数量必须动态增长或收缩，尽可能减少副作用。例如，云的数据库服务。
·高可用分片 - 分片是实现写扩展的常用方法。使用MySQL组复制实现高可用性分片，其中每个分片映射到复制组。
·替代主从复制 - 在某些情况下，使用单一主节点可能使其成为单点争用。在某些情况下，写入整个组可能更具可扩展性。
·自动化系统 - 可以将MySQL组复制当做一个纯粹的自动化复制系统
Group ReplicationDetails（组复制详解）
Failure Detection（失败检测）
组复制提供了一种故障检测机制，其能够找到和报告哪些服务器是没有响应的，并假定其是死的。更深入地说，故障检测器是提供关于哪些服务器可能已死的信息的分布式服务。后续如果组同意怀疑可能是真的，则由组来决定该服务器确实已经失败。这意味着组中的其余成员进行协调决定排除给定成员。
服务器无响应时触发怀疑机制。当服务器A在给定时间段内没有从服务器B接收消息时，发生超时就会引起怀疑。
如果服务器与组的其余部分隔离，则它怀疑所有其他服务器都失败。由于无法与组达成协议（因为它无法获得大多数成员认可），因此其怀疑没有后果。当服务器以此方式与组隔离时，它无法执行任何本地事务。
Group Membership(组成员服务)
MySQL组复制依赖于组成员服务group membership service。这是内置的插件。它定义哪些服务器是在线的并参与在复制组中。在线服务器列表通常称为视图view。因此，组中的每个服务器具有一致的视图，其是在给定时刻积极参与到组中的成员。
复制组的成员们不仅需要同意事务是否提交，而且也需要决定当前视图。因此，如果服务器同意新的服务器成为组的一部分，则该组本身被重新配置以将该服务器集成在其中，从而触发视图改变。相反的情况也发生，如果服务器自愿地离开组，则该组动态地重新布置其配置，并且触发视图改变。
请注意，当成员自愿离开时，它首先启动动态组重新配置。这触发一个过程，所有成员必须同意新的视图（也就是新视图中没有该离开成员）。然而，如果成员不由自主地离开（例如它已意外停止或网络连接断开），则故障检测机制实现这一事实，并且提出该组的重新配置（新视图没有该离开成员）。如上所述，这需要来自组中大多数成员的同意。如果组不能够达成一致（例如，以不存在大多数服务器在线的方式进行分区），则系统不能动态地改变配置，从而阻止脑裂情况引起的多写。最终，这意味着管理员需要介入并解决这个问题。
Fault-tolerance（容错机制）
MySQL组复制构建在Paxos分布式算法的实现上，以提供服务器之间的分布式协调。因此，它需要大多数服务器处于活动状态以达到选举条件，从而做出决定。这对系统可以容忍的故障数量有直接影响，一个组复制中成员数量设置（n）为n = 2×f + 1。
在实践中，这意味着为了容忍一个故障，组必须有三个服务器。因此，如果一个服务器故障，仍然有两个服务器形成大多数（三分之二）并且允许系统自动地继续运行。但是，如果第二个服务器也异常失败，则该组（剩下一个服务器）阻塞，因为没有多数可以做出决定。https://www.actionsky.com/mysql-57-semi-sync-intro/
组复制 全同步机制
[root@server1 ~]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[root@server1 ~]# cd /var/lib/mysql
[root@server1 mysql]# pwd
/var/lib/mysql
[root@server1 mysql]# ls
auto.cnf mysql
ib_buffer_pool mysql-bin.000001
ibdata1 mysql-bin.index
ib_logfile0 performance_schema
ib_logfile1 sys
install-validate-password-plugin.x6qV01.sql test
[root@server1 mysql]# rm -rf *
[root@server1 mysql]# ls
[root@server1 mysql]# vim /etc/my.cnf
[root@server1 mysql]# /etc/init.d/mysqld start
Initializing MySQL database: [ OK ]
Starting mysqld: [ OK ]
[root@server1 mysql]# vim /etc/my.cnf
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
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="f4cfe0a0-9c7b-11e8-a10c-52540057d97e"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "172.25.53.1:24901"
loose-group_replication_group_seeds= "172.25.53.1:24901,172.25.53.2:24901,172.25.53.3:24901"
loose-group_replication_bootstrap_group=off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=on
loose-group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8"
[root@server1 mysql]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[root@server1 mysql]# /etc/init.d/mysqld start
Starting mysqld: [ OK ]
[root@server1 mysql]# grep password /var/log/mysqld.log
若是密码登不上去，清除日志后重复上述动作
> /var/log/mysqld.log
最好按照官方文档做
https://dev.mysql.com/doc/refman/5.7/en/group-replication-launching.html
首先进入更改密码
mysql> alter user root@localhost identified by 'YaoJing...123@'
-> ;
Query OK, 0 rows affected (0.06 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'YaoJing...123@';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)
mysql> reset master;
Query OK, 0 rows affected (0.28 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='YaoJing...123@' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.68 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.30 sec)
mysql> SHOW PLUGINS;
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> 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.
mysql> quit
Bye
查看日志
2018-08-10T09:44:51.280790Z 0 [Warning] Plugin group_replication reported: '[GCS] Connection attempt from IP address 172.25.53.1 refused. Address is not in the IP whitelist.'
经检查是由于粗心将配置文件白名单ip打错
更改后由于配置文件本次已经读取，我们在mysql里面也作更改
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> stop GROUP_REPLICATION;
Query OK, 0 rows affected (0.00 sec)
mysql> set global group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8";
Query OK, 0 rows affected (0.00 sec)
mysql> start GROUP_REPLICATION;
Query OK, 0 rows affected (1.44 sec)
可以正常启动了
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.00 sec)
mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.09 sec)
mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
Query OK, 0 rows affected (0.62 sec)
mysql> INSERT INTO t1 VALUES (1, 'Luis');
Query OK, 1 row affected (0.12 sec)
mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)
Server2
[root@server2 mysql]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[root@server2 mysql]# > /var/log/mysqld.log
[root@server2 mysql]# rm -rf *
[root@server2 mysql]# /etc/init.d/mysqld start
Initializing MySQL database: [ OK ]
Installing validate password plugin: [ OK ]
Starting mysqld: [ OK ]
[root@server2 mysql]# grep password /var/log/mysqld.log
[root@server2 ~]# vim /etc/my.cnf
server_id=2
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
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="f4cfe0a0-9c7b-11e8-a10c-52540057d97e"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "172.25.53.2:24901"
loose-group_replication_group_seeds= "172.25.53.1:24901,172.25.53.2:24901,172.25.53.3:24901"
loose-group_replication_bootstrap_group=off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=on
loose-group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8"
mysql> show databases;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
mysql> alter user root@localhost identified by 'YaoJing...123@';
Query OK, 0 rows affected (0.05 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'YaoJing...123@';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> reset master;
Query OK, 0 rows affected (0.31 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='YaoJing...123@' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.59 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.28 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (6.37 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
| group_replication_applier | 37569825-9c85-11e8-ab5e-525400178366 | server2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1 |
+----------------+
1 row in set (0.00 sec)
mysql> select * from t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)
Server3与server2相同，不同之处是配置文件
mysql> alter user root@localhost identified by 'YaoJing...123@';
Query OK, 0 rows affected (0.07 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'YaoJing...123@';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> reset master;
Query OK, 0 rows affected (0.23 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='YaoJing...123@' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.80 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.14 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.13 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
| group_replication_applier | 37569825-9c85-11e8-ab5e-525400178366 | server2 | 3306 | ONLINE |
| group_replication_applier | a810ff44-9c86-11e8-acaf-52540057d97e | server3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)
我们试着在server3里建立数据
在其他两个库都可以看见
