MySQL User Camp: GTIDs

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
MySQL Replication:
Global Transaction Identifiers(GTIDs)
Shivji Kumar Jha
Software Developer, MySQL Replication Team

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.

Program Agenda
 Introduction to MySQL Replication
 Fail-over Base
– Global Transaction Identifiers – Automatic Positioning – Hands-On
 Under the Hood: Become a GTID Expert
– How Slave Preserves GTIDs – GTIDs Must Be Unique
 Integration With Other Features
– Seeking & Skipping – Purging Binary Logs – Restoring from Backup

Introduction to MySQL Replication  Fail-over Base  Under the Hood  Integration With Other Features
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

Why Use
Replication?

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

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

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

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

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

How Does
Replication
Work?

All Changes Written to Binary Log
A
binary log
Client

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

create...
A
binary log
Client
Table t

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

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

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

Binary Log Sent to Slave, Re-executed
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

Makes sense?

Fail-over
 Crash can happen to anyone:
– Hardware failure
– Human mistake
– Bug
– Natural disaster
 Automatic fail-over with Global Transaction Identifiers:
– Reduces admin overhead
– Prevents planned downtime
– Prevents unplanned downtime

Fail-over
 Handle server crash with minimal disruption
 Example 1: tree
C
B
A

Fail-over
 Example 1: tree
C
B
ACrash

Fail-over
 Example 1: tree
C
B
A
Make B the new master

Fail-over
 Example 1: tree
 Example 2: line

Fail-over
 Example 1: tree
 Example 2: line
CA B

Fail-over
 Example 1: tree
 Example 2: line
CA BCrash

Fail-over
 Example 1: tree
 Example 2: line
CA B
Make A direct master of C

Fail-over
 Example 1: tree
 Example 2: line
 Example 3: circle
C
A
B
D

Fail-over
 Example 1: tree
 Example 2: line
C
A
B
DCrash

Fail-over
 Example 1: tree
 Example 2: line
C
A
B
D
Make a shortcut
in the circle

Fail-over
 Example 1: tree
 Example 2: line
 Example 4: scheduled maintenance
C
A
B
D
Take
out D!

Fail-over
 Example 1: tree
 Example 2: line
C
A
B
D
Maintain
D offline,
without
disrupting
service

Fail-over
 Example 1: tree
 Example 2: line
C
A
B
D

Fail-over
 Example 1: tree
 Example 2: line
 Example 5: arbitrary topology
A
B
C
D
E
F

Wow!
Lets
get started with
fail-over.

Global Transaction Identifiers
 Server assigns Global Transaction Identifier (GTID) to every
transaction:
– server_uuid:number
a61678ba-4889-4279-9e58-45ba840af334:1
– server_uuid identifies the server; globally unique
– number is incremented by 1 for each transaction on this server
 Writes GTID to binary log
 Slave ensures transaction gets the same GTID when re-executed

master> CREATE TABLE t1 (a INT);
master> SELECT @@global.gtid_executed;
a61678ba488942799e5845ba840af334:1
master> INSERT INTO t1 VALUES (1);
master> INSERT INTO t1 VALUES (2);
a61678ba488942799e5845ba840af334:13
Note: interval
New variable:
gtid_executed

a61678ba488942799e5845ba840af334:110000
slave> SELECT @@global.gtid_executed;
a61678ba488942799e5845ba840af334:19999
Slave is missing
one transaction
Slave is missing
one transaction

But
how are GTIDs
used in
fail-over?

Automatic Positioning
 Master–slave protocol:
– Slave sends @@gtid_executed to master
– Master sends all other transactions to slave
id1,trx1,
id2,trx2
id1,trx1,
id2,trx2,
id3,trx3
A 2. id3, trx3, …
1. id1…id2
B

 Example 1: tree
(master)
A
id1,trx1,
id2,trx2,
id3,trx3
(slave)
C
id1,trx1
(slave)
id1,trx1,
id2,trx2B

 Example 1: tree
(master)
A
id1,trx1,
id2,trx2,
id3,trx3
(slave)
C
id1,trx1
(slave)
id1,trx1,
id2,trx2B
Crash!

 Example 1: tree
(master)
A
id1,trx1,
id2,trx2,
id3,trx3
(slave)
C
id1,trx1
(slave)
id1,trx1,
id2,trx2B id1
id2, trx2,...
What the
slave has
What the
slave does
not have

 Example 1: tree
BA C
client client

 Example 1: tree
id1,trx1
BA C
client client trx1

 Example 1: tree
id1,trx1
B
id2,trx2
A C
client clienttrx2 trx1

 Example 1: tree
id1,trx1,
id2,trx2B
id2,trx2
A C
client clienttrx2 trx1

 Example 1: tree
id1,trx1,
id2,trx2,
id3,trx3
B
id2,trx2
A C
client clienttrx2 trx1, trx3

 Example 1: tree
id1,trx1,
id2,trx2,
id3,trx3
B
id2,trx2
A C
Crash!

 Example 1: tree
id1,trx1,
id2,trx2,
id3,trx3
B
id2,trx2
A C
id2
id1,trx1,id3,trx3,...
What the
slave has
What the
slave does
not have

Awesome!
How do I set
it up?

Hands-On
 Prerequisites:
– Use transactional storage engine for all tables (InnoDB)
– Don't use CREATE TABLE … SELECT
– Don't execute CREATE TEMPORARY TABLE or
– DROP TEMPORARY TABLE inside a transaction

Hands-On
 Prepare the server for fail-over
– Sync and stop all servers
– Add to every my.cnf:
gtidmode=on
enforcegtidconsistency=on
logbin
logslaveupdates
– Start all servers
– Execute:
> CHANGE MASTER TO MASTER_AUTO_POSITION = 1

Hands-On
 Perform fail-over
On the slave, simply point to the new master:
> CHANGE MASTER TO MASTER_HOST = '<host>',
                   MASTER_PORT = <port number>,
                   MASTER_USER = '<user name>'
                   MASTER_PASSWORD = 'secret';
 No positions needed!

Hands-On
 Perform fail-over
C
B
A
CHANGE MASTER TO
MASTER_HOST = 'B',
MASTER_PORT = <B's port>,
MASTER_USER = '<user name>'
MASTER_PASSWORD = 'secret';

Interesting!
I want to learn
more.

Under the Hood: How Slave Preserves GTIDs
B
id1,trx1,
id2,trx2A
Slave
= client

B
id1,trx1,
id2,trx2A
Slave
= client
SET GTID_NEXT = 'id1';
trx1

id1,trx1
B
id1,trx1,
id2,trx2A
Slave
= client
trx1

id1,trx1
B
id1,trx1,
id2,trx2A
Slave
= client
trx1
trx2

id1,trx1,
id2,trx2B
id1,trx1,
id2,trx2A
Slave
= client
trx1
trx2

Under the Hood: GTID_NEXT
 GTID_NEXT – session system variable
 Default: “AUTOMATIC”
– → Server generates new GTID for next transaction
 Slave thread sets to “UUID:NUMBER”
– → Server uses specified GTID for next transaction

Under the Hood: GTID_NEXT
 Clients can set GTID_NEXT too:
 Mysqlbinlog outputs SET GTID_NEXT statements:
id1,trx1
id2,trx2
set gtid_next = “id1”;
trx1
set gtid_next = “id2”;
trx2
mysqlbinlog
binary log
id,insert
A
Client
set gtid_next=”id”;
insert

Under the Hood: GTIDs Must Be Unique
 Impossible to execute a GTID twice:
id1,trx1
id1,trx2A

 Try to execute a GTID second time → transaction skipped:
id1,trx1
id1,trx2A
id1,trx1
A
Client

id1,trx1
id1,trx2A
id1,trx1
A
Client
set gtid_next=”id1”;
trx2

id1,trx1
id1,trx2A
id1,trx1
A
Client
trx2
trx2 not executed!

I love
GTIDs!
Is there anything
that I should pay
attention to?

Skipping a Transaction
 Common use case: skip a bad transaction
 Transaction should be skipped forever
 Not enough to move replication position
A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1
B
Bad
transaction

A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id3,trx3B
Bad
transaction

A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id3,trx3B
Bad
transaction trx2 comes back
after reconnect
id2, trx2, …
id1,id3

A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id3,trx3B
Bad
transaction trx2 comes back
after reconnect
So we don't
allow seeking!
id2, trx2, …
id1,id3

 Recall: Try to execute a GTID second time → transaction skipped
 Interesting feature:
Client executes GTID before slave
→ slave skips transaction
 To force slave thread to skip a transaction:
slave> SET GTID_NEXT=“GTID of transaction to skip”;
slave> COMMIT;
 Transaction is skipped forever

 How to skip a
transaction forever
A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1
B
Bad
transaction
commit;Client

 How to skip a
transaction forever
A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id2, –B
Bad
transaction
commit;Client

 How to skip a
transaction forever
A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id2, – ,
id3,trx3
B
Bad
transaction
commit;Client

 How to skip a
transaction forever
A
id1,trx1,
id2,trx2,
id3,trx3
id1,trx1,
id2, – ,
id3,trx3
B
Bad
transaction
commit;Client
id4, trx4, …
id1,id2,id3

Filters
 --replicate-ignore-table etc
 Transactions should be filtered-out forever
 Slave commits empty transaction
A
(crashed)(master)
A
id1,trx1,
id2,trx2,
id3,trx3
(slave)
id1,trx1,
id2,-
id3,trx3
B
Filters out
trx2
Logs id2 with an
empty transaction

Skipping Stuff: Summary & Recipe
 To seek forward from position A to B:
– Commit empty transaction for each GTID between A and B
 To seek backward:
– Not possible, does not make sense
 To skip N transactions:
– Get the GTIDs, commit empty transaction for each GTID
 Replication filters automatically commit empty transactions

So the rule
is easy:
skip = empty
transaction

Purging Binary Logs
 Binary logs are rotated and can be purged
A
id4,trx4,
id5,trx5,
id6,trx6
master-bin.02 master-bin.03
id7,trx7,
id8,trx8
master-bin.01
id1,trx1,
id2,trx2,
id3,trx3

Purging Binary Logs
A
id4,trx4,
id5,trx5,
id6,trx6
id7,trx7,
id8,trx8
Client PURGE BINARY LOGS TO 'masterbin.02'
master-bin.01
id1,trx1,
id2,trx2,
id3,trx3

Purging Binary Logs
A
id4,trx4,
id5,trx5,
id6,trx6
id7,trx7,
id8,trx8
XPurged!
Client PURGE BINARY LOGS TO 'masterbin.02'
master-bin.01

Purging Binary Logs
 On Master: cannot send purged GTIDs to slave
– @@gtid_purged = all purged GTIDs

Purging Binary Logs
B Purged!A
id4,trx4,
id5,trx5,
id6,trx6
master-bin.02
XPurged!
id1,trx1,
id2,trx2
slave-bin.01
gtid_purged=id1,id2,id3 gtid_executed=id1,id2
master-bin.01

Purging Binary Logs
B Purged!A
id4,trx4,
id5,trx5,
id6,trx6
master-bin.02
XPurged!
id1,trx1,
id2,trx2
slave-bin.01
Error!
id1,id2
Nothing sensible to do:
B needs trx3
which is purged
gtid_purged=id1,id2,id3 gtid_executed=id1,id2
master-bin.01

Purging Binary Logs
 On Slave: must send all GTIDs (purged or not) to master
– @@gtid_executed = all GTIDs (purged or not)
A
slave-bin.02
XPurged!A
master-bin.02
id1,trx1,
id2,trx2,
id3,trx3
id4,trx4,
id5,trx5
id4,trx4
slave-bin.01master-bin.01
id5,trx5
id1…id4
Note: slave must send id1...id3 despite purged
or else master would send trx1…trx3

Purging Binary Logs
 On Slave: must send all GTIDs (purged or not) to master
– @@gtid_executed = all GTIDs (purged or not)
A
id4,trx4,
id5,trx5,
id6,trx6
id7,trx7,
id8,trx8
XPurged!
@@gtid_purged = id1 … id3 @@gtid_executed = id1 … id8
master-bin.01

Purged and Executed are Stored in Binary Log
 Binary logs begin with:
[ list of all GTIDs in all previous binary logs ]
A
[id1…id3]
id4,trx4,
id5,trx5,
id6,trx6
[id1…id6]
id7,trx7,
id8,trx8
XPurged!
master-bin.01
GTIDs in
master-bin.01 +
master-bin.02
GTIDs in
master-bin.01

Purged and Executed are Stored in Binary Log
 Binary logs begin with:
[ list of all GTIDs in all previous binary logs ]
A
[id1…id3]
id4,trx4,
id5,trx5,
id6,trx6
[id1…id6]
id7,trx7,
id8,trx8
XPurged!
@@gtid_executed
=
head of newest log +
GTIDs in newest logid1…id3
id1…id6 + id7 + id8
master-bin.01
@@gtid_purged
=
head of oldest log

Purging Binary Logs: Summary
 Works automatically, behind the scenes
 Purged GTIDs are stored in @@gtid_purged
 @@gtid_purged is a subset of @@gtid_executed

Automatic
is the word!
Does purging have
anything to do with
backups?

Provision a Slave From a Backup
id1,create,
id2,insertA
Table t
1
B

id1,create,
id2,insertA
Table t
1
B
Backup
Table t
1
Backup

id1,create,
id2,insertA
Table t
1
B
Table t
1Backup
Table t
1
Backup Restore

id1,create,
id2,insertA
Table t
1
B
Table t
1Backup
Table t
1
Backup Restore
Binary log
not
restored!

id1,create,
id2,insertA
Table t
1
B
Table t
1Backup
Table t
1
Backup Restore
Binary log
not
restored!
Set gtid_executed and
gtid_purged to id1,id2
(or else A would send
id1,id2 when B connects)

id1,create,
id2,insertA
Table t
1
B
Table t
1Backup
Table t
1
Backup Restore
Binary log
not
restored!
Set gtid_executed and
gtid_purged to id1,id2
(or else A would send
id1,id2 when B connects)
XPurged!
set @@gtid_purged = “id1,id2”

 @@gtid_executed must agree with database state
– @@gtid_executed after restore = @@gtid_executed at backup
 @@gtid_purged = GTIDs in @@gtid_executed that are not in log
– Binary logs not (normally) restored
– @@gtid_purged after restore = @@gtid_executed after restore
 @@gtid_purged is settable:
– SET @@GLOBAL.GTID_PURGED = "GTID_EXECUTED at backup"
– Also sets @@GTID_EXECUTED to the same value

Restore a Backup
 Backup tools must store @@gtid_executed
 Restore tools must execute:
– SET @@GLOBAL.GTID_PURGED =
"GTID_EXECUTED at backup"

You had
me at “GTID”
What shall I
do now?

Next Steps
 More on GTIDs
– svenmysql.blogspot.co.uk
 More on MySQL 5.6 Replication
– http://dev.mysql.com/tech-resources/articles/
mysql-5.6-replication.html
 Try Out MySQL 5.6
– http://dev.mysql.com/downloads/mysql/

MySQL User Camp: GTIDs

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to MySQL User Camp: GTIDs (20)

More from Shivji Kumar Jha (16)

Recently uploaded (20)

MySQL User Camp: GTIDs