Confoo 202 - MySQL Group Replication and ReplicaSet

MySQL Group Replication,
ReplicaSet, & Architectures
Dave Stokes @Stokes
MySQL Community Manager
Oracle Corporations
Copyright © 2019 Oracle and/or its affiliates.

The following is intended to outline our general product direction. It is intended for information purposes
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 upon in making purchasing decisions. The development,
release, timing, and pricing of any features or functionality described for Oracle’s products may change
and remains at the sole discretion of Oracle Corporation.
Statements in this presentation relating to Oracle’s future plans, expectations, beliefs, intentions and
prospects are “forward-looking statements” and are subject to material risks and uncertainties. A detailed
discussion of these factors and other risks that affect our business is contained in Oracle’s Securities and
Exchange Commission (SEC) filings, including our most recent reports on Form 10-K and Form 10-Q
under the heading “Risk Factors.” These filings are available on the SEC’s website or on Oracle’s website
at http://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.
Safe Harbor

MySQL 5.6 End of Life
February 2021!!
Upgrade please!

MySQL Replication Greatly Simplified
Primary server
makes change to
data, records that
change to a log
file
Replica fetches
log entry, applies
that change to its
copy of the data
We now have two
copies of the
same data

Terminology – may be offensive
Traditionally MySQL has used the terms
master/slave, borrowed from the
electronic industry.
Slowly moving away from those terms
but they are heavily used and probably
stuck in the legacy of the product

The Past
• Setup of replication was done manually, with many steps
Setup users, backup data, restore data, configuration, etc.
• MySQL offered large components
User had to customize setup for environment
• Lots of work for DBAs/experts who spent time in automation

Two General Types of Basic Replication
Asynchronous
Replication is asynchronous by
default; replicas do not need to be
connected permanently to receive
updates from the master.
Depending on the configuration,
you can replicate all databases,
selected databases, or even selected
tables within a database.
Semi synchronous
Semi synchronous replication, a
commit performed on the primary
blocks before returning to the session
that performed the transaction until
at least one replica acknowledges
that it has received and logged the
events for the transaction.

InnoDB Cluster - 2016
• Group Replication
Automatic membership changes, consistency, network partition handling
• MySQL Shell
Many uses but here it is used to setup and administer InnoDB Cluster
• InnoDB CLONE Plug-in
Automatically provision members
Fully integrated with InnoDB

Having Multi-Primary solves the fundamental
problem of MySQL – having single point of failure
while leaving the system as close to ACID as it is
expected from MySQL clusters.
Giedrius Jaraminas
Engineering manager of MySQL team at Uber
https://lefred.be/content/mysql-day-the-uber-experience/

InnoDB Replica Set - 2020
• ‘Classic’ asynchronous replication based solution
Fully integrated

InnoDB Cluster
A single product – MySQL
– with high availability and
scaling features baked in;
providing an integrated
end-to-end solution that is
easy to use.

Components
MySQL Server
MySQL Group Replication
MySQL Shell
MySQL Router
All components developed
together, integrated. and
tested

By having your application
talk through the Router to
the data, the application is no
longer dependent on the
architecture of the cluster.
The down side is that you
may have to retry writes. And
you are checking return
codes, right??

Easy to Use
• One client – MySQL Shell
• Integrated Orchestration
• Homogenous Servers

Group Replication
• Fault Tolerant
• Automatic Failover
• Active/Active update anywhere
• Automatic membership management
Adding/Removing members
Network partitions, failures
• Conflict detection and resolution
• Prevents Data Loss

Group Replication
• Implementation of the Replicated Database State Machine
Total order writes
XCOM – a Paxos implementation
• Configurable Consistency Guarantees
Eventual consistency
8.0 – per session and global read/write consistency
• Using proven MySQL Replication Framework by design
Binary logs
Relay logs
Global Transaction IDs – GTIDs
• Generally Available since MySQL 5.7
• Supported on all platforms
Linux, Windows, Solaris, Mac OSX, FreeBSD

What are your business requirements?
Recovery time
Objective
• How fast
should the
service recover
from a failure?
Recovery Point
Objective
• How much data
loss can the
service lose
from a failure?

What are your business requirements?
Recovery time
Objective
• How fast
should the
service recover
from a failure?
Recovery Point
Objective
• How much data
loss can the
service lose
from a failure?
Types of failure
• High Availability
• Single server,
network partition
• Disaster Recovery
• Full region/network
failure
• Human Error
• Little Bobby Tables

How much of those can you afford?
• None
• A few seconds
• Minutes
• Hours
• Day
• ……

Group Replication Use Cases
• Consistency: No data loss (Recover Point Objective)
In the event of the failure of a primary member
Split brain prevention by quorum
• Highly Available: Automatic Failover
Primary members automatically elected
Automatic network partitioning handling

• READ Scale out
Add/Remove members as needed
Replication Lag handling with Flow Control
Configurable consistency levels
Eventual
Full consistency – no stale reads

• Active/Active environments
Write to many members at the same time
Ordered writes within group (XCOM)
Guaranteed consistency
Good Write performance
Optimistic Locking (Depends on workload)

MySQL Router
Transparent routing between your application
and the back-end MySQL Servers
• Transparent client connection routing
• Load balancing
• Application connection failover
• Little to no configuration needed

MySQL Router
• Stateless design offers easy HA client routing
• Router as part of application stack
• Integration into InnoDB Cluster and Replica Set
• Understands Group Replication and
replication technology
• Currently TCP/IP for primary and non-primary
traffic

MySQL Shell
• Provides the developer and DBA with a single,
intuitive, flexible, and powerful interface for all
MySQL Related Tasks
• Multi Language
• SQL
• Python
• JavaScript

MySQL Shell
• Naturally scriptable
• Supports both document and
relational models
• Exposes full development and
administrative APIs
• Classic MySQL and X Protocol
support

MySQL Shell – Easy to Use!
Mysqlsh-js> c admin@host1
Mysqlsh-js> cluster = dba.createCluster(‘cluster’)

MySQL Shell – Configure 2nd Server
Mysqlsh-js> dba.configureInstance(‘admin@host2’)

MySQL Shell – Add 2nd Server
Mysqlsh-js> dba.addInstance(‘admin@host2’)
And we will add a third server (not shown)

MySQL Shell – Start MySQL Router
Mysqlsh-js> dba.addInstance(‘admin@host2’)
$ sudo mysqlrouter –user=mysqlrouter –bootstrap
$ sudo systemctl start mysqlrouter

cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "localhost:3320", "ssl":
"REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can
tolerate up to ONE failure.",
"topology": {
"localhost:3310": {
"address": "localhost:3310",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
},
"localhost:3320": {
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
},
"localhost:3330": {
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
}
}
}
}

InnoDB Replica Set
• MySQL 8.0.19
• Fully integrated with MySQL Router
Automatic routing
• Ease of use with MySQL Shell
Configuring, adding members, removing members
• Replication Architecture
Manual switchover and Failover
Asynchronous read scale out
Simple replication architecture
No network/hardware requirements
Providing availability on PRIMARY when issues with secondaries or network

MySQL ReplicaSet Features
Past
Restore a backup or provision new member
Present
Automatic provision with InnoDB Clone

Past
Configure replication users
Configure replication
Present
MySQL shell automatically configures users and
replication

Past
Configure replication users
Configure replication
Manual configuration, adding/removing
servers in application, MySQL Router or other
proxy
Present
MySQL shell automatically configures users and
replication
Integrated MySQL Router load balancing
Only need to bootstrap Router
Router is stateless, adapts to topology
changesCopyright © 2019 Oracle and/or its affiliates.

Past
Manual or relying on external tools to make
topology changes
Use additional monitoring tool to login to
each server to check topology status
Present
Easy to use manual switchover/failover
See status of topology through MySQL Shell
status()

Past
Complexity: User is responsible for the full
configuration of every component and its
settings
Every setup is custom
Lots of manual steps and additional software
required, always customized and often over
engineered by MySQL DBAs
Present
Shell configures server, router, replication in a
standardized best practice setup, prevents mistakes
Standard solution Supported & Q/A-ed by Oracle
Easy to use, even for beginners

MySQL ReplicaSet Requirements & Limitations
1. Requirements
1. SET PERSIST (MySQL 8.0)
2. GTIDs
2. Limitations
1. Manual failover
2. No multi-primary as such topology can not guarantee data consistency
3. All secondary members replicate from primary

MySQL ReplicaSet & Router Integration
• --bootstrap to automatically configure
• Metadata schema contain replication topology
• Health checks performed on all members
• Switch over to new primary:setPrimaryInstance()
• Shell performs topology change, configures super_read_only and updates
view_id in metadata
• Router automatically sees higher view_id nd and will redirect primary traffic
to new primary
• When primary is lost: forcePrimaryInstance()
• Shell performs topology change , updates view_id in metatdata and
invalidates lost primary
• Router will notice new topology change by higher view_id in metatdata
and automatically connects to new primary

MySQL Shell : InnoDB Cluster versus InnoDB ReplicaSet
Mysql-js>c root@h1
Mysql-js>cluster =
dba.createCluster(‘cluster’)
Mysql-js>c root@h1
Mysql-js>rs =
dba.createReplicaSet(‘replicaset’)

Mysql-js>c root@h1
Mysql-js>cluster =
dba.createCluster(‘cluster’)
Mysql-js>c root@h1
Mysql-js>rs =
dba.createReplicaSet(‘replicaset’)
Mysql-js>
dba.configureInstance(‘admin@h1’)
Mysql-js>dba.configureReplicaSet(‘admin@h1’)

Mysql-
js>cluster.addInstance(‘admin@h1’)
Mysql-
js>rs.addInstance(‘admin@h1’)

Mysql-
js>cluster.addInstance(‘admi
n@h1’)
Mysql-
js>rs.addInstance(‘admin@h1’)
$sudo mysqlrouter –user =
mysqlrouter –bootstrap
$sudo systemctl start
mysqlrouter
$sudo mysqlrouter –user =
mysqlrouter –bootstrap
$sudo systemctl start
mysqlrouter

MySQL InnoDB ReplicaSet – Manual failover
Designed for manual failover
• External monitoring process decides failover can have a lot
of false positives.
• External tool decides , if tool has issues you have bigger issues
• Split brain issues
• Majority of production environments user manual failover, which
increases uptime
• When you need automatic failover use MySQL InnoDB
Cluster instead of semi-sync

Example:
• 1 primary
• 2 secondary
• 2 proxies (on app servers)
• 1 management server
Problem: management server
and replica server partitioned
from other servers – what will
happen??
Secondary
•h1
Primary
•h2
Secondary
•h3
Async/Semi-sync
Proxy/AP Proxy/Ap
Mgmt

Example:
• 1 primary
• 2 secondary
Secondary
•h1
Primary
•h2
Secondary
•h3
Async/Semi-sync
Proxy/AP Proxy/Ap
Mgmt
Writes

Example:
• 1 primary
• 2 secondary
Problem: management server and
replica server partitioned from
other servers – what will happen??
The management might
promote the secondary causing
a split brain
Secondary
•h1
Primary
•h2
Secondary
•h3
Proxy/AP Proxy/Ap
Mgmt
Writes
Network
Partition

Example:
• 1 primary
• 2 secondary
Problem: management server and
replica server partitioned from
other servers – what will happen??
The management might
promote the secondary causing
a split brain
Secondary
•h1
Primary
•h2
Secondary
•h3
Proxy/AP Proxy/Ap
Mgmt
Writes
Network
Partition
Use InnoDB Cluster over semi-sync because as semi-
sync needs all members to ack to prevent split brain,
causing downtime with every glitch

InnoDB Cluster – when to use
• Single primary, multiple secondaries OR Multi-Primary (write to all)
• Read scale out with configurable consistent reads
• All members take part in consensus (writes as fast as the slowest node)
• Stable network is required: Net glitches cause stalls/membership
changes
• Uneven number of members required
• No Data Loss in case of member failure
• Consistency
• Automatic failover in case of failure

InnoDB ReplicaSet – when to use
• Single primary, multiple secondaries
• Read scale out with stale reads
• Secondary members only get stream of changes (binlog), does not
effect primary
• No network requirements, glitches in network do not impact availability
• 2 or more members
• During planned switchover; No data loss, split brain is handled
• Manual switchover/failover only

Clone Plugin – Physical InnoDB Snapshot
A remote cloning operation
involves a local MySQL server
instance where the cloning
operation is initiated, and a
remote MySQL server instance
where the source data is
located.
When a remote cloning
operation is initiated on the
recipient, cloned data is
transferred over the network
from the donor to the recipient.

Try InnoDB Cluster today in a sandbox!

Create Sandbox systems 2 & 3

Create InnoDB Cluster

Add systems 2 & 3 to cluster

And finally start router

Consistency Levels
You may choose between the following consistency levels:
•EVENTUAL (the default)
The transaction does not wait for preceding transactions to be applied before executing, neither does it wait
for other members to apply its changes.
This was the behavior of Group Replication before 8.0.14.
•BEFORE
The transaction will wait until all preceding transactions are complete before starting its execution. This
ensures that this transaction will execute on the most up-to-date snapshot of the data, regardless of which
member it is executed on.
•AFTER
The transaction will wait until its changes have been applied on other members. This ensures that once this
transaction completes, all following transactions read a database state that includes its changes, regardless
of which member they are executed on.
•BEFORE_AND_AFTER
This transaction will wait until : 1) all preceding transactions are completed before starting its execution;
and 2) its changes have been applied on other members. This ensures that: 1) this transaction will execute
on the most up-to-date snapshot of the data; and 2) once this transaction completes, all following
transactions read a database state that includes its changes, regardless of which member they are executed
on.

Resources on InnoDB Cluster & ReplicaSET
Planet.mysql.com
• lefred.be
• MySQLHighAvailability.com
Forums.MySQL.com
MySQLCommunity.slack.com

MySQLHighAvailability.com
• Preserving commit order on replicas with binary log disabled
• https://mysqlhighavailability.com/preserve-commit-order-on-binlogless-
replicas/
• NDB Cluster 8.0 is Generally Available
• https://mysqlhighavailability.com/ndb-cluster-8-0-is-generally-available/
• Restrict MySQL replication to row based events
• https://mysqlhighavailability.com/restrict-replication-to-row-based-events/

Thank You
Slides at
slideshare.net/davidmstokes

Confoo 202 - MySQL Group Replication and ReplicaSet

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Confoo 202 - MySQL Group Replication and ReplicaSet

Ähnlich wie Confoo 202 - MySQL Group Replication and ReplicaSet (20)

Mehr von Dave Stokes

Mehr von Dave Stokes (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Confoo 202 - MySQL Group Replication and ReplicaSet