Keine Cache-Version

Caching deaktiviert Standardeinstellung für diese Seite:aktiviert (code DEF204)
Wenn die Anzeige zu langsam ist, können Sie den Benutzermodus deaktivieren, um die zwischengespeicherte Version anzuzeigen.

Rechercher dans le manuel MySQL

18.2.1.6 Adding Instances to the Group

Inhaltsverzeichnis

At this point, the group has one member in it, server s1, which has some data in it. It is now time to expand the group by adding the other two servers configured previously.

18.2.1.6.1 Adding a Second Instance

In order to add a second instance, server s2, first create the configuration file for it. The configuration is similar to the one used for server s1, except for things such as the server_id. These different lines are highlighted in the listing below. 

[mysqld]

#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off

Similar to the procedure for server s1, with the option file in place you launch the server. Then configure the distributed recovery credentials as follows. The commands are the same as used when setting up server s1 as the user is shared within the group. This member needs to have the same replication user configured in Section 18.2.1.3, “User Credentials”. If you are relying on distributed recovery to configure the user on all members, when s2 connects to the seed s1 the replication user is replicated or cloned to s1. If you did not have binary logging enabled when you configured the user credentials on s1, and a remote cloning operation is not used for state transfer, you must create the replication user on s2. In this case, connect to s2 and issue:

  1. SET SQL_LOG_BIN=0;
  2. CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
  3. GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
  4. GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
  5. SET SQL_LOG_BIN=1;
  6. CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
  7.   FOR CHANNEL 'group_replication_recovery';
Tip

If you are using the caching SHA-2 authentication plugin, the default in MySQL 8, see Using Group Replication and the Caching SHA-2 User Credentials Plugin.

If necessary, install the Group Replication plugin, see Section 18.2.1.4, “Launching Group Replication”.

Start Group Replication and s2 starts the process of joining the group.

  1. mysql> START GROUP_REPLICATION;

Unlike the previous steps that were the same as those executed on s1, here there is a difference in that you do not need to boostrap the group because the group already exiists. In other words on s2 group_replication_bootstrap_group is set to off, and you do not issue SET GLOBAL group_replication_bootstrap_group=ON; before starting Group Replication, because the group has already been created and bootstrapped by server s1. At this point server s2 only needs to be added to the already 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 servers which fail when starting Group Replication for any reason do not accept transactions. If the server should join the group as read-write instance, for example as the primary in a single-primary group or as a member of a multi-primary group, when the super_read_only variable is set to ON then it is set to OFF upon joining the group.

Checking the performance_schema.replication_group_members table again shows that there are now two ONLINE servers in the group.

  1. mysql> SELECT * FROM performance_schema.replication_group_members;
  2. +---------------------------+--------------------------------------+-------------+-------------+---------------+
  3. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
  4. +---------------------------+--------------------------------------+-------------+-------------+---------------+
  5. | group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |   s1        |        3306 | ONLINE        |
  6. | group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |   s2        |        3306 | ONLINE        |
  7. +---------------------------+--------------------------------------+-------------+-------------+---------------+

When s2 attempted to join the group, Section 18.4.3, “Distributed Recovery” ensured that s2 applied the same transactions which s1 had applied. Once this process completed, s2 could join the group as a member, and at this point it is marked as ONLINE. In other words it must have already caught up with server s1 automatically. Once s2 is ONLINE, it then begins to process transactions with the group. Verify that s2 has indeed synchronized with server s1 as follows.

  1. mysql> SHOW DATABASES LIKE 'test';
  2. +-----------------+
  3. | Database (test) |
  4. +-----------------+
  5. | test            |
  6. +-----------------+
  7.  
  8. mysql> SELECT * FROM test.t1;
  9. +----+------+
  10. | c1 | c2   |
  11. +----+------+
  12. |  1 | Luis |
  13. +----+------+
  14.  
  15. mysql> SHOW BINLOG EVENTS;
  16. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
  17. | Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
  18. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
  19. | binlog.000001 |    4 | Format_desc    |         2 |         123 | Server ver: 8.0.19-log, Binlog ver: 4                              |
  20. | binlog.000001 |  123 | Previous_gtids |         2 |         150 |                                                                    |
  21. | binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
  22. | binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
  23. | binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
  24. | binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
  25. | binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
  26. | binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
  27. | binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
  28. | binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
  29. | binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
  30. | binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
  31. | binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
  32. | binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
  33. | binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=30 */                                                |
  34. | binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
  35. | binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
  36. | binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
  37. | binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
  38. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

As seen above, the second server has been added to the group and it has replicated the changes from server s1 automatically. In other words, the transactions applied on s1 up to the point in time that s2 joined the group have been replicated to s2.

Inhaltsverzeichnis Haut

18.2.1.6.2 Adding Additional Instances

Adding additional instances to the group is essentially the same sequence of steps as adding the second server, except that the configuration has to be changed as it had to be for server s2. To summarise the required commands:

1. Create the configuration file 

[mysqld]

#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

#
# Group Replication configuration
#
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s3:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off

2. Start the server and connect to it. Configure the distributed recovery credentials for the group_replication_recovery channel.

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

4. Install the Group Replication plugin and start it.

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

At this point server s3 is booted and running, has joined the group and caught up with the other servers in the group. Consulting the performance_schema.replication_group_members table again confirms this is the case.

  1. mysql> SELECT * FROM performance_schema.replication_group_members;
  2. +---------------------------+--------------------------------------+-------------+-------------+---------------+
  3. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
  4. +---------------------------+--------------------------------------+-------------+-------------+---------------+
  5. | group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |   s1        |       3306  | ONLINE        |
  6. | group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 |   s3        |       3306  | ONLINE        |
  7. | group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |   s2        |       3306  | ONLINE        |
  8. +---------------------------+--------------------------------------+-------------+-------------+---------------+

Issuing this same query on server s2 or server s1 yields the same result. Also, you can verify that server s3 has caught up:

  1. mysql> SHOW DATABASES LIKE 'test';
  2. +-----------------+
  3. | Database (test) |
  4. +-----------------+
  5. | test            |
  6. +-----------------+
  7.  
  8. mysql> SELECT * FROM test.t1;
  9. +----+------+
  10. | c1 | c2   |
  11. +----+------+
  12. |  1 | Luis |
  13. +----+------+
  14.  
  15. mysql> SHOW BINLOG EVENTS;
  16. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
  17. | Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
  18. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
  19. | binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 8.0.19-log, Binlog ver: 4                              |
  20. | binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
  21. | binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
  22. | binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
  23. | binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
  24. | binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
  25. | binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
  26. | binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
  27. | binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
  28. | binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
  29. | binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
  30. | binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
  31. | binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
  32. | binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
  33. | binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=29 */                                                |
  34. | binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
  35. | binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
  36. | binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
  37. | binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
  38. | binlog.000001 | 1326 | Gtid           |         1 |        1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6'  |
  39. | binlog.000001 | 1387 | Query          |         1 |        1446 | BEGIN                                                              |
  40. | binlog.000001 | 1446 | View_change    |         1 |        1585 | view_id=14724832985483517:3                                        |
  41. | binlog.000001 | 1585 | Query          |         1 |        1650 | COMMIT                                                             |
  42. +---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

Suchen Sie im MySQL-Handbuch

Deutsche Übersetzung

Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.

Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.

Vielen Dank im Voraus.

Dokument erstellt 26/06/2006, zuletzt geändert 26/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/mysql-rf-group-replication-adding-instances.html

Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.

Referenzen

  1. Zeigen Sie - html-Dokument Sprache des Dokuments:en Manuel MySQL : https://dev.mysql.com/

Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.

Inhaltsverzeichnis Haut