Shulou(Shulou.com)06/01 Report--

The following content mainly brings you an introduction to MGR. The knowledge mentioned here, which is slightly different from books, is summed up by professional and technical personnel in the process of contact with users, and has a certain value of experience sharing. I hope to bring help to the majority of readers.

MySQL group replication is a plug-in for MySQL server, which needs to be configured and installed for each server in the group. This section provides a detailed tutorial that contains the steps required to create a replication group of at least three server.

18.2.1 deploy group replication in single primary mode

Each server instance in the group can run on a separate physical machine or on the same machine. This section describes how to create a replication group with three MySQL Server instances on one physical machine. This means that three data directories are required, one for each server instance, and each instance needs to be configured separately.

Figure 18.4 sets of architectures

This tutorial describes how to use the group replication plug-in to obtain and deploy MySQL Server, how to configure each server instance before creating a group, and how to use Performance Schema to verify that everything is working.

18.2.1.1 deployment group replication instance

The first step is to deploy three instances of MySQL CVM. Group replication is a built-in MySQL plug-in provided with MySQL Server 8.0. For more background information on the MySQL plug-in, see Section 5.6, "MySQL Server plug-in." After downloading the MySQL server package, you need to unzip and install the binaries. This procedure assumes that the MySQL server has been downloaded and unzipped to the current directory, which needs to be under the mysql-8.0 directory. Because this tutorial uses a physical machine, each MySQL instance requires a specific data directory to store the instance's data. Create a data directory in a directory named data and initialize each directory.

Mkdir datamysql-8.0/bin/mysqld-initialize-insecure-basedir=$PWD/mysql-8.0-datadir=$PWD/data/s1mysql-8.0/bin/mysqld-initialize-insecure-basedir=$PWD/mysql-8.0-datadir=$PWD/data/s2mysql-8.0/bin/mysqld-initialize-insecure basedir=$PWD/mysql-8.0 datadir=$PWD/data/s3

Data/s1,data/s2 and data/s3 are initialized data directories that contain MySQL system databases and related tables. To learn more about the initialization process, see Section 2.10.1, "initializing the data Catalog."

Warning

Do not use initialize-insecure in a production environment, it is only used to simplify tutorials. For more information about security settings, see Section 18.5, "Group replication Security."

18.2.1.2 configure group replication instances

This section describes the configuration settings required for MySQL Server instances to be used for group replication. For background information, see Section 18.8.2, "Group replication restrictions."

Group replication Server Settings

To install and use the group replication plug-in, the MySQL server instance must be configured correctly. It is recommended that you store the configuration in the my.cnf file. For more information, see Section 4.2.7, "use of Files." Without special instructions, the following is the configuration of the first instance in the group, which is called S1 in this section. The following section shows a sample configuration of server.

[mysqld] # server configurationdatadir=/data/s1basedir=/mysql-8.0/port=24801socket=/s1.sock

These settings configure MySQL server to use the previously created data directory, configure which port server should open, and start listening for incoming connections.

Note

Use a non-default port of 24801 here because in this tutorial, three server instances use the same hostname. This setting is not required in an environment with three different machines.

Group replication requires network interworking between members, which means that each member must be able to resolve the network addresses of all other members. For example, in this tutorial, all three instances are running on the same machine, so to ensure that members can contact each other, you can also add a line to the configuration file, such as report_host=127.0.0.1.

Copy frame

The following settings configure replication based on MySQL group replication requirements.

Server_id=1gtid_mode=ONenforce_gtid_consistency=ONbinlog_checksum=NONE

These settings configure server to use unique identification number 1 to enable global transaction identifiers to allow only statements based on GTID security records to be executed and to disable binary log event checksums.

If you are using a version of MySQL earlier than 8.0.3, where the default values have been improved for replication, you need to add these lines to the member's configuration file.

Log_bin=binloglog_slave_updates=ONbinlog_format=ROWmaster_info_repository=TABLErelay_log_info_repository=TABLE

These settings specify that server turns on binary logging, uses a row-based format, stores replication metadata in system tables instead of files, and disables binary log event checksums. For more details, see Section 18.8.1, "Group replication requirements."

Group replication Settings

Ensure that the my.cnf file in server is now configured as required and that server instantiates the replication infrastructure as configured. The following sections are the configurations for server group replication.

Transaction_write_set_extraction=XXHASH64group_replication_group_name= "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=offgroup_replication_local_address= "127.0.0.1 group_replication_start_on_boot=offgroup_replication_local_address=" 24901 "group_replication_group_seeds=" 127.0.0.1 group_replication_start_on_boot=offgroup_replication_local_address= 24901127.0.1 "group_replication_bootstrap_group=off configuration transaction_write_set_extraction instructs the server for each transaction It must collect the write set and encode it as a hash using the XXHASH64 hash algorithm. Starting with MySQL 8.0.2, this setting is the default, so you can omit this line. The configuration group_replication_group_name tells the plug-in that the group it is joining or creating is named "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" the value group_replication_group_name must be a valid UUID. This UUID is used internally when GTID is set for group replication events in the binary log. You can use SELECT UUID () to generate a UUID. Configuring group_replication_start_on_boot instructs the plug-in not to automatically start group replication when server starts. This is important when setting up group replication because it ensures that you can configure server before starting the plug-in manually. After configuring the members, you can set group_replication_start_on_boot to on to start Group Replication automatically when server restarts. Configuring group_replication_local_address tells the plug-in to use IP address 127.0.0.1 and port 24901 to communicate internally with other members of the group.

Important

Server listens for connections between group members on this port. This port cannot be used for user applications and must be reserved for communication between different members of the group when running group replication.

The local address configured by group_replication_local_address must be accessible to all team members. For example, if each server instance is on a different computer, you can use the computer's IP address, such as 10.0.0.1. If you use a hostname, you must use a fully qualified name and ensure that it can be resolved through DNS and that the correct / etc/hosts file or other domain name resolution process is configured. Starting with MySQL 8.0.14, you can use the IPv6 address (or its hostname that can be resolved) as well as the IPv4 address. A group can contain a mix of members using IPv6 and members using IPv4. For more information about IPv6 networks and group replication support for mixed IPv4 and IPv6 groups, see Section 18.4.5, "supporting IPv6 and mixed IPv6 and IPv4 groups."

The recommended port group_replication_local_address is 33061. In this tutorial, we use three instances of server running on one computer, so we use ports 24901 to 24903 for internal communication. Group_replication_local_address Group Replication uses it as a unique identifier for group members in the replication group. As long as the hostname or IP address is different, you can use the same port for all members of the group replication, and as shown in this tutorial, as long as you have the same hostname or IP address, you can use the same hostname or IP address. Only the ports are different.

Configure group_replication_group_seeds to set the hostname and port of the group members that new members use to establish a connection with the group. These members are called seed members. After the connection is established, the group membership information is in the performance_schema.replication_group_ membership table. Typically, the group_replication_group_seeds list contains a list group_replication_local_address for each group member of the hostname:port, but this is not mandatory, and a subset of the group members can be selected as a seed.

Important

The hostname:port column, which is the internal IP address of the seed member in group_replication_group_seeds, is used for client connections based on configuration group_replication_local_address, not SQL hostname:port, and is displayed in the performance_schema.replication_group_members table.

The server of the startup group does not use this option because it is the initial server, so it is responsible for booting the group. The second joining server applies to the only member of the group to join, and then the group can be expanded. The third added server can apply to either of the two server to join, and then the group can be expanded again. Subsequent server repeats this process when it joins.

Warning

When multiple server are joined at the same time, make sure that they are already seed members in the group. Do not use seed members who are also applying to join the group, as they may not have joined the group at the time of the visit.

First start the boot member and ask it to create a group, and then make it a seed member of the rest of the members you are joining. This ensures that there is already a group when you join the rest of the members.

Creating groups and joining multiple members at the same time is not supported. This may happen when operating in competition, but joining the group will eventually result in an error or timeout.

The member to join must communicate with the seed member using the same protocol (IPv4 or IPv6) that the seed member advertises in the group_replication_group_seeds option. For the purpose of the whitelist of IP addresses copied by the group, the whitelist on the seed member must contain the IP address of the joining member of the protocol provided by the seed member, or the hostname that resolves to the address of the protocol. In addition to joining a member, you must also set this address or hostname and whitelist group_replication_local_address if the protocol of the address does not match the notification protocol of the seed member. If the joining member does not have a whitelist address for the appropriate protocol, its connection attempt is rejected. For more information, see Section 18.5.1, "whitelist of IP addresses."

The configuration group_replication_bootstrap_group indicates whether the plug-in is a boot group.

Important

This option can only be used on one server instance at any time, usually when the group is booted for the first time (or if the entire group is crashed and then restored). If you boot a group multiple times, for example, when multiple server instances have this option set, they may artificially cause a brain fissure, where there are two different groups with the same name. Disable this option after the first server instance joins the group.

The configuration of all server members in the group is very similar. You need to change the details of each server (for example, server_id, datadir,group_replication_local_address). This will be introduced later in this tutorial.

18.2.1.3 user credentials

Group replication uses an asynchronous replication protocol for distributed recovery, synchronizing group members before joining the group. The distributed recovery process relies on the group_replication_recovery replication channel, which is used to transfer transactions between group members. Therefore, you need to set up replication users with the correct permissions so that group replication can directly establish a member-to-member recovery replication channel.

Start the server using the configuration file:

Mysql-8.0/bin/mysqld-defaults-file=data/s1/s1.cnf

Create a MySQL user with REPLICATION-SLAVE privileges. This action should not be logged to the binary log to avoid passing changes to other server instances. Connect to server S1 and execute the following statement:

Mysql > SET SQL_LOG_BIN=0

The following example shows the process of creating a user rpl_user with a password of rpl_pass. The correct user name and password are required when configuring the server.

Mysql > CREATE USER rpl_user@'%' IDENTIFIED BY 'password';mysql > GRANT REPLICATION SLAVE ON *. * TO rpl_user@'%';mysql > FLUSH PRIVILEGES

If binary logging is disabled, enable it again after the user is created.

Mysql > SET SQL_LOG_BIN=1

After the user has made the above configuration, you need to use the CHANGE MASTER TO statement to configure server to use group_replication_recovery to copy the given credentials of the channel the next time you need to restore their state from other members. Execute the following command to replace rpl_user and rpl_pass with the values used when creating the user.

Mysql > CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'\\ FOR CHANNEL 'group_replication_recovery'

Distributed recovery is the first step performed by the server that joins the group. "if these credentials are not set correctly, server will not be able to perform the recovery process and get synchronized with other group members, so it will eventually be unable to join the group."

Similarly, if a member cannot correctly identify other members by the hostname of the server, the restore process may fail. It is recommended that operating systems running MySQL are correctly configured with a unique hostname, using DNS or local settings. You can verify this hostname in the Member_host column of the performance_schema.replication_group_members table. If multiple group members use the default hostname set by the operating system, there will be a situation in which a member cannot resolve to the correct member address and cannot join the group. In this case, you can use report_host to configure a unique hostname for each server.

Use the group replication and Caching SHA-2 user credential plug-in

By default, users created in MySQL 8 use section 6.5.1.3, "caching SHA-2 plug-in authentication." If your configured user _ rpl_user_ for distributed recovery uses the cached SHA-2 authentication plug-in and does not use the 18.5.2, secure Sockets layer support (SSL) group_replication_recovery replication channel, and the RSA key is used for password exchange, see Section 6.4.3, "creating SSL and RSA certificates and keys". You can copy the public key of a member whose state rpl_user should restore from the group to that group, or you can configure the donor to provide the public key upon request.

A more secure approach is to copy the public key rpl_user to the member who should restore the group state from the donor. Then, you need group_replication_recovery_public_key_path to configure the system variable on the member that joined the group and provide it with the path rpl_user of the public key.

Optionally, the alternative is to set up group_replication_recovery_get_public_key=ON donors so that their rpl_user provides the members' public keys when they join the group. The identity of the server cannot be verified, so group_replication_recovery_get_public_key=ON is set only if you determine that there is no risk that the server's identity will be compromised, for example, through the middleman.

18.2.1.4 start group replication

After configuring and starting server S1, install the group replication plug-in. Then connect to server and execute the following command:

INSTALL PLUGIN group_replication SONAME 'group_replication.so'

Important

The mysql.session user must exist before loading group replication. Mysql.session users have been added in MySQL version 8.0.2. If you need to initialize the data dictionary with an earlier version, you must perform the MySQL upgrade process (see Section 2.11, "upgrading MySQL"). If the upgrade is not running, the group replication starts with the following error: 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..

To check that the plug-in has been successfully installed, execute SHOW PLUGINS and check the output. It should look like this:

Mysql > SHOW PLUGINS +-- +-- +-+ | Name | Status | Type | | Library | License | +-- +-- +-+ | binlog | | | ACTIVE | STORAGE ENGINE | NULL | PROPRIETARY | (...) | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | PROPRIETARY | +-+-| -+

To start a group, instruct the server S1 boot group, and then start the group replication program. This boot should be done independently by a single sever, and the server starts the group only once. This is why the value of the boot configuration option is not saved in the configuration file. If you save it in the configuration file, server automatically boots a second group with the same name when you restart. This will result in two different groups having the same name. The same applies to stopping and restarting plug-ins, and this option is set to ON.

SET GLOBAL group_replication_bootstrap_group=ON;START GROUP_REPLICATION;SET GLOBAL group_replication_bootstrap_group=OFF

After the START GROUP_REPLICATION statement returns, the group is started. You can check that the group has now been created and that it already has one member:

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 | +-- +-- -+

The information in this table confirms that there is a member of the group and has a unique identifier ce9be252-2b71-11e6-b8f4-00212844f856, which is online and listens for client connections on myhost port 24801.

To demonstrate that server is indeed in a group and can handle loading, create a table and add some content to it.

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 contents of table T1 and binary logs.

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: 8.0.2-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,270,270,270 | BEGIN | | binlog.000001 | 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 * / | +-+- -- +

As shown above, the database and table objects are created and their corresponding DDL statements are written to the binary log. In addition, the data is inserted into the table and written to the binary log. As group membership grows and distributed recovery is performed as new members try to join and become online, the importance of binary log entries is explained in the following sections.

18.2.1.5 add an instance to the group

At this point, there is a member of the group, server S1, where some data already exists. At this point, you can expand the group by adding the other two server that you configured previously.

18.2.1.5.1 add a second instance

To add a second instance, server S2, first create a configuration file for it. This configuration is similar to the configuration for server S1, except for things such as the location of the data directory, the port that S2 will listen on, or its server_id. These different lines are highlighted in the list below.

[mysqld] # server configurationdatadir=/data/s2basedir=/mysql-8.0/port=24802socket=/s2.sock## Replication configuration parameters#server_id=2gtid_mode=ONenforce_gtid_consistency=ONbinlog_checksum=NONE## Group Replication configuration#transaction_write_set_extraction=XXHASH64group_replication_group_name= "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=offgroup_replication_local_address= "127.0.0.1 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 24902" group_replication_group_seeds= "127.0.0.1 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 24901127.0.1purl 24902127 .0.0.1: 24903 "group_replication_bootstrap_group= off

The process for server S1 is similar to starting server with the configuration file in place.

Mysql-8.0/bin/mysqld-defaults-file=data/s2/s2.cnf

Then configure the recovery credentials as shown below. Because users share in the group, this command is the same as the command used when setting up server S1. Execute the following statement on 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'

Tip

"if you are using the cached SHA-2 authentication plug-in (the default in MySQL 8), see using the Group replication and caching SHA-2 user credential plug-in."

Install the group replication plug-in and start the program that adds server to the group. The following example installs the plug-in in the same way as when you deployed server S1.

Mysql > INSTALL PLUGIN group_replication SONAME 'group_replication.so'

Add server S2 to the group.

Mysql > START GROUP_REPLICATION

Unlike the previous steps, one difference from those performed on S1 is that the operation SET GLOBAL group_replication_bootstrap_group = ON is not performed; before starting the group replication, because the group has been created and booted by server S1. At this point, server S2 only needs to be added to the existing group.

Tip

When group replication starts successfully and the server joins the group, it checks the super_read_only variable. By setting super_read_only to ON in the member's configuration file, you can ensure that the server that fails when starting group replication for any reason does not accept transactions. If the server should join the group as a read-write instance, for example, as a member of a primary or multi-primary group in a single primary group, when the super_read_only variable is set to ON, it is set to OFF when joined.

Checking the performance_schema.replication_group_members table again, you can see that there are now two server of ONLINE in the group.

Mysql > SELECT * FROM performance_schema.replication_group_members +-+ | CHANNEL_NAME | | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +-- | -+-+ | group_replication_applier | 395409e1-6dfahorse 11e6-970b-00212844f856 | myhost | 24801 | ONLINE | | group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost | 24802 | ONLINE | +-+- -- +

Since server S2 is also marked as ONLINE, it must already be synchronized with server S1. Verify that it is indeed synchronized with server S1 as follows.

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: 8.0.3-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 | 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 | 1,326 | COMMIT | + | -+- -+

As shown above, the second server has been added to the group and the changes have been automatically copied from server S1. According to the distributed recovery process, this means that server S2 automatically connects to server S1 and fetches lost data from it after joining the group and before it is declared online. In other words, it replicates the transactions it lacked before joining the group's time node from S1's binary log.

18.2.1.5.2 add additional instances

Adding other instances to the group is basically the same step as adding a second server, except that the configuration must be changed to the corresponding server. The required commands are summarized as follows:

1. Create a profile

[mysqld] # server configurationdatadir=/data/s3basedir=/mysql-8.0/port=24803socket=/s3.sock## Replication configuration parameters#server_id=3gtid_mode=ONenforce_gtid_consistency=ONbinlog_checksum=NONE## Group Replication configuration#group_replication_group_name= "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=offgroup_replication_local_address= "127.0.0.1 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 24903" group_replication_group_seeds= "127.0.0.1 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 24901127.0.0.1 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa 24903" group_replication_bootstrap_group= off

two。 Start server

Mysql-8.0/bin/mysqld-defaults-file=data/s3/s3.cnf

_ 3. Configure the recovery credentials for the group_replicationrecovery channel.

SET SQL_LOG_BIN=0;CREATE USER rpl_user@'%' IDENTIFIED BY 'password';GRANT REPLICATION SLAVE ON *. * TO rpl_user@'%';FLUSH PRIVILEGES;SET SQL_LOG_BIN=1;CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'\\ FOR CHANNEL' group_replication_recovery'

4. Install the Group Replication plug-in and start it.

INSTALL PLUGIN group_replication SONAME 'group_replication.so';START GROUP_REPLICATION

At this point, server S3 is booted and running, and has joined the group and synchronized with other server members in the group. Visit the performance_schema.replication_group_members table to reconfirm that this is the case.

Mysql > SELECT * FROM performance_schema.replication_group_members +-+ | CHANNEL_NAME | | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +-- | -+-+ | group_replication_applier | 395409e1-6dfahorse 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 | +- -+

Issuing this same query on server S2 or server S1 produces the same results. In addition, you can verify that server S3 is synchronized:

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: 8.0.3-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 | 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 | 1,326 | 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 | +- -+

For the above introduction to MGR, if you need to know more, you can continue to pay attention to the innovation of our industry, if you need to get professional answers, you can contact the pre-sale and after-sale on the official website. I hope this article can bring you some knowledge updates.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.