Then each member needs to be able to connect to the other members on their group_replication_local_address . For example in the option file of member s1 add: 

group_replication_local_address= "127.0.0.1:24901" group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903" 

This configures s1 to use port 24901 for internal group communication with seed members. For each server instance you want to add to the group, make these changes in the option file of the member. For each member you must ensure a unique address is specified, so use a unique port per instance for group_replication_local_address . Usually you want all members to be able to serve as seeds for members that are joining the group and have not got the transactions processed by the group. In this case, add all of the ports to group_replication_group_seeds  as shown above. 

The remaining steps of Section 18.2.1, “Deploying Group Replication in Single-Primary Mode”  apply equally to a group which you have deployed locally in this way. 

## 18.3 Requirements and Limitations 

This section lists and explains the requirements and limitations of Group Replication. 

## 18.3.1 Group Replication Requirements 

Server instances that you want to use for Group Replication must satisfy the following requirements. 

## Infrastructure 

• InnoDB Storage Engine.  Data must be stored in the InnoDB  transactional storage engine. Transactions are executed optimistically and then, at commit time, are checked for conflicts. If there are conflicts, in order to maintain consistency across the group, some transactions are rolled back. This means that a transactional storage engine is required. Moreover, InnoDB  provides some additional functionality that enables better management and handling of conflicts when operating together with Group Replication. The use of other storage engines, including the temporary MEMORY  storage engine, might cause errors in Group Replication. You can prevent the use of other storage engines by setting the disabled_storage_engines  system variable on group members, for example: 

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" 

• Primary Keys.  Every table that is to be replicated by the group must have a defined primary key, or primary key equivalent where the equivalent is a non-null unique key. Such keys are required as a unique identifier for every row within a table, enabling the system to determine which transactions conflict by identifying exactly which rows each transaction has modified. Group Replication has its own built-in set of checks for primary keys or primary key equivalents, and does not use the checks carried out by the sql_require_primary_key  system variable. You may set sql_require_primary_key=ON  for a server instance where Group Replication is running, and you may set the REQUIRE_TABLE_PRIMARY_KEY_CHECK  option of the CHANGE REPLICATION SOURCE TO  | CHANGE MASTER TO  statement to ON  for a Group Replication channel. However, be aware that you might find some transactions that are permitted under Group Replication’s built-in checks are not permitted under the checks carried out when you set sql_require_primary_key=ON  or REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON . 

• Network Performance.  MySQL Group Replication is designed to be deployed in a cluster environment where server instances are very close to each other. The performance and stability of a group can be impacted by both network latency and network bandwidth. Bi-directional communication must be maintained at all times between all group members. If either inbound or outbound communication is blocked for a server instance (for example, by a firewall, or by connectivity issues), the member cannot function in the group, and the group members (including the member with issues) might not be able to report the correct member status for the affected server instance. 

