MySQL Developer Day conference: MySQL Replication and Scalability

MySQL Replication and
Scalability
Shivji Jha
Software Developer,
MySQL Replication Team

2 | Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
Safe Harbour Statement
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, and timing of any features or functionality described for Oracle’s
products remains at the sole discretion of Oracle.

Overview
MySQL Replication: Discover What's New
Overview: MySQL Replication
Consistency: Lossless Semi-Sync
Slave Throughput: Improved Multi-Threaded Slave
Flexibility: Multi-Source Replication
Monitoring: Performance_Schema Tables
Next steps

“In my opinion, MySQL is the only database we
would ever trust to power the Zappos.com
website.”
"On any given day we can sell close to
300,000 tickets on the Web site using
MySQL as the database to search for
events. It is amazing."
"craigslist infrastructure could
not have handled the
exponential growth in traffic
without MySQL.”
“We are one of the largest MySQL
web sites in production
MySQL Replication In Action on the Web
“As a leader in our field, we are committed to
providing the best service to our users, and a
web experience that meets members
expectations and that starts with IT”

What is
Replication?

Replication: Copy Changes Master → Slave
 MySQL Master Server
●
Changes data
●
Sends changes to slave
 MySQL Slave Server
●
Receives changes from master
●
Applies received changes to database
M S

M M/S S
S
S
S
M
Server can be master, slave or both
Master can have multiple slaves

S
M
M
Slave can only have one master
S
M
M
Slave can have multiple masters!
labs.mysql.com
labs
Yippee!

M/S
Circular replication is also possible
M/S
M/S
M/S
M/S
M/S

Filters on slave
SM
Replication
filter
I have a lot
of tables
I only have
table_1

Why Use
Replication?

Why Replication? – Performance
Read scale-out
M S
write clients read clients

Read scale-out
M S
write clients read clients
More
reads?
More
slaves!

Read scale-out
M S
S
S
S
M
write clients read clients read clients
write clients
More
reads?
More
slaves!

Why Replication? – Redundancy
 If master crashes, promote slave to master
C
B
A

C
B
ACrash

C
B
A
B is the
new master

Why Replication? – Online backup/reporting
 Expensive queries on slave(s)
M S
Regular clients
 Reports
 Big queries
 Business intelligence

Why Replication? – Long-distance Data
Distribution
CB
BAAC
Image from
www.ginkgomaps.com

How Does
Replication
Work?

All Transactions Written to Binary Log
A
binary log
Client

create table t (a int);
A
binary log
Client

Table t
create...
A
binary log
Client

insert into t values (1);
Table t
create...
A
binary log
Client

insert into t values (1);
Table t
1
create...
insert...A
binary log
Client

Slave Initiates Replication
B
binary log
A
binary log
Client
1. Slave sends request
for replication to start
to master
2. Master sends stream
of replication data
to slave

Binary Log Sent to Slave, Re-applied
B
binary log
A
binary log
Client

create...
B
binary log
A
binary log
Client

create...
Table t
B
binary log
create...
A
binary log
Client

create...
Table t Table t
create...
B
binary log
create...
A
binary log
Client

create...
insert...
Table t Table t
create...
B
binary log
create...
A
binary log
Client

create...
insert...
Table t
1
Table t
create...
B
binary log
create...
insert...A
binary log
Client

create...
insert...
Table t
1
Table t
1
create...
insert...B
binary log
create...
insert...A
binary log
Client

Actually, Transactions Land in Slave's Relay Log
B
binary logrelay log
A
binary log
Client

create...
B
binary logrelay log
A
binary log
Client

create...
B
binary logrelay log
create...
A
binary log
Client
Table t

create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t

create...
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t

create...
Replication is Asynchronous
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
Transaction
applied here
and
copied here
THEN
applied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
Transaction
applied here
and
copied here
THEN
applied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
Transaction
applied here
and
copied here
THEN
applied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
Transaction
applied here
and
copied here
THEN
applied here
THEN
ack'ed

create...
insert...
create...
insert...B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
1Transaction
applied here
and
copied here
THEN
applied here
THEN
ack'ed

Overview
Next steps

What is
Semi-Synchronous
Replication?

Asynchronous vs Semi-sync Replication
 By default, replication is asynchronous
●
In parallel: Master acks to app and sends transaction to slave
●
Fast
●
Changes lost if master dies
 MySQL 5.5: semi-synchronous replication possible
●
In sequence: slave receives transaction, then master acks to app
●
Slower: Master waits for slave
●
Less risk for lost updates

create...
Semi-Synchronous Replication (MySQL 5.5)
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
Transaction
applied here
THEN
copied here
and
applied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
Transaction
applied here
and
applied here
THEN
copied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
Transaction
applied here
and
applied here
THEN
copied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
Transaction
applied here
and
applied here
THEN
copied here
THEN
ack'ed

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
Transaction
applied here
and
applied here
THEN
copied here
THEN
ack'ed
1
2
Slave tells master
when to ack!

create...
insert...
create...
insert...B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
1Transaction
applied here
and
applied here
THEN
copied here
THEN
ack'ed

What's New in
Semi-Synchronous
Replication?

Loss-Less Semi-Sync Replication (MySQL 5.7.2)
 MySQL 5.5:
semi-synchronous replication
●
Master commit
●
Slave receive
●
Client ack
.If master crashes
between 1 and 2,
committed data is lost
.Concurrent clients
may have seen the transaction
 MySQL 5.7.2:
loss-less semi-sync replication
●
Slave receive
●
Master commit
●
Client ack
.If master crashes, all
committed data is on slave

create...
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
THEN com-
mitted here
and
applied here
Transaction
copied here
and
ack'ed

create...
insert...
create...
B
binary log
create...
relay log
create...
A
binary log
Client
Table t Table t
THEN com-
mitted here
and
applied here
Transaction
copied here
and
ack'ed

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t Table t
and
applied here
THEN com-
mitted here
Transaction
copied here
and
ack'ed

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
and
applied here
Transaction
copied here
and
ack'ed
THEN com-
mitted here

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
and
applied here
Transaction
copied here
1
2
Slave tells master
when to commit!
and
ack'ed
THEN com-
mitted here

create...
insert...
create...
B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
and
applied here
THEN com-
mitted here
Transaction
copied here
and
ack'ed

create...
insert...
create...
insert...B
binary log
create...
insert...
relay log
create...
insert...A
binary log
Client
Table t
1
Table t
1and
applied here
THEN com-
mitted here
Transaction
copied here
and
ack'ed

 Summary
●
MySQL 5.7.2: loss-less semi-synchronous replication possible
●
If master crashes, all committed data is on slave
●
To enable:
master> SET GLOBAL
rpl_semi_sync_master_wait_point = AFTER_SYNC;
●
(default: AFTER_COMMIT – for 5.5 behavior)

Overview
Next steps

What is
Multi-Threaded
Slave?

A
binary log
 Before MySQL 5.6: Single-threaded slave
Improved Multi-Threaded Slave
B
relay logClient
Client
Client

A
binary log
B
relay log
Transactions
applied
in parallel
Client
Client
Client
Transactions
logged
in sequence
Transactions
applied
in sequence

A
binary log
B
relay log
Transactions
applied
in parallel
Client
Client
Client
Transactions
logged
in sequence
Transactions
applied
in sequence
Bottleneck!

A
binary log
 MySQL 5.6: Multi-threaded slave by database
B
relay log
Transactions
applied
in parallel
Client
Client
Client
Transactions
logged
in sequence
Transactions
applied
in parallel

A
binary log
●
Different databases go to different threads
B
relay logClient
Client
Client
DB1
DB2
DB3

A
binary log
●
Different databases go to different threads
●
Great for some applications, BUT:
●
No improvement if there is only one database
●
May break cross-database consistency
B
relay logClient
Client
Client
DB1
DB2
DB3

What's New in
Multi-Threaded
Slave?

A
binary log
 MySQL 5.7.2: Multi-threaded slave by master concurrency
●
Transactions that were prepared at the same time on master
cannot conflict
●
Master stores a logical timestamp in the binary log
●
Slave applies transactions with same timestamp in parallel
B
relay logClient
Client
Client

A
binary log
●
Works always
●
Even for one-database applications
●
Consistent
B
relay logClient
Client
Client

A
binary log
●
To enable:
slave> SET GLOBAL
slave_parallel_type = logical_clock;
(default: database – for 5.6 behavior)
B
relay logClient
Client
Client

Overview
Next steps

Multi-Source Replication
What is
Multi-Source
Replication?

 Before: Slave can have one master
 Labs release: Slave can have multiple masters
S
M
M

 Note
●
No conflict detection/resolution
●
Not update everywhere
●
Not synchronous
 The masters must have conflict-free workloads!

 Slave can have multiple masters
 Preview release: labs.mysql.com
●
Not for production yet
●
Known and unknown limitations and bugs
●
Try it out and give feedback!
S
M
M

Why Use
Multi-Source
Replication?

for Data Analytics
Business Intelligence
Data analytics
Backup
etc
M
M
M
Database 2
Database 3
Database 1
S
Database 1, 2, 3

for Merging Shards
M
M
Shard 2
Shard 1
S
New Shard

How Does
Multi-Source
Work?

relay log
relay log
relay log
A
B
C
D

Multi-Source + Multi-Threaded
relay log
relay log
relay log
A
B
C
D

D
relay log
relay log
relay log
A
B
C
D
Channel = Full slave pipeline

D
relay log
relay log
relay log
A
B
C
D
Channel = Full slave pipeline
Channels are named
my_channel
another_channel
third_channel

 Setting up
CHANGE MASTER TO […] FOR CHANNEL = 'name'

 Other replication commands:
START SLAVE […] FOR CHANNEL = 'name'
STOP SLAVE […] FOR CHANNEL = 'name'
RESET SLAVE […] FOR CHANNEL = 'name'
FLUSH RELAY LOGS FOR CHANNEL = 'name'
SHOW RELAY LOG EVENTS FOR CHANNEL = 'name'
START SLAVE […] FOR ALL CHANNELS
STOP SLAVE […] FOR ALL CHANNELS
RESET SLAVE […] FOR ALL CHANNELS
SELECT MASTER_POS_WAIT('file', pos[, timeout][, 'channel'])

 Compatibility
CHANGE MASTER TO […] (with no channel specified)
START SLAVE […] (with no channel specified)
etc
… are the same as …
CHANGE MASTER TO […] FOR CHANNEL = ''
START SLAVE […] FOR CHANNEL = ''
etc

Overview
Next steps

Monitoring with Performance_Schema
 Traditional replication monitoring:
SHOW SLAVE STATUS;
– Simple
– Not SQL friendly – no WHERE, no joins, etc
– Multi-source has per-source status
– Multi-threaded slave has per-applier status
 5.7.2: Performance_Schema tables for replication slave

relay log
execute status
by coordinator
execute status
by worker
execute
configuration
execute
status
connection
configuration
connection
status

 6 tables in performance_schema database:
replication_connection_configuration
replication_connection_status
replication_execute_configuration
replication_execute_status
replication_execute_status_by_coordinator
replication_execute_status_by_worker
 Consistent semantics across tables
 Consistent naming across tables
One row for each worker
in each multi-source channel
One row
for each
multi-source
channel

 Example: Connection status
mysql> select * from performance_schema.replication_connection_statusG
*************************** 1. row ***************************
            CHANNEL_NAME: CHANNEL1
             SOURCE_UUID: 7cff740623ca11e3ac3e5c260a83b12b
               THREAD_ID: 13
           SERVICE_STATE: ON
RECEIVED_TRANSACTION_SET: 7cff740623ca11e3ac3e5c260a83b12b:14
       LAST_ERROR_NUMBER: 0
      LAST_ERROR_MESSAGE:
    LAST_ERROR_TIMESTAMP: 00000000 00:00:00
*************************** 2. row ***************************
                        ⋮
One row for each channel

*************************** 1. row ***************************
               THREAD_ID: 13
           SERVICE_STATE: ON
      LAST_ERROR_MESSAGE:
*************************** 2. row ***************************
                        ⋮
The master's server_uuid

*************************** 1. row ***************************
               THREAD_ID: 13
           SERVICE_STATE: ON
      LAST_ERROR_MESSAGE:
*************************** 2. row ***************************
                        ⋮
Thread id and status

*************************** 1. row ***************************
               THREAD_ID: 13
           SERVICE_STATE: ON
      LAST_ERROR_MESSAGE:
*************************** 2. row ***************************
                        ⋮
Set of transactions
received through this channel

*************************** 1. row ***************************
               THREAD_ID: 13
           SERVICE_STATE: ON
      LAST_ERROR_MESSAGE:
*************************** 2. row ***************************
                        ⋮
Error status

*************************** 1. row ***************************
               THREAD_ID: NULL
           SERVICE_STATE: OFF
      LAST_ERROR_MESSAGE: error connecting to master 'me@host:13000' …
*************************** 2. row ***************************
                        ⋮
Error status

*************************** 1. row ***************************
               THREAD_ID: NULL
           SERVICE_STATE: OFF
      LAST_ERROR_MESSAGE: error connecting to master 'me@host:13000' …
*************************** 2. row ***************************
                        ⋮
Thread stopped
on error

Overview
Next steps

 Try it out!
●
MySQL 5.6:
http://dev.mysql.com/downloads/mysql/
●
MySQL 5.7.4:
http://dev.mysql.com/downloads/mysql/5.7.html
●
Labs release:
http://labs.mysql.com
 Read the manual!
●
http://dev.mysql.com/doc/refman/5.7/en/index.html
Next Steps

 Send us feedback!
●
Shivji Kumar Jha
shivji.jha@oracle.com
●
Sven Sandberg
sven.sandberg@oracle.com
●
Luís Soares
luis.soares@oracle.com
 File bugs!
●
http://bugs.mysql.com
Next Steps

MySQL Developer Day conference: MySQL Replication and Scalability

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (15)

Similar a MySQL Developer Day conference: MySQL Replication and Scalability

Similar a MySQL Developer Day conference: MySQL Replication and Scalability (20)

Más de Shivji Kumar Jha

Más de Shivji Kumar Jha (15)

Último

Último (20)

MySQL Developer Day conference: MySQL Replication and Scalability