MySQL 5.7 and Innodb cluster : Must read series – Part 1

1.Cluster status - Extended information

In version 5.7 cluster.status() does not include replication lag or the recovery status of nodes in a cluster. Lets say you are noticing intermittent lag , you need to use commands like “show slave status for channel ‘group_replication_recovery’\G” to understand how the recovery is progressing

In version 8 we have options to get more information about cluster. Cluster.status({‘extended’:value}) is the command to use to get additional information . Value can be any of the below :

Cluster.status({‘extended’:1}) : includes information about the Group Replication Protocol Version, Group name, cluster member UUIDs, cluster member roles and states as reported by Group Replication, and the list of fenced system variables

Cluster.status({‘extended’:2}) : includes information about transactions processed by connection and applier

Cluster.status({‘extended’:3}) : includes more detailed statistics about the replication performed by each cluster member.

NOTE: Upgrading shell to version 8.0 might be sufficient to get extended information

2. Changing primary node :

In 5.7 you can not change the primary of a given cluster easily. Lets say you have node A, node B and node C in a cluster . Currently node A is the primary node in cluster and you want to promote node C as master now , only way to do that is to run “stop group_replication” until the desired node is master . Or another way of approaching it in 5.7 is by changing the weight of member

In version 8.0 you can do that by using ‘select group_replication_set_as_primary(member_uuid);’

3. Clone feature :

Cloning is introduced in version 8 . In version 5.7 it is hard to resync a broken node . Imagine using mysqldump to resync a broken cluster . Xtrabackup is better in this case but cloning is even better. Also during the cluster initialization process , cloning makes it easy to add nodes into cluster

4. Network glitches and large transactions

In 5.7 cluster nodes can get expelled easily due to network glitches or transaction sizes . There is no easy way to automatically fix a broken cluster. Version 8 introduces various variables to deal with network glitches :

Auto-rejoin-retries: You can set this variable to 3 to try for 3 times before expelling a node

Group_replication_member_expel_timeout: By deafult this is set to zero which means that suspected member is liable for expulsion immediately after the 5-second detection period ends

Group_replication_communication_max_message_size: Message fragmentation is improved in version 8

5. Deployment procedure:

Deployment procedure is very much simplified in version 8 . For example SET PERSIST was introduced in version 8 which makes it easy to persist config changes . Before the introduction of SET PERSIST we had to manually issue dba.configureLocalInstance()on all nodes

NOTE : Please read Part 2 here

Share this Post :