MySQL InnoDB Cluster - Advanced Configuration & Operations

Pedro Gomes
MySQL Senior Software Developer
Frédéric Descamps
MySQL Community Manager
EMEA & APAC
MySQL InnoDB Cluster
Advanced Configuration &
Operations

2 / 161

Safe Harbor
The following is intended to outline our general product direction. It is intended for information purpose only, and
may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality,
and should not be relied up in making purchasing decisions. The development, release, timing and pricing of any
features or functionality described for Oracle´s product may change and remains at the sole discretion of Oracle
Corporation.
Statement in this presentation relating to Oracle´s future plans, expectations, beliefs, intentions and ptospects
are "forward-looking statements" and are subject to material risks and uncertainties. A detailed discussion of
these factors and other risks that a ect our business is contained in Oracle´s Securities and Exchange
Commission (SEC) lings, including our most recent reports on Form 10-K and Form 10-Q under the heading
"Risk Factors". These lings are available on the SEC´s website or on Oracle´s website at
h p://www.oracle.com/investor. All information in this presentation is current as of September 2019 and Oracle
undertakes no duty to update any statement in light of new information or future events.
Copyright @ 2019 Oracle and/or its affiliates.
3 / 161

about us
Who are we ?
4 / 161

Pedro Gomes
@distributedpete
MySQL Replication Developer
MySQL Developer since 2012
Portuguese born and raised 🇵🇹
h ps://mysqlhighavailability.com
5 / 161

Frédéric Descamps
@lefred
MySQL Evangelist
Managing MySQL since 3.23
devops believer
living in Belgium 🇧🇪
h ps://lefred.be
6 / 161

New Member Provisioning & Recovery
7 / 161

Provisioning VS Recovery
Provisioning a server is the process of con guring and adding data to a server, which
can then potentially be used in a replication topology. Typically, this involves restoring a
backup or snapshot into a given instance.
The distributed recovery is the protocol that runs when a server is added to a cluster, so
that the new server nds a state donor, fetches missing state and synchronizes with the
rest of the cluster automatically.
As of MySQL 8.0.17, the distributed recovery protocol for Group Replication is able to
automatically orchestrate provisioning, in addition to using binary logs, in the process of
synchronizing the new instance with the rest of the group
8 / 161

How to Provision a New Member
Incremental Recovery
New node for a recent Cluster
From a Backup
Clone (NEW 8.0.17)
9 / 161

Incremental Recovery
Based on the good old Asynchronous replication
Fetches only the missing data based on the member GTIDs info
Also provides the member with group transactional information
10 / 161

Based on the brand new Clone plugin
Fetches a full snapshot of the donor data
Replaces the server data and requires its
restart
Still requires incremental recovery for
group transactional information

Clone
11 / 161

MySQL InnoDB Cluster Provisioning
binlog binlog
12 / 161

binlog binlog
13 / 161

binlog binlog
14 / 161

binlog binlog
15 / 161

binlog binlog
16 / 161

binlog binlog
hello, I would
like to join !
17 / 161

binlog binlog
I have no
data yet !
18 / 161

binlog binlog
19 / 161

binlog binlog
Option 1: Incremental
donor joiner
binlog
20 / 161

binlog binlog
donor joiner
binlog
21 / 161

binlog binlog
donor joiner
binlog
22 / 161

binlog binlog
binlog
23 / 161

24 / 161

binlog binlog
Option 2: Clone
binlog
donor joiner
clone
25 / 161

binlog binlog
Option 2: Clone
binlog
donor joiner
clone
26 / 161

binlog binlog
hello, I would
like to join !
binlog
27 / 161

binlog binlog
hello, I would
like to join !
binlog
And I have
no data yet !
28 / 161

binlog binlog
We are not
able to provide
you incremental data !
Use CLONE !
binlog
29 / 161

binlog binlog
donor joiner
clone
binlog
30 / 161

binlog binlog binlog
31 / 161

32 / 161

restored
backup
What kind of provisioning will happen ?
33 / 161

restored
backup
Incremental Recovery !
What kind of provisioning will happen ?
34 / 161

35 / 161

As a DBA, I want to force the use of Clone when adding an instance even if
Incremental Recovery is possible.
36 / 161

Just specify it in the MySQL Shell:
As a DBA, I want to force the use of Clone when adding an instance even if
Incremental Recovery is possible.
37 / 161

Recovery Process
The recovery process happens when a previous member joins back a Cluster/Group.
By default and if possible (based on GTID set), the Incremental Recovery method is used.
However, sometimes applying a large amount of binary log events might be slower than
performing a Clone. You have the possibility to con gure the treshold:
group_replication_clone_threshold (default is 9223372036854775807 !):
38 / 161

Recovery Process (2)
As a DBA, I want to force the use of Clone when rejoining an instance even if
Incremental Recovery is enough to recover.
39 / 161

It's possible ! You need to connect to the instance you want to rejoin and set
group_replication_clone_threshold to 1.
As Clone will be called and the change is not persisted, no need to set it back to its original
value. Never persist it to 1 or to a really low value on a live Group, never!
As a DBA, I want to force the use of Clone when rejoining an instance even if
Incremental Recovery is enough to recover.
40 / 161

41 / 161

Force a Donor during Clone
As a DBA, I want to add a node (mysql3) but it should only clone from server
mysql2
42 / 161

Force a Donor during Clone
This is again possible, you need to connect on the other members (in this case mysql1 and
unload the clone plugin).
Please note, that to be able to unload the plugin you need to be connected using the
classic protocol (3306).
As a DBA, I want to add a node (mysql3) but it should only clone from server
mysql2
43 / 161

We connect using the classic protocol and
we uninstall the plugin:
Force a Donor during Clone (2)
44 / 161

We connect using the classic protocol and
we uninstall the plugin:
Then we add the instance forcing Clone:
45 / 161

46 / 161

We can also verify this on the new joiner Performance_Schema.clone_status table:
47 / 161

Don't forget to install the Clone plugin again:
48 / 161

Don't forget to install the Clone plugin again:
49 / 161

Monitoring
50 / 161

Monitoring Provisioning & Recovery process
Currently, when the CLONE is triggered within MySQL Shell, you can follow its progress:
51 / 161

And we already saw that the status and the progress is also available in performance_schema
tables on the joiner:
52 / 161

53 / 161

Incremental Recovery process
It's also possible to evaluate the amount of transactions a member needs to process before
being in sync with the Group when joining. You can nd a User-De ned Report to see that
amount :
More Info: h ps://lefred.be/content/mysql-innodb-cluster-recovery-process-monitoring-
with-the-mysql-shell-reporting-framework/
54 / 161

By default the status()
method disables the
extended mode.
It's possible to have much
more information enabling
it.
MySQL InnoDB Cluster - status()
55 / 161

MySQL InnoDB Cluster - status({extended})
The extended option allows 4 values (or boolean):
0: disables the command verbosity (default)
1: includes information about the Group Protocol Version, Group name, cluster member
UUIDs, cluster member roles and states as reported by Group Replication and the list of
fenced system variables
2: includes information about transactions processed by connection and applier
3: includes more detailed stats about the replication machinery of each cluster member
56 / 161

MySQL InnoDB Cluster - status({extended:1})
57 / 161

58 / 161

59 / 161

Monitoring MySQL InnoDB Cluster -
Performance_Schema
Other than the status() in the MySQL Shell, it's possible to get information from
Performance_Schema tables:
60 / 161

Performance_Schema (2)
61 / 161

62 / 161

63 / 161

As a DBA, I would like to know which of my Secondary-Master is slower ?
64 / 161

Performance_Schema provides to us all what we need to discover which Secondary-Slave
takes more time to "fully replicate" events.
As a DBA, I would like to know which of my Secondary-Master is slower ?
65 / 161

Let's run this bash code on all our Secondary-Masters (mysql1 and mysql2):
for i in $(seq 1 10)
do
if [[ $i -eq 1 ]]; then echo "repl delay transport time time to RL apply time"
mysql -BN -e "
SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
'rep delay (sec)',
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
'transport time',
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 'time RL',
LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 'apply time'
FROM performance_schema.replication_applier_status_by_worker t1
JOIN performance_schema.replication_connection_status t2
ON t2.channel_name=t1.channel_name
WHERE t1.channel_name='group_replication_applier'";
sleep 2
done
66 / 161

Let's run this bash code on all our Secondary-Masters (mysql1 and mysql2):
for i in $(seq 1 10)
do
if [[ $i -eq 1 ]]; then echo "repl delay transport time time to RL apply time"
mysql -BN -e "
SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
'rep delay (sec)',
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
'transport time',
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 'time RL',
LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 'apply time'
FROM performance_schema.replication_applier_status_by_worker t1
JOIN performance_schema.replication_connection_status t2
ON t2.channel_name=t1.channel_name
WHERE t1.channel_name='group_replication_applier'";
sleep 2
done
This script will query some performance_schema tables 10 times every 2 seconds (we write
on our cluster every 2 secs), and all members have their time in sync: ntpd.
67 / 161


68 / 161


69 / 161

As a DBA, I would like to estimate how many transactions per second could my
cluster process with the current configuration.
70 / 161

To perform this estimation, we will block all writes to a member of our cluster. As a result,
the apply queue will grow on that server. When the queue is large enough, we will enable
writes again on the node and see how many transactions and how much time the node
needed to process everything and be back in sync with the cluster.
Currently, the application is performing 100 tx/sec.
As a DBA, I would like to estimate how many transactions per second could my
cluster process with the current configuration.
71 / 161

On the node that we will lock, let's run this small bash command:
while true
do
mysql -BNe "select now(), transactions_behind, count_transactions_remote_applied
from sys.gr_member_routing_candidate_status, performance_schema.replication_group_member_stats
where member_id=@@server_uuid;"
sleep 1
done
72 / 161

On the node that we will lock, let's run this small bash command:
while true
do
mysql -BNe "select now(), transactions_behind, count_transactions_remote_applied
from sys.gr_member_routing_candidate_status, performance_schema.replication_group_member_stats
where member_id=@@server_uuid;"
sleep 1
done
73 / 161

74 / 161

75 / 161

So we can estimate that our MySQL InnoDB Cluster is able to process approximately 350
tx/sec.
So what will happen if we increase our workload to 360 tx/sec ?
76 / 161

77 / 161

The cluster will start
slowing down and this
might have a major impact
depending of the
consistency level.

78 / 161

More Info: h ps://lefred.be/content/using-the-new-mysql-
shell-reporting-framework-to-monitor-innodb-cluster/
Monitoring MySQL InnoDB Cluster - MySQL
Shell UDR
It's also possible to constantly monitor the status of your MySQL InnoDB Cluster using
User-De ned Reports in MySQL Shell:
79 / 161

[http_server]
port=8080
[rest_api]
[rest_router]
require_realm=somerealm
[rest_routing]
[rest_metadata_cache]
[http_auth_realm:somerealm]
backend=somebackend
method=basic
name=Some Realm
[http_auth_backend:somebackend]
backend= le
lename=/etc/mysqlrouter/mysqlrouter.pwd
Monitoring MySQL Router
Since MySQL 8.0.17 it's possible to query the MySQL Router using its REST API !
You need to enable it in the Router's con g le:
80 / 161

Monitoring MySQL Router (2)
You can then query the REST API using curl:
$ curl -s -u fred:fred
http://192.168.91.2:8080/api/20190715/routes/myCluster_default_rw/destinations
{"items":[{"address":"mysql2","port":3306}]}
Or use/create a plugin for the MySQL Shell.
More Info:
h ps://lefred.be/content/mysqlrouter-8-0-17-and-the-rest-api/
h ps://lefred.be/content/mysql-router-8-0-17s-rest-api-mysql-shell-extensions/
81 / 161

82 / 161

83 / 161

Network Monitoring
84 / 161

All good ;)
Network monitoring - the basics
85 / 161

When members crash or are expelled
86 / 161

When a majority of the
members becomes
unreachable
87 / 161

Network monitoring - Adapt to faulty networks
To avoid frequent member expels due to faulty networks make use of:
group_replication_member_expel_timeout
88 / 161

Network monitoring - Deal with failure scenarios
Con gure your rejoin a empts for each member (this method persists the change)
89 / 161

Con gure your rejoin a empts for each member (this method persists the change)
If you prefer to not persist it:
90 / 161

Con gure your timeout during loss of quorum
91 / 161

Be prepared: whom shall be the primary when failure strikes
92 / 161

Network monitoring - Adapt to higher latencies
93 / 161

group replication write concurrency
94 / 161

95 / 161

96 / 161

97 / 161

98 / 161

99 / 161

100 / 161

Con gure your write
concurrency in the group

101 / 161

Operations
102 / 161

Upgrading to a newer version
Before upgrading, don't forget to use util.upgradeChecker() in MySQL Shell. This
operation must be performed on the Primary Master:
103 / 161

Upgrading Process
PM SM SM
8.0.16 8.0.16 8.0.16
104 / 161

Upgrading Process
PM SM SM
8.0.16 8.0.16 8.0.16
util.checkForServerUpgrade( )PM
105 / 161

Upgrading Process
PM SM
8.0.16 8.0.16 8.0.16
stop mysqld on a SM
106 / 161

Upgrading Process
PM SM
8.0.16 8.0.16 8.0.17
upgrade MySQL binaries
107 / 161

Upgrading Process
PM SM
8.0.16 8.0.16 8.0.17
start mysqld
108 / 161

Upgrading Process
PM SM
8.0.16 8.0.16 8.0.17
join
the group
109 / 161

Upgrading Process
PM SM SM
8.0.16 8.0.16 8.0.17
110 / 161

Upgrading Process
PM SM
8.0.16 8.0.16 8.0.17
stop mysqld on the other SM
111 / 161

Upgrading Process
PM SM
8.0.16 8.0.17 8.0.17
upgrade the MySQL binaries
112 / 161

Upgrading Process
PM SM
8.0.16 8.0.17 8.0.17
start mysqld
113 / 161

Upgrading Process
PM SM
8.0.16 8.0.17 8.0.17
join
the group
join
the group
114 / 161

Upgrading Process
PM SM SM
8.0.16 8.0.17 8.0.17
115 / 161

Upgrading Process
PM SM
8.0.16 8.0.17 8.0.17
stop mysqld on the PM
116 / 161

Upgrading Process
PM SM
8.0.17 8.0.17 8.0.17
upgrade MySQL binaries
117 / 161

Upgrading Process
PM SM
8.0.17 8.0.17 8.0.17
start myslqd
118 / 161

Upgrading Process
PM SM
8.0.17 8.0.17 8.0.17
join
the group
119 / 161

Upgrading Process
PMSM SM
8.0.17 8.0.17 8.0.17
120 / 161

Upgrading Process Info
The lowest version of a Group must always be the Primary Master
If ejected from the Group, the lowest version instance won't be able to rejoin the Group
again
121 / 161

Downgrading
Downgrading an existing instance won't work as downgrading MySQL Server is not
supported:
[ERROR] [MY-013171] [InnoDB] Cannot boot server version 80016 on data directory built by version 80017.
Downgrade is not supported.
However it's possible to downgrade your MySQL InnoDB Cluster without downtime, by
using a previous backup.
Before 8.0.17, any 8.0.x could join a MySQL InnoDB Cluster 8.0. Since 8.0.17, the minor
version is also checked.
122 / 161

Downgrading (2)
So if you want to have a lower version to join a cluster, you need to set
group_replication_allow_local_lower_version_join to ON on the joiner.
But don't forget that this instance running with a lower version should be promoted to be
the Primary-Master as soon as possible to avoid any possible issues related to protocol and
variable di erences.
123 / 161

Backup
Taking a backup of your MySQL InnoDB Cluster is trivial. You can use exactly the same
method as you are using for a standalone MySQL Server:
Physical (MySQL Enterperise Backup (MEB), Xtrabackup)
Logical (mysqldump, mysqlpump, mydumper)
Snapshot (lvm, MySQL Clone)
124 / 161

Backup (2)
As a DBA using MySQL InnoDB Cluster retains data consistency, I only want to
backup one member of the Group and preferably a Secondary Master, no need
to waste disk space with multiple backups of the same data.
125 / 161

Backup (2)
This is possible ! Let's de ne the best backup solution.
As a DBA using MySQL InnoDB Cluster retains data consistency, I only want to
backup one member of the Group and preferably a Secondary Master, no need
to waste disk space with multiple backups of the same data.
126 / 161

Backup (3)
The perfect backup solution for you MySQL InnoDB Cluster, should then perform the
following steps:
check if the node where the script run is part of the cluster
check if the node is indeed a secondary master
eventually check if the node is lagging behind (large apply queue)
ensure that the backup is not running on another member
127 / 161

Backup (3)
The perfect backup solution for you MySQL InnoDB Cluster, should then perform the
following steps:
check if the node where the script run is part of the cluster
check if the node is indeed a secondary master
eventually check if the node is lagging behind (large apply queue)
ensure that the backup is not running on another member
Here, you can nd a working script calling MEB to use as a cron job :
h ps://lefred.be/content/how-to-backup-your-innodb-cluster/
128 / 161

DDLs
There is nothing special about DDLs. When DDLs are performed, the cluster is not blocked
completely.
Of course, concurent DDLs and DMLs are not a good idea when using a cluster in Multi-
Primary mode.
If you use a Multi-Primary Cluster, you must swicth to Single-Primary mode the time of the
DDL.
Don't forget that MySQL 8.0 supports also Instant DDLs like adding a column.
129 / 161

DDLs on Multi-Primary Clusters
130 / 161

DDLs on Multi-Primary Clusters
131 / 161

Configurable Consistency Guarantees
Consistency Levels
132 / 161

mysql> show variables like
'group_replication_consistency';
+-------------------------------+----------+
| Variable_name | Value |
+-------------------------------+----------+
| group_replication_consistency | EVENTUAL |
+-------------------------------+----------+

Consistency: EVENTUAL (default)
By default, there is no synchronization point for the transactions, when you perform a write
on a node, if you immediately read the same data on another node, it is eventually there.
133 / 161

mysql> show variables like
'group_replication_consistency';
+-------------------------------+----------+
| Variable_name | Value |
+-------------------------------+----------+
| group_replication_consistency | EVENTUAL |
+-------------------------------+----------+

Consistency: EVENTUAL (default)
By default, there is no synchronization point for the transactions, when you perform a write
on a node, if you immediately read the same data on another node, it is eventually there.
Since MySQL 8.0.16, we have the possibility to
set the synchronization point at read or at write or both (globally or for a session).
134 / 161

Consistency: BEFORE (READ)
As a DBA, I want to load balance my reads without deploying additional
restrictions on which server I read from to avoid reading stale data, my group
writes are much more than my group reads.
135 / 161

As a DBA, I want to load balance my reads without deploying additional
restrictions on which server I read from to avoid reading stale data, my group
writes are much more than my group reads.
As a developer, I want specific transactions in my workload to always read up-
to-date data from the group, so that whenever that sensitive data is updated, I
will enforce that reads shall read the most up to date value.
136 / 161

137 / 161

Consistency: AFTER (WRITE)
I want to load balance my reads without deploying additional restrictions on
which server I read from to avoid reading stale data, my group writes are
much less than my group reads.
138 / 161

I want to load balance my reads without deploying additional restrictions on
which server I read from to avoid reading stale data, my group writes are
much less than my group reads.
I have a group that mostly does reads-only, I want my read-write transactions
to be applied everywhere once they commit, so that subsequent reads are done on
up-to-date data that includes my latest write. Without paying at reads.
139 / 161

140 / 161

Consistency: BEFORE_AND_AFTER
I want that my application to replicate data as close as possible to synchronous.
And of course I'm OK to pay the required price !
141 / 161

Consistency: BEFORE_AND_AFTER
142 / 161

Defining Consistency
The consistency level of the MySQL InnoDB Cluster can be de ned during the creation:
143 / 161

Defining Consistency (2)
The consistency can be globally changed in MySQL Shell:
It's also possible and recommended for the most restrictive levels to de ne it at
statement session level:
144 / 161

MySQL Router Specific Settings
145 / 161

MySQL Router : Metadata Cache
The se ings to access MySQL InnoDB Cluster's Metadata Cache is de ned in the
[metadata_cache:<name>] section of MySQL Router's con g le.
146 / 161

MySQL Router : Metadata Cache
The se ings to access MySQL InnoDB Cluster's Metadata Cache is de ned in the
[metadata_cache:<name>] section of MySQL Router's con g le.
The most interesting se ings is:
ttl: Time to live (in seconds) of information in the metadata cache. One milissecond is
0.001. To continously query the the metadata cache in a tight loop, set it to 0 (the
default value is 0.5).
147 / 161

MySQL Router : Metadata Cache (2)
As of MySQL Router 8.0.17, ttl is now obsolete as you can enable
use_gr_noti cations to refresh metadata on each of the four noti cations that Group
Replication sends:
group_replication/membership/quorum_loss
group_replication/membership/view
group_replication/status/role_change
group_replication/status/state_change
148 / 161

MySQL Router
By default, when bootstrapped, MySQL Router is con gured using rst-available as
routing strategy for R/W connections (to the Primary-Master).
For R/O connections (to Secondary-Masters), the strategy is round-robin-with-fallback.
This is actually setup for the MySQL Classic Protocol and MySQL X Protocol.
149 / 161

MySQL Router : Routing Strategy Methods
rst-available: the new connection is routed to the rst available server from the
destinations list. In case of failure, the next available server is used. This cycle continues
until all servers are unavailable.
round-robin-with-fallback: for load-balancing, each new connection is made to the
next available secondary server in a round-robin fashion. If a secondary server is not
available then servers from the primary list are used in round-robin fashion.
150 / 161

MySQL Router : Routing Strategy Methods
round-robin: for load-balancing, each new connection is made to the next available
server in a round-robin fashion.
next-available: like rst-available, in that the new connection is routed to the rst
available server from the destinations list. Unlike rst-available, if a server is marked as
unreachable then it gets discarded and is never used again as a destination
151 / 161

MySQL Router : Routing destinations
Now that we have de ned a strategy for the MySQL Router, we also need to de ne
destinations.
Destinations (desinations in [routing:<name>] section), can be a comma-separated list of
MySQL Servers, or a metadata-cache de nition:
152 / 161

MySQL Router : Routing destinations
Now that we have de ned a strategy for the MySQL Router, we also need to de ne
destinations.
Destinations (desinations in [routing:<name>] section), can be a comma-separated list of
MySQL Servers, or a metadata-cache de nition:
[routing:PerconaLiveEU_default_rw]
bind_address=0.0.0.0
bind_port=6446
destinations=metadata-cache://PerconaLiveEU/default?role=PRIMARY
routing_strategy= rst-available
protocol=classic
153 / 161

Configuration & Settings
154 / 161

Instance Specific Settings
Within the MySQL Shell you can de ne some Group Replication speci c se ings via the
Admin API that will only a ect the targeted instance:
exitStateAction: string value indicating the group replication exit state action.
(ABORT_SERVER, READ_ONLY and OFFLINE_MODE [8.0.18])
memberWeight: integer value with a percentage weight for automatic primary election
on failover.
autoRejoinTries: integer value to de ne the number of times an instance will a empt to
rejoin the cluster after being expelled.
155 / 161

Instance Specific Settings (2)
label: a string identi er of the instance.
156 / 161

Group Specific Settings
Within the MySQL Shell you have the possibility to de ne some Group speci c se ings via
the Admin API:
clusterName: string value to de ne the cluster name.
exitStateAction: string value indicating the group replication exit state action.
memberWeight: integer value with a percentage weight for automatic primary election
on failover.
consistency: string value indicating the consistency guarantees that the cluster
provides.
157 / 161

Group Specific Settings (2)
expelTimeout: integer value to de ne the time period in seconds that cluster members
should wait for a non-responding member before evicting it from the cluster.
autoRejoinTries: integer value to de ne the number of times an instance will a empt to
rejoin the cluster after being expelled.
disableClone: boolean value used to disable the clone usage on the cluster.
158 / 161

Upgrade to MySQL 8.0
It's time to upgrade to MySQL 8.0, the fastest MySQL adoption release ever !
159 / 161

160 / 161

Thank you !
161 / 161

MySQL InnoDB Cluster - Advanced Configuration & Operations

More Related Content

What's hot (20)

Similar to MySQL InnoDB Cluster - Advanced Configuration & Operations (20)

More from Frederic Descamps (20)

Recently uploaded (20)

MySQL InnoDB Cluster - Advanced Configuration & Operations