Multi-Primary and Single-Primary Modes The factors considered by members when electing a primary, in order, are as follows: 1. The first factor considered is which member or members are running the lowest MySQL Server version. If all group members are running MySQL 8.0.17 or higher, members are first ordered by the patch version of their release. If any members are running MySQL Server 5.7 or MySQL 8.0.16 or lower, members are first ordered by the major version of their release, and the patch version is ignored. 2. If more than one member is running the lowest MySQL Server version, the second factor considered is the member weight of each of those members, as specified by the group_replication_member_weight  system variable on the member. If any member of the group is running MySQL Server 5.7, where this system variable was not available, this factor is ignored. 3. If more than one member is running the lowest MySQL Server version, and more than one of those members has the highest member weight (or member weighting is being ignored), the third factor considered is the lexographical order of the generated server UUIDs of each member, as specified by the  server_uuid  system variable. The member with the lowest server UUID is chosen as the primary. This factor acts as a guaranteed and predictable tie-breaker so that all group members reach the same decision if it cannot be determined by any important factors. The  group_replication_member_weight  system variable specifies a number in the range 0-100. All members default to a weight of 50, so set a weight below this to lower their ordering, and a weight above it to increase their ordering. You can use this weighting function to prioritize the use of better hardware or to ensure failover to a specific member during scheduled maintenance of the primary. To find out which server is currently the primary when deployed in single-primary mode, use the MEMBER_ROLE  column in the  performance_schema.replication_group_members  table. For example: mysql>  SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members; +-------------------------+-------------+ | MEMBER_HOST | MEMBER_ROLE | +-------------------------+-------------+ | remote1.example.com | PRIMARY | | remote2.example.com | SECONDARY | | remote3.example.com | SECONDARY | +-------------------------+-------------+ mysql>  SHOW STATUS LIKE ’group_replication_primary_member’ 3695 If a member stops accepting write transactions, for example, in the event of an unexpected server exit, clients connected to it can be redirected, or failed over, to any other member that is in read-write mode. Group Replication does not handle client-side failover itself, so you need to arrange this using a middleware framework such as MySQL Router 8.0, a proxy, a connector, or the application itself. In multi-primary mode ( group_replication_single_primary_mode=OFF ) no member has a special role. Any member that is compatible with the other group members is set to read-write mode when joining the group, and can process write transactions, even if they are issued concurrently. 18.1.3.2 Multi-Primary Mode The  group_replication_primary_member  status variable has been deprecated and is scheduled to be removed in a future version. Alternatively use the  group_replication_primary_member  status variable. Warning Finding the Primary