In this mode the group has a single-primary server that is set
to read-write mode. All the other members in the group are set
to read-only mode (with
). This happens automatically. The primary is typically the
first server to boostrap the group, all other servers that join
automatically learn about the primary server and are set to read
When in single-primary mode, some of the checks deployed in multi-primary mode are disabled, because the system enforces that only a single writer server is in the group at a time. For example, changes to tables that have cascading foreign keys are allowed, whereas in multi-primary mode they are not. Upon primary member failure, an automatic primary election mechanism chooses the next primary member. The next primary is selected by ordering the remaining servers lexicographically (using their UUID) and picking the first member in the list.
In the event that the primary member leaves the group, then an election is performed and a new primary is chosen from the remaining servers in the group. This election is performed by looking at the new view, ordering the server UUIDs in lexicographical order and by picking the first one. Once a new primary is elected, it is automatically set to read-write and the other secondaries remain as secondaries, and as such, read-only.
It is a good practice to wait for the new primary to apply its replication related relay-log before re-routing the client applications to it.