The document presents an overview of group replication in MySQL 8.0, detailing its architecture, modes, and monitoring features essential for high availability and fault tolerance. It explains group replication services, including failure detection and recovery management, while highlighting the communication protocols and conditions for utilizing online UDFs. Additionally, the document covers primary member change scenarios and the election algorithm used for primary selection within the group.

1. Group Replication In MYSQL 8.0
A walk through
Presented by
VIGNESH PRABHU S
www.mydbops.com info@mydbops.com

2. About Mydbops
● Founded in 2015, HQ in Bangalore India with 450+ customer base across the globe.
● Mydbops is on Database Consulting with core specialization on MySQL ,MongoDB & PostgreSQL
Administration and Support.
● We have expert team with 30+ certified DBA’s providing full time support and currently managing 300+
servers on cloud.
● Mydbops was created with a motto of developing a Devops model for Database administration offering
24*7 expert remote DBA support.
● We help organisations to architect and scale systems in MySQL/Mongo by implementing the advanced
technologies in industry which are completely open source.
● We are a leading solution provider in the market for all sort of cloud based deployments and management.

3. Agenda
● Group Replication - Introduction
● Group Replication - Architecture
● Group Replication - Monitoring
● Group Replication - Modes
● Primary Member Change - Cases
● Primary Election Algorithm
● Conditions for using online UDF
● Communication Protocol
● Transaction Consistency

4. Group Replication - Introduction
● High Availability Solution
● To create a fault tolerant System.
● Supports Server side failover.
● Client side failover is not supported by GR.
● Distributed functionality.
● Based on the GCS protocol and paxos algorithm.
● Split brain issue is avoided by Quorum.

5. Group Replication - Introduction
Services of Group Replication:-
● Group Membership (VIEW)
● Failure Detection (Detect the failure & update the VIEW)
● Fault-tolerance ( QUORUM condition n = 2 x f + 1. )
● Monitoring ( performance schema tables )
All these Services are built into the GCS Protocol.

6. Group Replication - Architecture

7. Group Replication - Architecture
Functionality of Each Component:-
● Capture :Keep track of all the local transactions.
● Applier :Remote transactions.
● Recovery :Manage the distributed recovery.
● Replication :Define the replication protocol & handle the
conflict detection in the group.
● GCS & Xcom :GR Services & communication protocol.

8. Group Replication - ( Commit )

9. Group Replication - Monitoring
Tables in Perf schema:-
● replication_group_member_stats ( info about certification process)
● replication_group_members ( info about the group members )
● replication_connection_status ( info about the queue )
● replication_applier_status ( shows state of replication worker
thread )
Replication Channel:-
● group_replication_recovery - ( Channel for the recovery process)
● group_replication_applier - ( transactions from the other members
or from the group )

10. Group Replication - Monitoring
Group Replication Server States:-
● Online :will accept the connection from the client.
● Recovering :Applying the events from the donor.
● Offline :Member doesn’t belong to any group.
● ERROR :Member is in the group but not working properly.
“group_replication_exit_state_action”
● UNREACHABLE :It is mostly because of the network failure.

11. Group Replication - Modes
● Based on the variable - (group_replication_single_primary_mode)
● Single Primary Mode
○ One member accept the writes.
○ group_replication_enforce_update_everywhere_checks (off)
● Multi Primary Mode
○ All the members can accept the writes.
○ group_replication_enforce_update_everywhere_checks (ON)

12. Group Replication - Modes
● From MySQL version 8.0.13 we can change the modes in
online Using the UDF’s
○ group_replication_switch_to_single_primary_mode()
○ group_replication_switch_to_multi_primary_mode()
● From Version 8.0.13 to 8.0.16, no check for the safeguard.
● From Version 8.0.17, GR has safeguard check.
○ (i.e) Lower MySQL version member will become the
Primary.

13. Primary Member Change - Cases
● Primary leaves the group .
● While Changing the primary member manually using UDF.
● While Changing the multi primary to single primary.

14. Primary Election Algorithm
First Election Check:-
● Ordering based on MySQL major Version & patch Version.
Second Election Check:-
● Based on lowest member weight. ( group_replication_member_weight ).
Third Election Check:-
● Based on the lowest server UUID.

15. Conditions for using online UDF
1. All members must be in ONLINE state
2. No members can join in the group during a configuration change.
3. Only one configuration at once.
4. All members must be running MySQL 8.0.13 or higher

16. Communication Protocol
● From MySQL 8.0.16, Configure different versions of MySQL members.
● Group must use same communication protocol Version.
Reason:-
● From MySQL 5.7.14, allow compression of messages
● From MySQL 8.0.16, allow fragmentation of messages
Functions:-
● group_replication_get_communication_protocol();
● group_replication_set_communication_protocol(“version”);

17. Transaction Consistency.
● Controlled by group_replication_consistency variable.
○ EVENTUAL
○ BEFORE_ON_PRIMARY_FAILOVER
○ BEFORE ( RO trx wait for preceding trx to apply )
○ AFTER ( RW trx wait for preceding trx to apply in other members )
○ BEFORE_AND_AFTER

18. Email Us : Info@mydbops.com
Thank you