#### 18.5.1.4 Setting a Group's Communication Protocol Version

[]()

 From MySQL 8.0.16, Group Replication has the concept of a communication protocol for the group. The Group Replication communication protocol version can be managed explicitly, and set to accommodate the oldest MySQL Server version that you want the group to support. This enables groups to be formed from members at different MySQL Server versions while ensuring backward compatibility.

* Versions from MySQL 5.7.14 allow compression of messages (see [Section 18.7.4, “Message Compression”](group-replication-message-compression.html)).

* Versions from MySQL 8.0.16 also allow fragmentation of messages (see [Section 18.7.5, “Message Fragmentation”](group-replication-performance-message-fragmentation.html) ).

* Versions from MySQL 8.0.27 also allow the group communication engine to operate with a single consensus leader when the group is in single-primary mode and group\_replication\_paxos\_single\_leader is set to true (see [Section 18.7.3, “Single Consensus Leader”](group-replication-single-consensus-leader.html) ).

 All members of the group must use the same communication protocol version, so that group members can be at different MySQL Server releases but only send messages that can be understood by all group members.

 A MySQL server at version X can only join and reach `ONLINE` status in a replication group if the group's communication protocol version is less than or equal to X. When a new member joins a replication group, it checks the communication protocol version that is announced by the existing members of the group. If the joining member supports that version, it joins the group and uses the communication protocol that the group has announced, even if the member supports additional communication capabilities. If the joining member does not support the communication protocol version, it is expelled from the group.

 If two members attempt to join in the same membership change event, they can only join if the communication protocol version for both members is already compatible with the group's communication protocol version. Members with different communication protocol versions from the group must join in isolation. For example:

* One MySQL Server 8.0.16 instance can successfully join a group that uses the communication protocol version 5.7.24.

* One MySQL Server 5.7.24 instance cannot successfully join a group that uses the communication protocol version 8.0.16.

* Two MySQL Server 8.0.16 instances cannot simultaneously join a group that uses the communication protocol version 5.7.24.

* Two MySQL Server 8.0.16 instances can simultaneously join a group that uses the communication protocol version 8.0.16.

 You can inspect the communication protocol in use by a group by using the [`group_replication_get_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-get-communication-protocol) function, which returns the oldest MySQL Server version that the group supports. All existing members of the group return the same communication protocol version. For example:

```
SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16                                         |
+------------------------------------------------+
```

 Note that the [`group_replication_get_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-get-communication-protocol) function returns the minimum MySQL version that the group supports, which might differ from the version number that was passed to the [`group_replication_set_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-set-communication-protocol) function, and from the MySQL Server version that is installed on the member where you use the function.

 If you need to change the communication protocol version of a group so that members at earlier releases can join, use the [`group_replication_set_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-set-communication-protocol) function to specify the MySQL Server version of the oldest member that you want to allow. This makes the group fall back to a compatible communication protocol version if possible. The [`GROUP_REPLICATION_ADMIN`](privileges-provided.html#priv_group-replication-admin) privilege is required to use this function, and all existing group members must be online when you issue the statement, with no loss of majority. For example:

```
SELECT group_replication_set_communication_protocol("5.7.25");
```

 If you upgrade all the members of a replication group to a new MySQL Server release, the group's communication protocol version is not automatically upgraded to match. If you no longer need to support members at earlier releases, you can use the [`group_replication_set_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-set-communication-protocol) function to set the communication protocol version to the new MySQL Server version to which you have upgraded the members. For example:

```
SELECT group_replication_set_communication_protocol("8.0.16");
```

 The [`group_replication_set_communication_protocol()`](group-replication-functions-for-communication-protocol.html#function_group-replication-set-communication-protocol) function is implemented as a group action, so it is executed at the same time on all members of the group. The group action starts buffering messages and waits for delivery of any outgoing messages that were already in progress to complete, then changes the communication protocol version and sends the buffered messages. If a member attempts to join the group at any time after you change the communication protocol version, the group members announce the new protocol version.

 MySQL InnoDB cluster automatically and transparently manages the communication protocol versions of its members, whenever the cluster topology is changed using AdminAPI operations. An InnoDB cluster always uses the most recent communication protocol version that is supported by all the instances that are currently part of the cluster or joining it. For details, see [InnoDB Cluster and Group Replication Protocol](https://dev.mysql.com/doc/mysql-shell/8.0/en/monitoring-innodb-cluster.html#innodb-cluster-group-replication-protocol).

