Local Asynchronous Replication

Architectures
Haute-Dispo
Joffrey MICHAÏE
Consultant MySQL
04.20111
High Availability with MySQL
Higher
Availability
• Shared nothing distributed cluster with MySQL
Cluster
• Storage snapshots for disaster
recoveryGeographical Replication for disaster
recovery
• Virtualised Environments
• Active/Passive Clusters + Local Asynchronous
ReplicationActive/Passive Clusters through
shared storage
• DRBD + Local Asynchronous Replication
• Synchronous Replication through DRBDLocal
Semi-synchronous ReplicationLocal
Asynchronous Replication
2
Local Asynchronous Replication
• Data written on the master is written into the binary log
• The I/O thread on the slave collects logs from the master binary log and writes a
relay log on the slave
• The SQL thread on the slave reads the relay log and apply the writes on the slave
• Slave writes are optionally added to
the binary log on the slave
• It can be statement-based (SBR),
row-based (RBR) or mixed (MBR)
Read-Write
• In case of fault:
– The master server is taken
down
Read-Only
Read-Only
– The slave server is updated
up to the last position in the
relay log
– The clients point at the
binlog
designated slave server
– The designated slave
server becomes the
master server
99
3
relaylog
relaylog
relaylog
relaylog
Local Asynchronous Replication
1. A write transaction is sent to the Master
BEGIN WORK
INSERT INTO...
...
COMMIT
binlog
relaylog
relaylog
relaylog
relaylog
4
Local Asynchronous Replication
2. The transaction is stored into the binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
binlog
relaylog
relaylog
relaylog
relaylog
5
Local Asynchronous Replication
3. The client receives the ACK from the server
TXN OK!
binlog
relaylog
relaylog
relaylog
relaylog
6
Local Asynchronous Replication
4. The I/O thread on the slave(s) pulls the
transaction and it stores it in the relaylog
binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
7
Local Asynchronous Replication
5. The SQL thread reads the transaction from the
relay log and applies the transaction on the slave(s)
binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
8
Local Asynchronous Replication
Typical Usage
• High availability with manual failover
– Easy to implement and maintain, provides a good
level of availability
• Non-intrusive backup
– Backups can be executed on a slave server
– The binlog and provides incremental backup and
possible point-in-time recovery
• Scalability for read-intensive applications
– Read-only transactions can be executed on the slave
servers
• Systems and applications upgrades
– Chains of Master/Slaves reduce to virtually 0 the
downtime for upgrades
9
Local Asynchronous Replication
Other Features
• Out-of-the box with MySQL Server
• Platform independent
– Master and Slaves can be heterogeneous in OS and
version
• Storage engine independent
– Master and Slaves can be heterogeneous in storage
engines
• Multiple topologies
• Works with transactional and non-transactional
engines
• Advanced settings can define a selection of
data to replicate
10
Local Asynchronous Replication
Other Features
• Out-of-the box with MySQL Server
• Platform independent
– Master and Slaves can be heterogeneous in OS and
version
• Storage engine independent
– Master and Slaves can be heterogeneous in storage
engines
• Multiple topologies
• Works with transactional and non-transactional
engines
• Advanced settings can define a selection of
data to replicate
11
Local Semi-Synchronous Replication
• One or more slaves are defined as “semi-synchronous servers”
• the Master server waits until the I/O thread on one of the semi-sync slave(s)
has flushed the transaction to disk, or until it receives a timeout, then it
returns the ACK to the application.
• In case of fault:
– The master server is
taken down
Read-Write
– The slave server is
updated up to the
Read-Only
Read-Only
last position in the
relaylog (the update will
be fast)
– The clients point at the
designated slave server binlog
– The designated slave
server becomes the
master server
12
relaylog
relaylog
relaylog
relaylog
Local Semi-Synchronous Replication
1. A write transaction is sent to the Master
BEGIN WORK
INSERT INTO...
...
COMMIT
binlog
relaylog
relaylog
relaylog
relaylog
13
Local Asynchronous Replication
2. The transaction is stored into the binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
binlog
relaylog
relaylog
relaylog
relaylog
14
Local Asynchronous Replication
3. The I/O thread on the slave(s) pulls the
transaction and it stores it in the relaylog
binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
15
Local Asynchronous Replication
4. The client receives the ACK from the server
TXN OK!
binlog
relaylog
relaylog
relaylog
relaylog
16
Local Asynchronous Replication
5. The SQL thread reads the transaction from the
relay log and applies the transaction on the slave(s)
binlog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
relaylog
BEGIN WORK
INSERT INTO...
...
COMMIT
17
Synchronous Replication through DRBD
• One server is designated as “active” and another server as
“passive” or “stand-by”
• The active server “owns” a virtual IP address. Applications refer
to the virtual IP address to connect to the database server.
• Data is synchronously replicated at block level from the
active to the stand-by server
• In case of fault:
– The master server is
taken down
– The block device on the stand-by
server is mounted
– The mysqld on the stand-by server
starts
– The virtual IP address moves to the
stand-by server
– The stand-by server becomes active
Active/Hot
Server
Block
Device
Passive/Std-by
Server
Block
Device
18
Synchronous Replication through DRBD
1. A write transaction is sent to the active Server
BEGIN WORK
INSERT INTO...
...
COMMIT
Active/Hot
Server
Block Device
Passive/Std-by
Server
Block Device
19
Synchronous Replication through DRBD
2. The transaction is written to the block device
Active/Hot
Server
Passive/Std-by
Server
BEGIN WORK
INSERT INTO...
...
COMMIT
Block Device
Block Device
20
Synchronous Replication through DRBD
3. The blocks modified by the transaction are
replicated to the stand-by server
Active/Hot
Server
Block Device
Passive/Std-by
Server
Block Device
21
Synchronous Replication through DRBD
4. The client receives the ACK from the server
TXN OK!
Active/Hot
Server
Block Device
Passive/Std-by
Server
Block Device
22
Synchronous Replication through DRBD
Typical Usage
• High availability with automatic failover
– Fully redundant solution with no loss of data and
no single points of failure
• Point-in-time snapshots
– One or more servers can be updated at regular
intervals to provide historical analysis
23
Synchronous Replication through DRBD
Other Features
• Fully certified, Linux-only environment
– Works with Pacemaker and Heartbeat
• Works with InnoDB only
• Inexpensive solution
24
DRBD + MySQL Replication
• The combination of DRBD and MySQL Replication
provides more availability for scheduled and unscheduled
downtime
• In case of fault of the master server, DRBD switches over
to the stand-by server
• During the switchover,
clients can still read from
the slaves
• For planned
downtime and
upgrades, DBAs
can apply rolling
upgrades
Block
Device
binlog
relaylog
relaylog
relaylog
relaylog
25
Active/Passive Clusters through
Shared Storage
• Similar to DRBD, but data is not replicated through the network.
– Redundancy and replication must be guaranteed by the shared
storage
– Shared storage is usually Storage
Area Networks (SAN) or Network
Attached Storage (NAS)
• InnoDB only, available with
Linux, Windows or Solaris
• Used with FS like GFS
or OCFS2
• In case of fault:
– The master server is taken down
– The mysqld on the stand-by server starts
– The virtual IP address moves to the
stand-by server
– The stand-by server becomes active
Active/Hot
Server
Shared Storage
Passive/Std-by
Server
26
Active/Passive Clusters through Shared Storage
Large Deployments
VIP0
2
VIP0
6
VIP0
3
VIP0
7
VIP0
4
VIP0
8
in01
in02
in03
in04
in05
in06
in07
in08
06 05 04
03 02 01
08 07
VIP0
1
VIP0
5
Shared Storage
27
Active/Passive Clusters through Shared Storage
Failover in Large Deployments
VIP0
5
VIP0
3
VIP0
7
VIP0
4
VIP0
8
in02
in03
in04
in06
in07
in08
in01
in05
06 05 04
03 02 01
08 07
VIP0
1
VIP0
2
VIP0
6
Shared Storage
28
Active/Passive Clusters plus
Replication
• The combination of active/passive cluster + MySQL
Replication provides more availability for scheduled and
unscheduled downtime
• In case of fault, the master, active server switches over to
the stand-by server
• Slaves will pull data from
the new slave
• Replication can also
be used
Passive/Std-by
Active/Hot
Server
Server
for planned
downtime and
rolling upgrades
• Replicated data
may be stored on
Shared Storage
shared storage
relaylog
relaylog
relaylog
29
relaylog
Active/Passive Clusters plus Replication
through Shared Storage
Large Deployments
VIP0
3
VIP0
7
VIP0
4
VIP0
8
M01
S02
S03
M04
S05
S06
M07
S08
08 07
M01 > S02,
S03
M04 > S05,
S06
VIP0
2
VIP0
6
06 05 04
03 02 01
VIP0
1
VIP0
5
Shared Storage
30
Virtualised Environments
• MySQL Servers - masters or slaves - are located on any
available physical server
• High availability and load balancing are provided by the
virtualised
software
• Data storage
is usually
managed by the
virtualised software
01
03
05
07
but it is masked as
02
04
06
08
local storage
• In case of fault, the
virtualised software restarts
on any other physical server
• InnoDB only
Shared Storage
08 07
06 05 04
03 02 01
31
Geographical Replication for Disaster
Recovery
Active
Data Centre
• Master-Master Asynchronous
Replication is used to update the
backup data centre
• In case of fault, the network
traffic is redirected to the
backup data centre. Failback
must be executed manually
• Cross-platform and crossengine
Backup Data
Centre
32
Storage Snapshots for Disaster
Recovery
Active Data
Centre
• Snapshots are managed by the NAS and SAN
firmware. There is usually a short read-only freeze
• Snapshots can be used as run-time
backup
• InnoDB only, NetApp NASs and
firmware are certified using Snapshot
and Snapmirror
Backup Data
Centre
33
MySQL Cluster
NDB API, ClusterJ/JPA
• Shared-nothing, fully transactional and distributed architecture used for high volume and small
transactions.
• MySQL Cluster is based on the NDB (Network DataBase) Storage Engine
• Data is distributed for scalability and performance, and it is replicated for redundancy on multiple
data nodes.
Application Nodes
• Nodes in a cluster:
– SQL Nodes: provide the
SQL interface to NDB
– API Nodes: provide the
native NDB API
– Data Nodes: store and
retrieve data, manage
SQL Nodes
transactions
– Management Nodes:
manage the Cluster
• Load balanced
• Memory or disk-based
• Geographically replicated
for disaster recovery
• Full online operation for
maintenance and
administration
Management
Nodes
Data Nodes
34
Thank You!
Joffrey MICHAÏE
Consultant MySQL
[email protected]
35