Deploying Group Replication in Single-Primary Mode
组中的每个服务器实例可以在独立的物理机器上运行，也可以在同一台机器上运行。本节介绍如何在一台物理机上创建具有三个MySQL Server实例的复制组。这意味着需要三个数据目录，每个MySQL Server实例占用一个，您需要独立配置每个实例。
本教程介绍如何使用组复制插件获取和部署MySQL Server，如何在创建组之前配置每个服务器实例以及如何使用性能模式监视来验证一切是否正常工作。
Deploying Instances forGroup Replication
第一步是部署MySQL服务器的三个实例。组复制是MySQL Server 5.7.17及更高版本提供的内置MySQL插件。有关MySQL插件的更多背景信息，请参见第6.5节“MySQL服务器插件”。一旦你下载了MySQL服务器包，解压缩它并安装二进制文件。此过程假定MySQL Server已下载并解压缩到当前目录，名为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
内部data / s1，data / s2，data / s3是一个初始化的数据目录，包含mysql系统数据库和相关表等。要了解有关初始化过程的更多信息，请参见第2.10.1.1节“使用mysqld手动初始化数据目录”。
警告
不要在生产环境中使用--initialize-insecure，它只用于简化教程。有关安全设置的更多信息，请参见第19.5节“组复制安全性”。
Configuring an Instancefor Group Replication
本节介绍要用于组复制的MySQL Server实例所需的设置。有关背景信息，请参见第19.7.2节“限制”。
Group Replication Server Settings
要安装和使用组复制插件，必须正确配置MySQL服务器实例。建议将配置存储在my.cnf文件中。有关详细信息，请参见第5.2.6节“使用选件文件”。除非另有说明，以下是组中第一个实例的配置，在此过程中称为s1。以下部分显示了示例服务器配置。
[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服务器配置为使用先前创建的数据目录以及服务器应打开哪个端口并开始侦听传入连接。
注意
使用非默认端口24801，因为在本教程中，三个服务器实例使用相同的主机名。在具有三个不同机器的设置中，这不是必需的。
Replication Framework
以下设置根据MySQL组复制要求配置复制。
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
这些设置将服务器配置为使用唯一标识号1，以启用全局事务标识符，并将复制元数据存储在系统表（而不是文件）中。此外，它指示服务器打开二进制日志记录，使用基于行的格式和禁用二进制日志事件校验和。有关更多详细信息，请参见第19.7.2节“限制”。
Group Replication Settings
此时，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
注意
用于上面group replication的变量的loose前缀指示服务器继续启动，如果在服务器启动时尚未加载组复制插件。
行1指示服务器对于每个事务它必须收集写集合(write set)并且使用XXHASH64散列算法将其编码为散列。
第2行告诉插件，它正在加入或创建的组名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。
第3行指示插件在服务器启动时不自动启动操作。
第4行告诉插件使用IP地址127.0.0.1或localhost，端口24901用于来自组中其他成员的传入连接。
重要
服务器在此端口上侦听成员到成员的连接。此端口不能用于用户应用程序，在运行组复制时，必须保留此端口用于组的不同成员之间的内部通信。
由group_replication_local_address配置的本地地址必须可供所有组成员访问。例如，如果每个服务器实例都位于不同的计算机上，则使用计算机的IP和端口，例如10.0.0.1:33061。 group_replication_local_address的推荐端口为33061，但在本教程中，我们使用在一台机器上运行的三个服务器实例，因此使用端口24901到24903。
第5行告诉插件，应该联系这些主机和端口上的以下成员，因为它需要加入组。这些是种子成员，当此成员想要连接到组时使用。即将加入组的成员会先跟这些种子种的一个联络，然后它要求组重新配置以允许在组中接受加入者。请注意，此选项不需要列出组中的所有成员，而只是新服务器加入时需要联系的服务器列表。
启动组的服务器不使用此选项，因为它是初始服务器，因此它负责引导组。第二个加入的服务器加入时只需询问其中一个节点和其他成员是否可以加入即可，这时组就扩大了。第三个服务器加入可以请求这两个加入，然后组再次扩展。后续服务器在加入时重复此过程。
警告
同时加入多个服务器时，请确保它们指向已在组中的种子成员。不要使用也加入群组作为种子的成员，因为他们可能在联系时尚未加入群组。优良做法是首先启动引导成员，并让它创建组。然后使其成为正在加入的其余成员的种子成员。这确保了有其他成员需要加入时，该组已经具有可用的组格式。不支持创建组并同时加入多个成员。它可能工作，但有可能导致操作竞争，从而导致加入组的行为最终出现错误或超时。
第6行指示插件是否要引导组。
重要
此选项只能在任何时候在一个服务器实例上使用，通常是首次引导组时（或在整个组被关闭并重新备份的情况下）。如果您多次引导组，例如，当多个服务器实例设置了此选项时，它们可能会创建一个人为裂脑情景，其中存在两个具有相同名称的不同组。在第一个服务器实例联机后禁用此选项。
组中的所有服务器的配置非常相似。您需要更改每个服务器的详细信息（例如server_id，datadir，group_replication_local_address）。这将在本教程的后面。
User Credentials
组复制依赖于异步复制协议，以便能够运行分布式恢复。因此，您需要设置一个复制用户，以便能够建立直接成员到成员恢复通道。
启动服务器：
mysql-5.7/bin/mysqld --defaults-file=data/s1/s1.cnf
禁用二进制日志记录，创建具有正确权限的用户，并保存组复制恢复通道的凭据。
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';
上面看到的最后一行配置此服务器使用给定凭据下次需要从另一个成员恢复其状态。分布式恢复是加入组的服务器执行的第一步。如果未正确设置这些凭据，则服务器无法运行恢复协议，并且最终无法加入组。
Launching GroupReplication
假设服务器s1已经按照上面的说明配置和启动，下一步是安装组复制插件。连接到服务器并发出以下命令：
INSTALL PLUGIN group_replication SONAME 'group_replication.so';要检查插件是否已成功安装，请发出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引导组，然后启动组复制。此引导应仅由单个服务器完成，该服务器启动组并且只启动一次。这就是为什么引导配置选项的值未保存在配置文件中的原因。如果将其保存在配置文件中，则在重新启动时，服务器会自动引导具有相同名称的第二个组。这将导致两个不同的组具有相同的名称。同样的推理适用于停止和重新启动插件。
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_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost | 24801 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
1 row in set (0,00 sec)
此表中的信息确认组中有唯一标识符ce9be252-2b71-11e6-b8f4-00212844f856的成员，它是在线并且在myhost侦听端口24801上的客户端连接。
为了演示服务器确实在一个组中，并且它能够处理加载，创建一个表并向其中添加一些内容。
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)
检查表t1和二进制日志的内容。
mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0,00 sec)
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.17-gr080-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 1 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| 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-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| 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 */ |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
15 rows in set (0,00 sec)
如上所示，创建了数据库和表对象，并将其相应的DDL语句写入二进制日志。此外，数据被插入到表中并被写入二进制日志。当组成员增长并且新成员尝试赶上并变为在线时执行分布式恢复时，二进制日志条目的重要性将在以下部分中说明。
Adding Instances to theGroup
此时，组中有一个成员，服务器s1，其中有一些数据。现在是通过添加先前配置的其他两个服务器来扩展组的时候了。
Adding a Second Instance
为了添加第二个实例，服务器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时使用的命令相同，因为用户在组中共享。
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0,00 sec)
mysql> CREATE USER rpl_user@'%';
Query OK, 0 rows affected (0,00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
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)
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)
安装组复制插件，并启动将服务器加入组的过程。以下示例以部署服务器s1时使用的相同方式安装插件。
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0,01 sec)
将服务器s2添加到组。
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (44,88 sec)
与以前的步骤与在s1上执行的步骤相同，这里有一个区别，因为您不发出SET GLOBAL group_replication_bootstrap_group = ON;在启动组复制之前，因为该组已由服务器s1创建和引导。此时，服务器s2只需要添加到已经存在的组中。
再次检查performance_schema.replication_group_members表，可以看出组中现在有两个ONLINE服务器。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost | 24801 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost | 24802 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
2 rows in set (0,00 sec)
由于服务器s2也被标记为ONLINE，它必须已经自动地赶上了服务器s1。验证它确实与服务器s1同步如下。
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
1 row in set (0,00 sec)
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0,00 sec)
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-aaaa-aaaa-aaaaaaaaaaaa:1' |
| 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-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| 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-aaaa-aaaa-aaaaaaaaaaaa:5' |
| 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 |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
19 rows in set (0,00 sec)
如上所示，第二个服务器已添加到组中，并且已自动从服务器s1复制了更改。根据分布式恢复过程，这意味着刚刚加入组之后并且在被声明为在线之前，服务器s2自动地连接到服务器s1并且从其获取丢失的数据。换句话说，它从s1的二进制日志中复制了它缺少的事务，直到它加入组的时间点。
Adding a Additional Instances
向组添加其他实例与添加第二个服务器基本上是相同的步骤，只是配置必须更改为服务器s2。总结所需的命令：
1.创建配置文件
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-5.7/
port=24802
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
2.启动服务器
mysql-5.7/bin/mysqld --defaults-file=data/s3/s3.cnf
3.配置group_replication_recovery通道的恢复凭据
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' \\
FOR CHANNEL 'group_replication_recovery';
4.安装组复制插件并启动它。
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_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| 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 |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
3 rows in set (0,00 sec)
在服务器s2或服务器s1上发出此相同的查询会产生相同的结果。此外，您可以验证服务器s3已经赶上：
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
1 row in set (0,00 sec)
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0,00 sec)
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-aaaa-aaaa-aaaaaaaaaaaa:1' |
| 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-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| 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-aaaa-aaaa-aaaaaaaaaaaa:5' |
| 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-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' |
| 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 |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
23 rows in set (0,00 sec)