mysql组复制（MGR）——部署

最新推荐文章于 2024-07-21 02:09:51 发布

原始寒冰菇1444

最新推荐文章于 2024-07-21 02:09:51 发布

点赞数

文章标签： mysql adb android 数据库

mysql组复制作为插件提供给mysql服务器，组内的每个服务器都要求配置和安装该插件。本文提供创建一个至少3个服务器的复制组所需的详细步骤。
一.部署单主模式的组复制
组内的每个服务器实例能运行在独立或同一台机器上。该部分讲解如何用同一台物理机上的三个mysql服务器实例来创建一个复制组。这意味着需要3个数据目录，每个服务器实例一个，且需要对每个实例进行独立的配置。
图1-1 组架构

mysql组复制（MGR）——部署_repli

本文讲解如何得到和部署已安装组复制插件的mysql服务器，如何在创建一个组前配置每个服务器实例，以及如何使用性能模式监视确认一切都工作正常。
1.部署组复制实例
第1步是部署3个mysql服务器实例。组复制是mysql服务器5.7.17以上版本内建的mysql插件。本过程假设mysql服务器被下载和解压到名字为mysql-5.7的目录。下列过程用一个物理机，所以，每个mysql服务器实例需要一个特定数据目录。在名字为data的目录下创建数据目录并对其进行初始化。
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
--注：
1）上述$PWD为环境变量，其指向linux的当前目录。
2）生产环境中不要用--initialize-insecure，这里使用仅出于简化。
2.配置组复制实例
该部分对用于组复制的mysql服务器实例所需配置进行讲解。
1）组复制服务器设置
为了安装和使用组复制插件，您必须正确配置mysql服务器实例。推荐将该配置存储于实例的配置文件。除非另有说明，下述是组内第1个实例的配置，该过程中称为s1。下面将展示1个服务器配置实例。

[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
这些配置mysql服务器使用较早创建的数据目录和打开和监听进入连接的端口。
--注：
1）使用非默认的24801端口，是因为本文3个服务器实例使用同一主机。3个不同主机的配置中，无需这样配置。
组复制依赖于成员间的网络连接，其意味着每个成员必须能解析所有其他成员的网络地址。例如：本文中所有3个实例都运行在1台物理机上，因此，为了确保成员能互相联系，您能往选项文件中添加类似report_host=127.0.0.1的一行。
2）复制框架
下面根据mysql组复制需求配置复制。
server_id=1
gtid_mode=ON
2963
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
这些配置该服务器使用唯一鉴定符号为1，其开启了全局事务鉴定符并在系统表而非文件中存储复制元数据。此外，其指示该服务器打开二进制日志，用基于行的格式并禁用二进制日志事件校验。
3）组复制设置
此时，my.cnf文件确保服务器被配置并被指示按照指定配置对复制基础架构进行实例化。下述部分为该服务器配置组复制设置。
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
--注：
1）用于上述组复制变量的loose-前缀指示如果组复制插件在服务器启动时未被加载，则服务器继续启动。
2）配置transaction_write_set_extraction指示服务器必须收集每个事务的写集并通过哈希算法对其进行编码。
3）配置group_replication_group_name告诉该插件正加入或创建的组命名为"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"。group_replication_group_name值必须为有效UUID。设置二进制中组复制事件的GTID时，该UUID被内部使用。
4）配置group_replication_start_on_boot指示该插件服务器启动时不要自动开启。因为需要确保手工启动该插件前您能配置该服务器，所以，安装组复制时这点很重要。一旦成员被配置，您能设置group_replication_start_on_boot为on，以便组复制在服务器启动时自动开启。
5）配置group_replication_local_address告诉该插件使用网络地址127.0.0.1和端口24901与组内其他成员进行内部通信。重要的是，组复制将该地址通过XCom用于内部成员间连接。该地址一定不要与SQL使用的
hostname和port相同，并且一定不要用于客户端应用。其必须被保留用于运行组复制时组成员间的内部通信。
group_replication_local_address配置的网络地址必须对所有组成员是可解析的。例如：如果每个服务器实例在配置了固定网络地址的不同服务器上，您能使用该机器的IP地址，像：10.0.0.1。如果您使用hostname，那么，您必须使用全限定名，并确保其可以通过DNS解析，正确配置/etc/hosts文件，或其他名字解析过程。group_replication_local_address的推荐端口为33061。本文中，我们在一台机器上运行3个服务器实例，这样，端口24901到24903用作内部通信的网络地址。
6）配置group_replication_group_seeds设置组成员的hostname和port，其用于新成员建立到该组的连接。这些成员称为种子成员。一旦建立连接，组成员信息在performance_schema.replication_group_members中列出。通常，group_replication_group_seeds列表包含每个组成员group_replication_local_address的hostname:port，但这不是必须的，可以选择部分组成员作为种子。重要的是group_replication_group_seeds中列出的hostname:port是group_replication_local_address配置的种子成员的内部网络地址，而非用于客户端连接的SQL的hostname:port，其被performance_schema.replication_group_members表显示。
启动该组的服务器并不适用该选项，由于其为最初服务器，因此，其负责该组的启动。换句话说，负责启动组服务器上的任何已有数据将用作下一个新加入成员的数据。第2个加入的服务器加入时会询问组内仅有的该服务器，第2台服务器上丢失的任何数据将会从该启动成员的捐赠数据复制，于是，该组得以扩展。第3个加入的服务器加入时询问已有两个服务器中的任何一个，数据被同步到新成员，接着组再次得以扩展。随后的服务器加入时重复该过程。
需要注意的是，当同时加入多个服务器时，确信它们都指向组中已有的种子成员。不要使用也正在加入组的成员做种子，因为当接触时它们也许还没在组中。
先启动自启成员并让其创建组是个好实践。接着，以它作为其他正加入成员的种子成员。这确保其他成员加入时有一个已形成的组。同时创建一个组并加入多个成员不被支持。这也许会工作，但很可能是操作竞争，接着，组会以报错或超时而结束。
7）配置group_replication_bootstrap_group指示插件是否启动组。
重要的是，任何时候该选项必须仅用于一个服务器实例，通常，第1次启动组时（或者整个组被关闭再启动的场景）。如果你多次启动组，例如：当以单主模式部署组复制时，多个服务器实例设置了该选项，那么，它们可能会创建一个人工脑裂场景，其中，存在两个同样名字的不同组。第1个服务器实例上线后就禁用该选项。组中所有服务器的配置是很类似的。您需要改变每个服务器的特定细节（例如：server_id，datadir，group_replication_local_address）。
3.用户认证
组复制使用异步复制协议完成新加入组成员的同步。分布式恢复处理依赖于称为group_replication_recovery 的复制通道，其用于将事务从捐赠者成员传输到加入组的新成员。因此，需要设置正确权限的复制用户，以便组复制能建立直接成员对成员的恢复复制通道。
用如下选项文件启动服务器：
mysql-5.7/bin/mysqld --defaults-file=data/s1/s1.cnf
以REPLICATION-SLAVE权限创建mysql用户。该过程能在二进制日志中捕获，接着，您能依靠分布式恢复来复制这些用于创建用户的语句。或者，您能禁用二进制日志并接着手工在每个成员上创建该用户，例如：如果您想避免改变传播到其他服务器实例。为了禁用二进制日志，连接到s1服务器并发布如下语句：
mysql> SET SQL_LOG_BIN=0;
下述例子中，显示用户和密码分别为rpl_user和password。当配置您的服务器时，使用合适的用户名和密码。一旦用户被创建，开启二进制日志。
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;
一旦用户被配置，使用CHANGE MASTER TO语句配置服务器，以便下次需要从另一个成员恢复期状态时，group_replication_recovery复制通道使用指定的认证。发布下述命令，用创建用户时的值替换其中rpl_user和密码。
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
分布式恢复只是假如组的服务器采取的第1步，其并没有组成员一样的事务集。如果像显示的rpl_user那样，group_replication_recovery replication channel的这些认证没有正确设置，该服务器不能连接到捐赠成员
并运行分布式恢复进程来获取与其他组成员的同步，最终将不能加入该组。
类似地，如果服务器不能通过服务器的hostname正确确定其他成员，复制进程则失败。推荐运行mysql的操作系统已通过DNS或本地设置正确配置了唯一hostname。可以通过performance_schema.replication_group_members表确认该hostname。如果多个组成员通过操作系统外化（externalize）了默认hostname设置，则有可能解析不到正确的成员地址，且不能加入该组。这种情况下，使用report_host来配置唯一hostname来外化每个服务器。
4.启动组复制
一旦服务器s1已配置和启动，安装组复制插件。连到该服务器并发布下述命令：
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
--注：
1）加载组复制前，mysql.session用户必须存在。mysql.session在mysql5.7.19中引入。如果数据字典是用较早版本初始化，那么，您必须运行mysql_upgrade过程。如果不进行该升级，组复制失败并报出如下错误信息：
There was an error when trying to access the server with user: mysql.session@localhost.Make sure the user is present in the server and that mysql_upgrade was ran after a server update..
为了检查该组件已成功安装，发布show plugins;并检查输出。其应该显示如下信息：
mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+-------------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+-------------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | PROPRIETARY |
(...)
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | PROPRIETARY |
+----------------------------+----------+--------------------+----------------------+-------------+
为了启动该组，指示服务器s1启动该组并接着启动组复制。该启动应该仅由单个服务器完成，该服务器为启动该组的服务器，且仅启动1次。这就是启动配置参数值不保存到配置文件中的原因。如果其被保存在配置文件中，重启该服务器会自动启动第2个同样名字的组。这将导致两个同样名字的不同组。同样的原因适用以该选项设置为ON来停止和重启该插件。
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
一旦start group_replication语句返回，该组已经被启动。您能检查该组现在被创建且其中有一个成员：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATEDeploying Group Replication in Single-Primary Mode
2967
+---------------------------+--------------------------------------+-------------+-------------+-----------
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost | 24801 | ONLINE
+---------------------------+--------------------------------------+-------------+-------------+-----------
该表中的信息确认唯一鉴定符为ce9be252-2b71-11e6-b8f4-00212844f856的组中有一个成员，其为在线状态，且在myhost的24801端口监听客户连接。
为了说明该服务器确实在该组中，且其能处理负载，创建一张表，并向其增加一些内容：
mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
mysql> INSERT INTO t1 VALUES (1, 'Luis');
Check the content of table t1 and the binary log.
mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+-----------------------------------------
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
+---------------+-----+----------------+-----------+-------------+-----------------------------------------
| binlog.000001 | 4 | Format_desc | 1 | 123 | Server ver: 5.7.19-gr080-log, Binlog ver
| binlog.000001 | 123 | Previous_gtids | 1 | 150 |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724817264259180:1
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIM
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-
| binlog.000001 | 831 | Query | 1 | 899 | BEGIN
| binlog.000001 | 899 | Table_map | 1 | 942 | table_id: 108 (test.t1)
| binlog.000001 | 942 | Write_rows | 1 | 984 | table_id: 108 flags: STMT_END_F
| binlog.000001 | 984 | Xid | 1 | 1011 | COMMIT /* xid=38 */
+---------------+-----+----------------+-----------+-------------+-----------------------------------------
如上所见，数据库和表对象已被创建，且其相应DDL语句被写入二进制日志。数据也被插入到该表中且写入二进制日志。
当组规模变大且由于新成员试图追赶和变为在线状态而执行分布式恢复时，二进制项的重要性在下述部分进行说明。
5.向组内添加实例
此时，组内已有一个成员，服务器s1，其中有一些数据。现在是时候通过添加先前配置的另两个服务器来扩展该组了。
1）添加第二个实例
为了添加第二个实例，服务器s2，首先为其创建配置文件。该配置与服务器s1的类似，除了类似数据目录位置，s2将监听的端口或其server_id等。这些不同的行将会在下列突出强调。

[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s2
basedir=<full_path_to_bin>/mysql-5.7/
port=24802
socket=<full_path_to_sock_dir>/s2.sock
#
# Replication configuration parameters
#
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
#
# Group Replication configuration
#
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:24902"
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
类似服务器s1的过程，配置文件已准备好，您可以启动该服务器了。
mysql-5.7/bin/mysqld --defaults-file=data/s2/s2.cnf
如下配置恢复认证。由于用户在组内共享，所以，命令与设置服务器s1时用的一样。在s2上发布如下语句：
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
安装组复制插件并开始将该服务器加入该组的过程。下列例子按照部署服务器s1时用的方式安装该插件。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
将服务器s2添加到该组。
mysql> START GROUP_REPLICATION;
不像先前s1上执行的步骤，这里有个不同的地方，那就是启动组复制前并不发布SET GLOBAL group_replication_bootstrap_group=ON;，因为该组已被创建并由s1启动。此时，服务器s2仅需添加到以存在的组中。
--注：
1）当组复制成功启动并该服务器加入组时，其检查super_read_only变量。通过在成员配置文件中将super_read_only设置为ON，您能确信启动组复制时因任何原因失败的服务器不会接受事务。如果该服务器作为读写实例加入该组，例如：作为单主组的主库或作为一个多主组成员加入，当变量super_read_only设置为ON时，那么，加入该组时其被设置为OFF。再次检查performance_schema.replication_group_members表显示现在组内有两个在线服务器。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+-----------
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STA
+---------------------------+--------------------------------------+-------------+-------------+-----------
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost | 24801 | ONLINE
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost | 24802 | ONLINE
+---------------------------+--------------------------------------+-------------+-------------+-----------
由于服务器s2也被标为ONLINE，其一定是已经自动追上了服务器s1。如下确认其确实已经与服务器s1同步。
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+----------------------------------------
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
+---------------+------+----------------+-----------+-------------+----------------------------------------
| binlog.000001 | 4 | Format_desc | 2 | 123 | Server ver: 5.7.17-log, Binlog ver: 4
| binlog.000001 | 123 | Previous_gtids | 2 | 150 |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRI
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1)
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=30 */
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGINDeploying Group Replication in Single-Primary Mode
2970
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT
+---------------+------+----------------+-----------+-------------+--------------------------------------------
如上所见，第2个服务器已经添加至该组，且其已经自动从服务器s1复制了改变。根据分布式恢复过程，这意味着仅在加入改组后和宣布在线前，服务器s2已经自动连到服务器s1，并从其获取了丢失的数据。换句话说，其从s1的二进制日志拷贝了其丢失的事务，知道其加入组的时间点。
2）添加另外的实例
向该组添加另外的实例实际与添加第2个服务器的步骤顺序相同，除了服务器s2特定的配置必须改变。需要的命令总结如下：
i）创建配置文件
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-5.7/
port=24803
socket=<full_path_to_sock_dir>/s3.sock
#
# Replication configuration parameters
#
server_id=3
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 configuration
#
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:24903"
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
ii）启动服务器
mysql-5.7/bin/mysqld --defaults-file=data/s3/s3.cnf
iii）配置group_replication_recovery通道的恢复认证
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
iv）安装组复制插件并启动
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;
此时，服务器s3启动和运行，已加入组并追上组内其他的服务器。查询performance_schema.replication_group_members表再次确认。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+-----------
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STA
+---------------------------+--------------------------------------+-------------+-------------+-----------
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost | 24801 | ONLINE
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | myhost | 24803 | ONLINE
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost | 24802 | ONLINE
+---------------------------+--------------------------------------+-------------+-------------+-----------
在服务器s2或s1上发布同样的查询产生同样的结果。您也能确认s3已经赶上：
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+----------------------------------------
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
+---------------+------+----------------+-----------+-------------+----------------------------------------
| binlog.000001 | 4 | Format_desc | 3 | 123 | Server ver: 5.7.17-log, Binlog ver: 4
| binlog.000001 | 123 | Previous_gtids | 3 | 150 |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRI
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1)
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=29 */
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT
| binlog.000001 | 1326 | Gtid | 1 | 1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaaMonitoring Group Replication
2972
| binlog.000001 | 1387 | Query | 1 | 1446 | BEGIN
| binlog.000001 | 1446 | View_change | 1 | 1585 | view_id=14724832985483517:3
| binlog.000001 | 1585 | Query | 1 | 1650 | COMMIT
+---------------+------+----------------+-----------+-------------+--------------------------------------------

原创作者: lhdzbj 转载于: https://blog.51cto.com/lhdzbj/11517786

原始寒冰菇1444

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
mysql组复制（MGR）——部署

mysql组复制作为插件提供给mysql服务器，组内的每个服务器都要求配置和安装该插件。本文提供创建一个至少3个服务器的复制组所需的详细步骤。一.部署单主模式的组复制组内的每个服务器实例能运行在独立或同一台机器上。该部分讲解如何用同一台物理机上的三个mysql服务器实例来创建一个复制组。这意味着需要3个数据目录，每个服...
复制链接

扫一扫