LinuxFest Northwest 2022 - The Evolution of a MySQL Database System

Frédéric Descamps
Community Manager
MySQL
The Evolution of a MySQL
Database System
from single instance to mutli-region DR

The Journey To
MySQL InnoDB
ClusterSet
Copyright @ 2022 Oracle and/or its affiliates.
2

Who am I ?
about.me/lefred
3

@lefred
MySQL Evangelist
using MySQL since version 3.21
devops believer
likes 🏀
living in 🇧🇪
https://lefred.be
Frédéric Descamps
4

Best Practices in 2022
configuration parameters
5

During this presentation I assume that...
your system is MySQL 8.0.28 or more recent
you are using only InnoDB
you have the binary logs enabled
the binary logs format is ROW
you are using GTIDs
6

Evolution to High Availability
MySQL 8.0
7

8

This is where it all begins...
reminder:
we use ONLY InnoDB
we keep the default durability settings
One single MySQL instance

9

One single MySQL instance
/
/
RPO ?
?
RTO
10

Next Level (level up)
The database becomes more important, loosing it might be an issue...

11


RTO → hours
11


RTO → hours

RPO → 1 day
11


RTO → hours

RPO → 1 day

RTO: Recovery Time Objective (how long to recover)

RPO: Recovery Point Objective (how much data can be lost)
11

Physical Backups
Logical Backups
For logical backups, please use MySQL
Shell Dump & Load Utility !
Backups
12

One single MySQL instance with daily backups
hours
1 day
RPO ?
?
RTO
13

1 day RPO ? Really ?? We want to reduce it to minutes at least !

14


RTO → hours
14


RTO → hours

RPO → minutes
14

These are the defaults in MySQL 8.0:

Durable Binlogs
We enable binary logs allowing to replay the modifications since the last backup:
15

One single MySQL instance with daily backups and
binlogs
hours
minutes
RPO ?
?
RTO
16

Point-in-Time Recovery (PITR)
PITR is the technique by which an administrator can restore or recover a data set to a
certain point in the past.
With MySQL, point-in-time recovery involves restoring a dump of the data and then
replaying the binlogs from and to a specific point.
This technique is used to:
solve an issue
perform a live migration
17

Point-in-Time Recovery : how does it work ?
day 1
BACKUPS
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
18

day 1
BACKUPS
Binlogs
day 2
we want to recover
up to this point
day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
19

day 1
BACKUPS
Binlogs
day 2
we want to recover
up to this point
day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
1. we restore the dump of day 3
20

day 1
BACKUPS
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
2
.
w
e
r
e
p
l
a
y
the
binlog
(.008)
1. we restore the du,p of day 3
21

Point-in-Time Recovery : important concepts
Usually, after a backup (and its verification), the binary log files are purged from the MySQL
server:
22

server:
day 1
BACKUPS
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
22

server:
day 1
BACKUPS
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
day 1
BACKUPS
pontential recovery
points
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005 .006 .007 .008 .009 .010
}
22

My data is very important and I've a heavy workload... I would like to loose less than a
second in case of a problem !

23


RTO → hours
23


RTO → hours

RPO → less than a second
23

Enable GTIDs (they should be already !)
Save in realtime the binary logs to a
different system (OCI Object Storage, S3,
...)
VCN
10.0.0.0/16
Public Subnet
10.0.0.0/24
Private Subnet
10.0.1.0/24
MySQL Shell
MySQL
Database Service
Internet
Gateway
Oracle Cloud Infrastructure
Availability Domain 1
Fault Domain 1
mysql-dump-bucket
mysql-binlogs-bucket
Object Storage
dump instance
streambinlogs
Improved Point-in-Time Recovery (PITR)
24

with MySQL restart
Enabling GTIDs
25

with MySQL restart without MySQL restart
Enabling GTIDs
25

Saving Binlogs

26

Saving Binlogs

On another system:
mysqlbinlog --raw --read-from-remote-server --stop-never --host 10.0.0.2
--port 3306 -u getbinlog -ppassword
--ssl-mode='REQUIRED' binlog.xxxxxx
26

Point-in-Time Recovery : important conceptes (2)
As you may have noticed, we can only recover at the exact time of the backups and we can
only do a one-off recovery from the last one!
This is why it is recommended to relocate/offload the binlogs (to another server, a NAS, the
cloud, ...).
This will allow for a point-in-time recovery at any moment in time:
27

Point-in-Time Recovery : important conceptes (2)
As you may have noticed, we can only recover at the exact time of the backups and we can
only do a one-off recovery from the last one!
This is why it is recommended to relocate/offload the binlogs (to another server, a NAS, the
cloud, ...).
This will allow for a point-in-time recovery at any moment in time:
}
day 1
BACKUPS
Binlogs
day 2 day 3 day 4
.001
.002
.003 .004 .005
.001
.002
.003
.004
.005
.006 .007 .008 .009 .010
.006
.007
.008
.009
.010
b
i
n
l
o
g
s
t
r
e
a
m
i
n
g
possible recovery
points
27

One single MySQL instance with daily backups and
external binlogs archiving
hours
< 1 second
RPO ?
?
RTO
28

My service is now very important, I would like my database to be available again within
minutes in case of an incident.

29


RTO → minutes
29


RTO → minutes

RPO → less than a second
29

Based on the well known Asynchronous
Replication
But easier... easier is always better !
Data provisioning included (clone)
2 or more nodes
Manual Failover
Transparent/Automatic query routing
with MySQL Router
MySQL InnoDB ReplicaSet
30

31

Connected to the actual server (our single instance):
JS > dba.configureReplicaSetInstance()
JS > rs=dba.createReplicaSet('myreplicaset')
On the new extra server where only MySQL is installed (server and shell):
JS > dba.configureReplicaSetInstance()
And again on the main instance (our single instance):
Et de nouveau sur l'instance
principale:
JS > rs.addInstance('mysql-2')
32

MySQL InnoDB ReplicaSet - examples
33

34

35

MySQL Router
MySQL Router is very easy to configure, you only need to use the bootstrap command !
36

MySQL Router
As usual, this is also visible in MySQL Shell
37

MySQL InnoDB ReplicaSet - Manual Failover
MySQL Shell is connected to MySQL InnoDB ReplicaSet via MySQL Router.
38

MySQL InnoDB ReplicaSet - Manual Failover
39

MySQL RelicaSet
minutes
< 1 second
RPO ?
?
RTO
rto >
40

Now my service is very important, I would like to be almost always up (automatic failover)
and never loose data !

41


RTO → seconds
41


RTO → seconds

RPO → 0
41

Based on native Group Replication
But easier.... easier is always better !
Data provisioning included (clone)
3 or more nodes (odd number)
Automatic Failover
Uses MySQL Router
Configurable Consistency Levels
MySQL InnoDB Cluster
42

43

On the ReplicaSet's Primary Instance:
JS > dba.dropMetadataSchema()
JS > cluster=dba.createCluster('mycluster')
On the Secondary one:
SQL > STOP REPLICA;
SQL > RESET ALL REPLICA;
And back on the Primary:
JS > cluster.addInstance('mysql-2')
We can now add a third instance to benefit
from the automatic failover:
44

On the ReplicaSet's Primary Instance:
JS > dba.dropMetadataSchema()
JS > cluster=dba.createCluster('mycluster')
On the Secondary one:
SQL > STOP REPLICA;
SQL > RESET ALL REPLICA;
And back on the Primary:
JS > dba.configureInstance()
From any member of the cluster:
JS > cluster=dba.getCluster()
Finally, we can configure MySQL Router
again:
# mysqlrouter --bootstrap
clusteradmin@single-mysql:3306
--conf-use-gr-notifications
--user mysqlrouter --force
# systemctl restart mysqlrouter
We can now add a third instance to benefit
from the automatic failover:
44

45

seconds
0
RPO ?
?
RTO
rto >
46

And if something happens to our data center ??
47

How can we deploy a Disaster Recovery solution ?

47

How can we deploy a Disaster Recovery solution ?

MySQL InnoDB ClusterSet !!
47

The Ultimate Evolution !
available since MySQL 8.0.27
fencing support since 8.0.28
MySQL InnoDB ClusterSet
48

The result of several transformations during previous releases:
8.0.22: Automatic Connection Failover (Async Replication Channels)
8.0.23: Automatic Connection Failover (Async Replication Channels using Group
Replication)
8.0.24: transformation of skip-replica-start en global, persistent and read-only
variable
8.0.26: Actions added for Group Replication's members (ex: super_read_only
configurable)
8.0.26: Specific UUID added for structural events change of the Group
(View_change_log_event)
8.0.27: Asynchronous Replication Channel automatically follows the Primary.
49

50


More complex architectures can be deployed !
50

seconds
0
RPO ?
?
RTO
possible rpo>0
rto >
51

Extra
Since MySQL 8.0.19, the connectors also support dns-srv which, together with a discovery
service such as Consul, can replace MySQL Router when it is impossible to install it on the
application servers:
52

MySQL Shell is now included in Visual Studio Code:
53

54

Try MySQL HeatWave for Free:
https://www.oracle.com/mysql/heatwave/
55

Share your ❤️to MySQL
#mysql

Join our slack channel!
bit.ly/mysql-slack
56

Questions ?
57

LinuxFest Northwest 2022 - The Evolution of a MySQL Database System

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à LinuxFest Northwest 2022 - The Evolution of a MySQL Database System

Similaire à LinuxFest Northwest 2022 - The Evolution of a MySQL Database System (20)

Plus de Frederic Descamps

Plus de Frederic Descamps (17)

Dernier

Dernier (20)

LinuxFest Northwest 2022 - The Evolution of a MySQL Database System