From MySQL 8.0.14, you can use an IPv4 or IPv6 network infrastructure, or a mix of the two, for TCP communication between remote Group Replication servers. There is also nothing preventing Group Replication from operating over a virtual private network (VPN). 

Also from MySQL 8.0.14, where Group Replication server instances are co-located and share a local group communication engine (XCom) instance, a dedicated input channel with lower overhead is used for communication where possible instead of the TCP socket. For certain Group Replication tasks that require communication between remote XCom instances, such as joining a group, the TCP network is still used, so network performance influences the group’s performance. 

## Server Instance Configuration 

The following options must be configured as shown on server instances that are members of a group. 

• Unique Server Identifier.  Use the server_id  system variable to configure the server with a unique server ID, as required for all servers in replication topologies. The server ID must be a positive integer between 1 and (2$^{32}$) − 1, and it must be different from every other server ID in use by any other server in the replication topology. 

• Binary Log Active.  Set --log-bin[=log_file_name] . From MySQL 8.0, binary logging is enabled by default, and you do not need to specify this option unless you want to change the name of the binary log files. Group Replication replicates the binary log’s contents, therefore the binary log needs to be on for it to operate. See Section 5.4.4, “The Binary Log” . 

• Replica Updates Logged.  Set log_slave_updates=ON . From MySQL 8.0, this setting is the default, so you do not need to specify it. Group members need to log transactions that are received from their donors at joining time and applied through the replication applier, and to log all transactions that they receive and apply from the group. This enables Group Replication to carry out distributed recovery by state transfer from an existing group member’s binary log. 

• Binary Log Row Format.  Set binlog_format=row . This setting is the default, so you do not need to specify it. Group Replication relies on the row-based replication format to propagate changes consistently among the servers in the group, and extract the necessary information to detect conflicts among transactions that execute concurrently in different servers in the group. From MySQL 8.0.19, the REQUIRE_ROW_FORMAT  setting is automatically added to Group Replication’s channels to enforce the use of row-based replication when the transactions are applied. See Section 17.2.1, “Replication Formats”  and Section 17.3.3, “Replication Privilege Checks” . 

• Binary Log Checksums Off (to MySQL 8.0.20).  Up to and including MySQL 8.0.20, set binlog_checksum=NONE . In these releases, Group Replication cannot make use of checksums and does not support their presence in the binary log. From MySQL 8.0.21, Group Replication supports checksums, so group members may use the default setting binlog_checksum=CRC32 , and you do not need to specify it. 

• Global Transaction Identifiers On.  Set gtid_mode=ON  and enforce_gtid_consistency=ON . These settings are not the defaults. GTID-based replication is required for Group Replication, which uses global transaction identifiers to track the transactions that have been committed on every server instance in the group. See Section 17.1.3, “Replication with Global Transaction Identifiers” . 

• Replication Information Repositories.  Set master_info_repository=TABLE  and relay_log_info_repository=TABLE . In MySQL 8.0, these settings are the default, and the FILE setting is deprecated. From MySQL 8.0.23, the use of these system variables is deprecated, so omit the system variables and just allow the default. The replication applier needs to have the replication metadata written to the mysql.slave_master_info  and mysql.slave_relay_log_info system tables to ensure the Group Replication plugin has consistent recoverability and transactional management of the replication metadata. See Section 17.2.4.2, “Replication Metadata Repositories” . 

