Single vs Multiple Master
The default mode for group replication is actually the single master configuration.
This is based on the default setting of:
group_replication_single_primary_mode=ON
So once there is a chosen primary node, it becomes the read/write master, and the rest become the read-only secondary nodes.
For the multi-master replication, this means that the election process is done for every node and becomes read/write enabled.
For this to happen, you would disable the option using:
group_replication_single_primary_mode=OFF
What is MySQL shell for?
MySQL Shell adds a practical layer to manage the whole solution, start/stop nodes, recover the deployment in case of outage etc.
It is possible to administer a MySQL Group Replication setup by developing customer scripts for managing the group. Nevertheless, if on one side it is good to train on the basic functionalities and features of GR, using MySQL Shell adds simplicity to administer the group.
By using MySQL Shell, it is also possible to develop Python or Javascript procedure to perform tasks, find out how scripting work with Shell on the manual. By using powerful Shell scripting features, scripts are much safer, more expressive, and clear to understand.
Important to remember, that if MySQL Shell is adopted, this decision must be coherent for all instances in the cluster.
So either all nodes are set using MySQL Shell, or none.
Binary Log Active. Set --log-bin[=log_file_name]. MySQL Group Replication replicates binary log contents, therefore the binary log needs to be on for it to operate. This option is enabled by default. See Section 5.4.4, “The Binary Log”.
Slave Updates Logged. Set --log-slave-updates. Servers need to log binary logs that are applied through the replication applier. Servers in the group need to log all transactions that they receive and apply from the group. This is required because recovery is conducted by relying on binary logs form participants in the group. Therefore, copies of each transaction need to exist on every server, even for those transactions that were not initiated on the server itself. This option is enabled by default.
Binary Log Row Format. Set --binlog-format=row. Group Replication relies on row-based replication format to propagate changes consistently among the servers in the group. It relies on row-based infrastructure to be able to extract the necessary information to detect conflicts among transactions that execute concurrently in different servers in the group. See Section 17.2.1, “Replication Formats”.
Binary Log Checksums Off. Set --binlog-checksum=NONE. Due to a design limitation of replication event checksums, Group Replication cannot make use of them, and they must be disabled.
Global Transaction Identifiers On. Set --gtid-mode=ON. Group Replication uses global transaction identifiers to track exactly which transactions have been committed on every server instance and thus be able to infer which servers have executed transactions that could conflict with already committed transactions elsewhere. In other words, explicit transaction identifiers are a fundamental part of the framework to be able to determine which transactions may conflict. See Section 17.1.3, “Replication with Global Transaction Identifiers”.
Replication Information Repositories. Set --master-info-repository=TABLE and --relay-log-info-repository=TABLE. The replication applier needs to have the master information and relay log metadata written to the mysql.slave_master_info and mysql.slave_relay_log_info system tables. This ensures the Group Replication plugin has consistent recoverability and transactional management of the replication metadata. From MySQL 8.0.2, these options are set to TABLE by default, and from MySQL 8.0.3, the FILE setting is deprecated. See Section 17.2.4.2, “Slave Status Logs”.
Transaction Write Set Extraction. Set --transaction-write-set-extraction=XXHASH64 so that while collecting rows to log them to the binary log, the server collects the write set as well. The write set is based on the primary keys of each row and is a simplified and compact view of a tag that uniquely identifies the row that was changed. This tag is then used for detecting conflicts. This option is enabled by default.
Multithreaded Appliers. Group Replication members can be configured as multithreaded slaves, enabling transactions to be applied in parallel. A nonzero value for slave_parallel_workers enables the multithreaded applier on the member, and up to 1024 parallel applier threads can be specified. Setting slave_preserve_commit_order=1 ensures that the final commit of parallel transactions is in the same order as the original transactions, as required for Group Replication, which relies on consistency mechanisms built around the guarantee that all participating members receive and apply committed transaction in the same order. Finally, the setting slave_parallel_type=LOGICAL_CLOCK, which specifies the policy used to decide which transactions are allowed to execute in parallel on the slave, is required with slave_preserve_commit_order=1. Setting slave_parallel_workers=0 disables parallel execution and gives the slave a single applier thread and no coordinator thread. With that setting, the slave_parallel_type and slave_preserve_commit_order options have no effect and are ignored.