This section describes how to upgrade the settings of group replication. The basic steps for upgrading group members are the same as the steps for upgrading a single instance. Regarding the upgrade method, you can specifically choose in-situ upgrade (using the mysql_upgrade command to upgrade the data dictionary based on the original data file) or logical upgrade (build a new version of Server in advance, The data in the old version is exported logically and then imported into the new version), depending on the amount of data stored in the group. Generally, in-place upgrade is faster, so it is recommended to use in-place upgrade to upgrade.
During the online upgrade of a group, in order to maximize the availability of the group (as far as possible to ensure the availability of the group), it is necessary to perform a rolling upgrade (update one by one) for the members of the group. Therefore, it may be necessary to run different MySQL in a group at the same time Member of the Server version. There are some compatibility strategies when a group contains members of different versions, which can safely combine members running different versions of MySQL in the same group during the upgrade process. In addition, these strategies may affect the order in which members of the upgrade group are promoted. For details, see "7.1 Compatible members of different versions in a group".
If the group can be upgraded offline, please refer to "7.2. Group replication offline upgrade" for the specific upgrade process. If you need to upgrade the group online (usually, the production environment requires online upgrade), please refer to "7.3. Group Replication Online Upgrade" to learn about the different methods of upgrading the group with minimum downtime.
7.1. Compatible members of different versions in a group
Group replication is version controlled according to the version of MySQL Server bound to the MGR plugin. For example, if a member is running in MySQL version 5.7.26, then this is the version of the MGR plugin. Use the following statement to check the MySQL Server version in the group members:
root@localhost : (none):35: > SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_VERSION |
+-------------+-------------+----------------+
| node2 | 3306 | 8.0.17 |
| node3 | 3306 | 8.0.17 |
| node1 | 3306 | 8.0.17 |
+-------------+-------------+----------------+
3 rows in set (0.01 sec)
In order to obtain the best compatibility and performance, all members of the group are recommended to run the same version of MySQL Server, and it is also recommended to run the same version of the group replication communication protocol. However, during the online upgrade of a group, in order to maximize the availability of the group, it may be necessary to run members of different MySQL Server versions at the same time. Because some features between different MySQL versions may be different (for example: the newer version may support some new functions but the old version does not, some functions supported in the older version are deleted in the newer version) , In this case, there may be incompatibility issues between the new and old versions. In this case, if you configure different versions of MySQL Server into a group, it may cause members who rely on deprecated features to fail, and it may also cause problems with older versions that do not support new features in the new version.
To prevent these problems, group replication supports some compatibility strategies to make a group of group members running on different MySQL Server versions safe and compatible. Group members apply these policies to decide whether to join the group normally, or to join the group in read-only mode, or not to join the group, depending on which choice can ensure the security of operations between the newly added Server and the existing members of the group. When performing a rolling upgrade to a group, each member needs to leave the group first, then upgrade to the new version, and then join the group again with the new version. At this time, the members in the group need to match the corresponding strategy for the new version (the The policy may be different from the policy applied before the group member upgrade).
The compatibility policy applied by members trying to join the group is as follows:
If the version of a MySQL Server is lower than the minimum version run by the existing group members in the group, the server is not allowed to join the group.
If the version of a MySQL Server is the same as the minimum version running by the existing members of the group, then the Server will usually (and allow) to join the group.
After a Server joins the group, if the MySQL Server version it runs is higher than the minimum version run by the existing group members in the group, the member will remain in read-only mode (if the group is running in single-primary mode, the newly added members are in any In all cases, the default is read-only; if the group is running in multi-primary mode, the newly added members may be in read-write mode).
Server running MySQL 8.0.17 or higher will consider the patch version of the release when checking its compatibility (for example, the version number is 8.0.17, where 8.0 represents the major version, 17 represents the patch version, which can also be called minor Version). Servers running MySQL 8.0.16 or lower or MySQL 5.7 only consider major versions (for example, the version number is 8.0.16, where 8.0 is the major version). Assuming a group where all members are running version 8.0.13, the compatibility policy applied by the server trying to join the group is as follows:
A server running MySQL 5.7.x is not allowed to join the group.
A server running MySQL version 8.0.16 is allowed to join the group normally (because only the major version string 8.0 is considered here, which matches the string 8.0 considered by the existing members of the group).
A server running MySQL version 8.0.17 is allowed to join the group, but will remain in read-only mode (because the newly added server will also consider patch version 17, which is 8.0.17, while existing members in the group only consider strings 8.0).
Note that when a server with a version of MySQL before 5.7.27 joins a group, it will check the version of all group members, so as to check whether the MySQL major version number of each group member is lower. Therefore, according to the above example and compatibility policy, if any member of the group is running MySQL 8.0 version, this check will fail, causing the server of MySQL version before 5.7.27 to be unable to join the group, even if other members of the group are already running MySQL In version 5.7, you cannot join the group either. Starting from the MySQL 5.7.27 version, the server that joins the group only checks the minimum major version running by the existing members of the group. In this way, the server running on MySQL 5.7.27 and later can join a server that uses a mixed MySQL 5.7.x The group of version members.
In multi-master mode groups with different MySQL Server versions, group replication will automatically manage the read-write and read-only status of members running MySQL 8.0.17 or later. If a member leaves the group, the member running the current lowest version will automatically be set to read-write mode. When using group_replication_switch_to_multi_primary_mode() UDF online to modify a single-primary mode group to multi-primary mode, group replication will automatically set the members to the correct mode. If a member runs a version of MySQL Server higher than the lowest version in the group, it will automatically be set to read-only mode, and the member running the lowest version will automatically be set to read-write mode.
7.1.1. Upgrade group members
During the online upgrade process, if the group is in single-master mode, after the member performing the upgrade operation goes offline (the member of the group performing the upgrade operation needs to be offline, the member of the group not performing the upgrade operation does not need to be offline), the group is not executed The members of the upgrade group will elect a new primary node according to the election strategy described in "1.3.1 Single-Master Mode". Note that if the primary node is required to always remain unchanged (unless it is performing the upgrade itself), you must first perform the upgrade on all other group members, and then perform the upgrade on the primary node last (when the primary node is upgraded, the primary node is offline due to , So the new primary node will be re-elected in the group. After the upgrade is completed, if you want the primary node to remain the original member, then you can use group_replication_set_as_primary() UDF to re-designate it as the primary node).
If the group is in multi-primary mode, the group members that can perform write operations normally during the upgrade process will become less and less, because the upgraded members will be placed in read-only mode and rejoin the group (this is to prevent the new version from Features cannot be successfully copied in the old version). If all members are upgraded to MySQL 8.0.17 and later versions, they will automatically return to read-write mode. But for earlier versions, after the upgrade is complete, you must manually set the system variables super_read_only and read_only on each group member to OFF (set the read-write mode) to make it the main node.
Note: For the comparison of new and old versions, starting from MySQL 8.0.17, the minor version number needs to be considered when comparing, and for versions 8.0.16 and before, only the major version number is considered when comparing versions.
If you need to make upgrade rollback members during the group member upgrade process, or you need to add a new member to the group, in an emergency, you can allow a member whose MySQL Server version is lower than the lowest version in the group to join the group (using group Copy the system variable group_replication_allow_local_lower_version_join to override the normal compatibility policy. It should be noted that setting this system variable to ON will not make the new member compatible with the group. Therefore, this system variable can only be used with caution in specific situations. For more prevention Please refer to the description of the group_replication_allow_local_lower_version_join system variable in "8. Group replication system variables").
7.1.2. Group copy communication protocol version
The group communication protocol version number used by group replication is not necessarily the same as the MySQL Server version number of the group members (for example: the communication protocol version used by MySQL Server 8.0.17 is 8.0.16 instead of 8.0.17, the protocol version represents The lowest MySQL Server version currently supported by this group, MySQL version 5.7.14 supports compressed messages, and MySQL version 8.0.16 supports message segmentation). To view the communication protocol version of the group, you can execute the following statement in any member of the group to query:
root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
Note: The group communication protocol version returned by group_replication_get_communication_protocol() UDF represents the lowest MySQL Server version currently supported by the group. When group_replication_set_communication_protocol() UDF is used to perform group communication protocol configuration, the final effective value may be different from the value passed to the function. For example: the value passed to this function is 8.0.17, and the final effective value is 8.0.16.
When all members of a replication group are upgraded to a new MySQL Server version, the group replication communication protocol version will not be automatically upgraded, in case it is still necessary to allow members of the earlier version to join the group. If after upgrading to the new version, it is determined that you do not need to support the old version of Server, and you also want to use some additional functions of the new version, you can use the group_replication_set_communication_protocol() UDF function to upgrade the group communication protocol version (anyone in the group) Only one member can modify the group communication protocol version operation). For more information, see "4.1.4 Setting the communication protocol version of the group".
7.2. Offline upgrade of group replication
To perform an offline upgrade for group replication, you need to remove all members of the group from the group one by one. After ensuring that the group is offline, perform version upgrades on each server. After upgrading all server versions, restart the group normally. In a multi-master mode group, you can remove and close group members in any order. In a single-master mode group, you need to first remove and close the servers of read-only members one by one, and finally close the servers of the main node (write node) member. For how to remove members from the group and shut down MySQL Server, see "7.3.2. Upgrading Group Replication Members".
After all members in a group are successfully upgraded to the new version, when the group is restarted, these members will use the new version of the group replication communication protocol to connect. If you need to allow an earlier version of Server to join the group at this time, you can use the group_replication_set_communication_protocol() UDF to downgrade the group communication protocol version to the version number of the communication protocol supported by the old version (or directly fill in the version number of the old version of MySQL Server)
7.3. Online upgrade of group replication
When you want to perform a version upgrade of a running group, and you must ensure that the group provides services to the outside world during the upgrade process, you need to use the correct upgrade method. This section will introduce some methods of how to perform an online upgrade group.
7.3.1. Precautions for online upgrade
When upgrading a group online, the following points need to be considered:
Regardless of how the group members are upgraded, it is forbidden to perform any write operations on the members until the group members are upgraded and rejoin the group.
When a member stops group replication, the system variable super_read_only will be automatically set to on, but this changed value is not persistent, that is, the changed value will be overwritten by the setting in the configuration file or the default value after restarting the Server.
When members of MySQL 5.7.22 or MySQL 8.0.11 try to join a group running MySQL 5.7.21 or lower, they will fail because MySQL 5.7.21 will not send the value of the system variable lower_case_table_names
7.3.2. Upgrade group replication members
This section describes the steps required to upgrade group members. This process is part of "7.3.3 Group Copy Online Upgrade Method". The method of upgrading all members in a group is common, but it should be noted that the group is running in single-master mode or multi-master mode, which will affect the order in which group members are upgraded and rejoined.
The process of upgrading group members includes: removing them from the group, performing the upgrade according to the method of upgrading members selected, and then adding the upgraded members to the group again. When upgrading members in a single-master mode group, it is recommended to upgrade the read-only nodes first, and then upgrade the read-write nodes (primary nodes). If the read-write nodes need to be upgraded before the read-only nodes, you need to select an old one. The other members of the version serve as the new main nodes. Therefore, in order to reduce the workload, it is usually recommended that the read and write nodes be upgraded last.
Upgrade group members:
Use the client to log in to the group member to be upgraded and execute the STOP GROUP_REPLICATION statement to stop group replication, and then check the performance_schema.replication_group_members table to ensure that the member is in the OFFLINE state (note that there should be only one row in the table at this time , And the MEMBER_STATE field value of this row record is OFFLINE).
By setting the system variable group_replication_start_on_boot=0 to prohibit the member from automatically joining the group when restarting, after the upgrade and configuration operations are completed, manually and safely rejoin the member to the group. Note: If the member performing the upgrade sets the system variable group_replication_start_on_boot=1, if the upgrade operation fails, the failed member will try to join the group automatically when the server is restarted.
Stop the MySQL Server process of group members. For example, use the mysqladmin shutdown command on the server where the Server is located or log in to the database and use the shutdown statement to stop the server process of group members that need to be upgraded. At this time, other members of the group continue to run without being affected.
Use in-situ (use the mysql_upgrade command to upgrade the data dictionary method) or use the pre-installed and configured new version of the server to upgrade the logical derivative. When the server is restarted after the upgrade, because the system variable group_replication_start_on_boot is set to 0, the group replication will not be automatically started and rejoin the group, so manual operations are required to rejoin the group.
When the member upgrade is completed, the system variable group_replication_start_on_boot must be set to 1 to ensure that the member can automatically rejoin the group after the next restart.
Use the client to log in to the upgraded Server and execute the START GROUP_REPLICATION statement to start group replication. Rejoin the server to the group. At this point, the metadata of the group replication is ready in the upgraded members, so there is usually no need to reconfigure the group replication. But it must catch up with the latest transaction in the group. When it catches up with the latest transaction in the group, it will become an online member of this group. Note: The longer it takes to upgrade the server (that is, the longer it takes to leave the group), the greater the difference between the data in the server and the group, and the time required to add it back to the group. The more (because there may be more transactions to catch up).
When the upgraded Server joins a group, if it is found that the members of the group are running an older version of MySQL Server, the upgraded Server will set its system variable super_read_only to on when it rejoins the group. This can ensure that no new data will be written in the newly upgraded server before all members are upgraded to the new version (prevent the data written in the new version of the server from being incompatible with the old version of the server). In a multi-master mode group, when the group upgrade is completed and ready to provide external services, members who intend to be writable master mode must be set to read-write mode. Starting from MySQL 8.0.17, when all members of a group are upgraded to the same version, all members are automatically set to read-write mode. But for earlier versions, you must manually set each member that needs to perform read and write operations to read and write mode. Set by the following statement:
root@localhost : (none):30: > SET GLOBAL super_read_only=OFF; set global read_only=OFF;
Query OK, 0 rows affected (0.00 sec)
7.3.3. Online upgrade method for group replication
There are several options for online update of group replication, which can be selected according to your actual situation.
7.3.3.1. Rolling upgrade within the group
Rolling upgrade within the group: refers to the group members are removed from the group one by one, perform in-situ upgrade (no need to migrate data, do not need to replace the server), and then rejoin the group after the upgrade is completed. During the upgrade process, the group can provide read and write services to the outside world, but the members who are removed from the group and perform the upgrade do not carry any workload during the upgrade process (read-only or read-write services are not provided). After the upgrade is completed, when rejoining the group, if there are members with a lower version number in the group, it will rejoin the group in a read-only mode (only read-only services are provided at this time). Whether the newly added members need to change from read-only mode to read-write mode in the future depends on whether the group is running in single-master mode or multi-master mode.
Single-primary mode: the rolling upgrade method within the group is very suitable for the single-primary mode group. In the single-primary mode, when performing a rolling upgrade, the secondary nodes (read-only nodes) will be upgraded one by one, and the primary node (read-write node) Finally perform the upgrade, so that during the entire upgrade process, you can avoid re-election as much as possible. Of course, in the final upgrade of the main node, it is unavoidable to re-elect the master. However, according to this recommended order, the re-election will only happen once, that is, it will be triggered when the main node is removed from the group and the upgrade is performed Re-elect the master once. When the last member (that is, the previous primary node) is upgraded, you can use the group_replication_set_as_primary() UDF to reassign it as the primary node. Of course, if you don't mind which group member is the main node, you can reassign the main node without using UDF. For the master selection strategy in single master mode, please refer to "1.3.1 Single master mode" for details.
Multi-primary mode: For a group in multi-primary mode, there may be multiple primary nodes (read and write nodes). When using rolling upgrade within the group, there is no specific update order rule (the order of updating members can be determined according to the actual situation). However, before all members in the group are updated to the latest version, when the updated members rejoin the group, they will be forced to be set to read-only mode (set the system variable super_read_only=ON because there are members with lower versions in the group. Note: When super_read_only=ON, read_only will be automatically set to ON, but when super_read_only=OFF, read_only will not be automatically set to OFF), because multiple nodes in a multi-master mode group can provide read and write services at the same time So, in this case, the write availability of the group will gradually decrease until all members in the group are updated to the latest version. When all members in the group are updated to the latest version, if the MySQL Server version number is less than 8.0.16, it will be forced to be a group member in read-only mode. You need to manually set the system variables super_read_only=OFF, read_only=OFF to disable Read (back to read-write mode). If the MySQL Server version number is greater than or equal to 8.0.17, after all members are updated to the new version, the system variables super_read_only=OFF, read_only=OFF will be automatically set to turn off read-only (return to read-write mode). For version compatibility in multi-master mode, please refer to "1.3.2.3. Version Compatibility" for details.
For complete information about version compatibility in a group and how it affects the behavior of the group during the upgrade process, see "7.1. Compatible members of different versions in a group".
PS: In a rolling upgrade plan within a group, group members rejoin the original group after the upgrade is completed.
7.3.3.2. Migration and rolling upgrade
Migration rolling upgrade: refers to the group members are removed from the group one by one, and after the upgrade is performed, they do not rejoin the original group, but use the upgraded members to create a second group (new group). For a group running in multi-master mode, the number of main nodes (read and write nodes) will gradually decrease during this process, resulting in reduced write availability. However, for a group running in single-primary mode, this will not affect the write availability of the group (but when the read-write node is upgraded at the end of the group, the application needs to perform a write request switch between the old and the new group, and the application will be affected at this time).
In the process of upgrading the group, because the group running the old version is always online (continuously providing read-write and read-only services to the outside world), the new group composed of members with the updated version must catch up with the upgrade process. Any newly written transactions in the group. Therefore, it is necessary to select a member in the new group as the slave library, and establish an asynchronous master-slave replication channel with the main node (read-write node) in the old group to catch up with the latest data. In order to avoid accidents in catching up with data through asynchronous replication channels, it is necessary to ensure that the system configuration parameters related to group replication and master-slave replication between the old and new groups are completely consistent. For a group operating in single-master mode, the member of the slave library in the new group must be the primary node (read-write node) in the new group. For a group operating in multi-master mode, the member of the slave library in the new group can be a new Any member of the group (read-write node).
The entire upgrade process is roughly as follows:
Remove members from the original group running the old version one by one, see "7.3.2. Upgrading Group Copy Members".
Upgrade the MySQL Server version running on the members of the excluded group. For the upgrade steps, refer to "A Formula for MySQL Performance Optimization Pyramid". Chapter 2 Two commonly used upgrade methods for MySQL.
Create a new group with the members of the group upgraded to the new version. The steps to deploy the new group are detailed in "2. Group Copy Installation and Deployment". It should be noted that because the old group is running, you need to give the new group a new group name, and use the first upgraded member to guide the new group, and the subsequent upgraded members can join the new group.
Set up an asynchronous replication channel between the old group and the new group. Set the main node in the old group as the master library for asynchronous replication, and configure the main node in the new group as the slave library for GTID replication.
Before redirecting (switching) the application to the new group, you must ensure that the new group has an appropriate number of group members so that the new group can respond normally when a member fails. You can view the group size of the old group and the new group by querying the group member view through the performance_schema.replication_group_members table in any member of the new group. After ensuring this information, you can block data writing in the old group (you need to observe the difference between the old and new groups). Asynchronous replication delay between the time, this step can be performed when the delay is not large), and wait for the new group to catch up with the latest data in the old group until the new group catches up with all the data in the old group, and then switch the application to the new group , And delete the asynchronous replication connection between the old and the new group. Finally, upgrade all the group members of the old version. After the upgrade is completed, add them to the new group one by one.
PS: Migrate the rolling upgrade plan. After the group members are upgraded, they will form a new group, and the server (host) is still the original one.
7.3.3.3. Replica rolling upgrade
Rolling copy upgrade: Compared with the two schemes of "rolling upgrade within a group" and "rolling migration upgrade", group members do not need to remove the group from the group. Instead, they use a backup tool to copy the data copies in the group to one. In the new server group, perform the upgrade one by one, and create a second group (new group). During the upgrade, because the old group continues to provide services online, the incremental data between the new and old groups needs to be passed between the new and old groups. Establish an asynchronous replication channel for data synchronization (for the requirements for creating an asynchronous replication channel between the old and new groups, see "7.3.3.2. Migration and rolling upgrade" for details). When the new group catches up with the latest data in the old group, it will be applied The access of the program is switched to the new group. For groups running in multi-master mode, the number of primary nodes (read and write nodes) will not be reduced during the upgrade process, so the availability of writes will not be affected (therefore, this upgrade method is very suitable for groups running in multi-master mode) . For groups running in single-primary mode, write availability is also not affected.
The entire upgrade process is roughly as follows:
Use the new version of the Server package to initialize and install the new server. It is necessary to ensure that the number of members of the new version can respond normally when a member fails. Note that there is no need to create a group on the new version of the server at this time, just use the new version of the package to initialize and install the database Server, and ensure that the Server can start normally.
Back up the existing data (full backup) from a member of the original group. For the detailed steps of backup, please refer to "4.6. Use backup data to restore failed members or expand new members in group replication".
Use the backup data to restore to the server where you are going to create a new group, and perform an in-place upgrade.
Create a new group with the server upgraded to the new version. The steps to deploy the new group are detailed in "2. Group Copy Installation and Deployment". It should be noted that since the old group is running, you need to give the new group a new group name, and use the first upgraded server to guide the new group, and the subsequent upgraded server can join the new group.
Set up an asynchronous replication channel between the old group and the new group. Set the main node in the old group as the master library for asynchronous replication, and configure the main node in the new group as the slave library for GTID replication.
Once the data in the new group is sufficiently delayed compared to the replication of the old group, the application switch can be performed (redirect application access to the new group), and then the asynchronous replication channel between the old and new groups is deleted (details Refer to "7.3.3.2. Migration and Rolling Upgrade" for application switching requirements).
PS: The copy rolling upgrade scheme, after the group members are upgraded, the group members and servers (hosts) are brand new.
| About the author
Luo Xiaobo·Database Technology Expert
One of the authors of "A Thousand Golden Recipes-MySQL Performance Optimization Pyramid Rule". Familiar with MySQL architecture, good at overall database tuning, like to specialize in open source technology, and keen on the promotion of open source technology, have done many public database topic sharing online and offline, and published nearly 100 database-related research articles.
Further reading
Group Replication Security | A Comprehensive Understanding of MySQL 8.0 Group Replication
Group Replication Monitoring | A Comprehensive Understanding of MySQL 8.0 Group Replication
Group Replication Background | A Comprehensive Understanding of MySQL 8.0 Group Replication
The full text is over.
Enjoy MySQL 8.0 :)
Teacher Ye's "MySQL Core Optimization" class has been upgraded to MySQL 8.0, scan the code to start the journey of MySQL 8.0 practice