O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
MySQL Replication Evolution -- Confoo Montreal 2017
MySQL Replication Evolution
ConFoo Montreal 2017
Dave Stokes -- MySQL Community Manager
Elephantanddolphin.blogger.com & opensourcedba.wordpress.com
Safe Harbor 2
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
21 Years Old
MySQL has been part of
Oracle’s family of databases
for six years.
MySQl 5.7 is the current release
but the next version will be
MySQL 8. Big feature is real
time data dictionary
A new native JSON datatype to
store documents in a column of
Programmers not know SQL
but need a database? X Devapi
allows them to use RDMS from
language of choice
Use Oracle Key Vault to
encrypt your data at rest.
Basic Premise Behind
1. Copy all the data on one server and copy onto another.
2. Setup Replication.
3. Log any changes on the first server to a log file, apply
that logfile to the second server.
Imagine Your Data as a Painting:
Make copy of Mona Lisa
Make copy of changes to Mona Lisa:
Apply changes to copy
Keep making copy of changes to Mona Lisa:
Apply changes made on master to slave
Binary Log on master
I/O Thread Grabs Data
Data copied to slave
Applier thread changes slave’s data
Replicating changes to tables and data
SBR: When using statement-based binary logging,
the master writes SQL statements to the binary log.
Replication of the master to the slave works by
executing the SQL statements on the slave. This is
called statement-based replication (often abbreviated
as SBR), which corresponds to the standard MySQL
statement-based binary logging format. Replication
capabilities in MySQL version 5.1.4 and earlier used
this format exclusively.
What is sent: Structured Query Language (SQL), your
RBR: When using row-based logging, the master
writes events to the binary log that indicate how
individual table rows are changed. Replication of the
master to the slave works by copying the events
representing the changes to the table rows to the
slave. This is called row-based replication (often
abbreviated as RBR).
What is sent: The Delta, the results of your query
MBR: You can also configure MySQL to use a mix of both
statement-based and row-based logging, depending on which
is most appropriate for the change to be logged. This is called
mixed-format logging. When using mixed-format logging, a
statement-based log is used by default. Depending on certain
statements, and also the storage engine being used, the log is
automatically switched to row-based in particular cases.
Replication using the mixed format is often referred to as
mixed-based replication or mixed-format replication.
Notes for the future
With MySQL.5.6 RBR started sending over only the
primary key and the changed data (not sending
unchanged data) which can drastically cut the amount
of data sent to slave servers. This can be huge!!
Many future products will work better with RBR as it
more deterministic. So plan accordingly.
Before 5.6 MySQL Replication is SINGLE threaded – Airline
MySQL 5.6 is multi-threaded at the database level
MySQL 5.7 is multi-threaded at the table level
Async and Semi Synchronous
Semi Synchronous replication -- a commit
performed on the master blocks before
returning to the session that performed the
transaction until at least one slave
acknowledges that it has received and
logged the events for the transaction (Note
not written to table, just recorded for
Asynchronous replication -- slave servers
retrieve data, master unaware of slave’s
Group Repilcation -- Labs.MySQL.Com for evaluation
Lots of folks want TWO active
masters and this can be done
but not recommended, You need
to have a sharp crew and plan
Not generally recommended
before Group Replication
You can run active-active
master-master with MySQL
Cluster, even between data
This can be very expensive and
MySQl Cluster is not a full
featured version of the MySQL
Layer separate from MySQL that is
mainly for high availability (not high
Claims to have snapshot isolation on
transactions but watch out for ‘first
committer wins’ and prepare for
Not low latency
Two types of
w/ & w/o
A global transaction identifier (GTID) is a unique
identifier created and associated with each
transaction committed on the server of origin
(master). This identifier is unique not only to the
server on which it originated, but is unique across
all servers in a given replication setup. There is a 1-
to-1 mapping between all transactions and all
Note the 1-5 is a group of
Binlog & ID
Enable Binary Log on
Master, Unique ID
Create user for
Get Master’s Binary
Snapshot data, copy
command and START
Before GTIDs (MySQL 5.5 and before) 28
Enable Binary Log & Unique ID on Master
Edit my.cnf file
Create replication user
mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY
mysql> GRANT REPLICATION SLAVE ON *.* TO
Get binary log position
mysql> FLUSH TABLES WITH READ LOCK;
mysql > SHOW MASTER STATUS;
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
| mysql-bin.000003 | 73 | test | manual,mysql |
Binlog & ID
Enable Binary Log on
Master, Unique ID
Create user for
Snapshot data, copy
command and START
GTIDs make it
much easier to
With GTIDs (MySQL 5.6 & Later) 35
MySQL InnoDB Cluster
MySQL InnoDB cluster is a collection of products that work together to provide
a high availability solution. A group of MySQL servers can be configured to
create a cluster using MySQL Shell. The cluster of servers has a single master,
called the primary, which acts as the read-write master. Multiple secondary
servers are replicas of the master. A minimum of three servers are required to
create a high availability cluster. A client application is connected to the
primary via MySQL Router. If the primary fails, a secondary is automatically
promoted to the role of primary, and MySQL Router routes requests to the new
MySQL Shell 1.0.8 or higher. Includes the AdminAPI, which enables you to create and administer an
above to run cluster provisioning scripts.
MySQL Router 2.1.2 or higher. Caches the metadata of the InnoDB cluster and performs high availability
routing to the MySQL Server instances which make up the cluster. If the primary instance becomes
unavailable, MySQL Router automatically routes client requests to a promoted secondary (the new
MySQL Server 5.7.17 or higher. This provides the Group Replication mechanism to allow data to be
replicated from the primary to the secondaries in the cluster.
Connection routing is the ability to permit the
redirection of connections sent to the router to an
available MySQL server. Connection routing is
simply the redirection of the MySQL packets in their
entirety without inspection.
This means you can set up your application to
connect to the router and should the current MySQL
server fail, retry the connection and the router will
select a new MySQL server to redirect the
So check you return codes, retry on failure
MySQL Group Replication provides distributed state machine replication with
strong coordination between servers. Servers coordinate themselves
automatically when they are part of the same group. The group can operate in a
single-primary mode with automatic primary election, where only one server
accepts updates at a time. Alternatively, for more advanced users the group
can be deployed in multi-primary mode, where all servers can accept updates,
even if they are issued concurrently. This power comes at the expense of
applications having to work around the limitations imposed by such
There is a built-in group membership service that keeps the view of the group
consistent and available for all servers at any given point in time. Servers can
leave and join the group and the view is updated accordingly. Sometimes
servers can leave the group unexpectedly, in which case the failure detection
mechanism detects this and notifies the group that the view has changed. This
is all automatic.
For a transaction to commit, the majority of the group have to agree on the
order of a given transaction in the global sequence of transactions. Deciding to
commit or abort a transaction is done by each server individually, but all
servers make the same decision. If there is a network partition, resulting in a
split where members are unable to reach agreement, then the system does not
progress until this issue is resolved. Hence there is also a built-in, automatic,
split-brain protection mechanism.
All of this is powered by the provided group communication protocols. These
provide a failure detection mechanism, a group membership service, and safe
and completely ordered message delivery. All these properties are key to
creating a system which ensures that data is consistently replicated across the
group of servers. At the very core of this technology lies an implementation of
the Paxos algorithm. It acts as the group communication systems engine.
All read-write (RW) transactions commit only after they have been approved by the
group. Read-only (RO) transactions need no coordination within the group and thus
commit immediately. For any RW transaction the group needs to decide whether it
commits or not, thus the commit operation is not a unilateral decision from the
originating server. When a transaction is ready to commit at the originating server, the
server atomically broadcasts the write values (rows changed) and the correspondent
write set (unique identifiers of the rows that were updated). Then a global total order
is established for that transaction. Ultimately, this means that all servers receive the
same set of transactions in the same order. As a consequence, all servers apply the
same set of changes in the same order, therefore they remain consistent within the
Can’t Cover all of MySQL Replication in ~60 minutes!!!!! 50Or can I?????
Giuseppe Maxia has lot of great code
for getting used to replication -- see
FREE Scripts written in Python, used with MySQL
Workbench or stand alone
1.Copy, diff databases
2.Disk usage, grants, copy users
3.Search for processed and kill ‘em
4.Setup replication and failover
Mysqlrplcheck -- check replication setup
shell> mysqlrplcheck --master=root@host1:3310 --slave=root@host2:3311
# master on host1: ... connected.
# slave on host2: ... connected.
Test Description Status
Checking for binary logging on master [pass]
Are there binlog exceptions? [pass]
Replication user exists? [pass]
Checking server_id values [pass]
Is slave connected to master? [pass]
Check master information file [pass]
Checking InnoDB compatibility [pass]
Checking storage engines compatibility [pass]
Checking lower_case_table_names settings [pass]
Checking slave delay (seconds behind master) [pass]
# ...done. 53
Mysqlrplcheck -- replication checker
shell> mysqlrplsync --master=user:pass@localhost:3310
# GTID differences between Master and Slaves:
# - Slave 'localhost@3311' is 15 transactions behind Master.
# - Slave 'localhost@3312' is 12 transactions behind Master.
# Checking data consistency.
# Using Master 'localhost@3310' as base server for comparison.
# Checking 'test_rplsync_db' database...
# - Checking 't0' table data...
# [OK] `test_rplsync_db`.`t0` checksum for server 'localhost@3311'.
# [OK] `test_rplsync_db`.`t0` checksum for server 'localhost@3312'.
# - Checking 't1' table data...
# [OK] `test_rplsync_db`.`t1` checksum for server 'localhost@3311'.
# [OK] `test_rplsync_db`.`t1` checksum for server 'localhost@3312'.
# Checking 'test_db' database... 54
Mysqlslavetrx -- skip bad transactions
shell> mysqlslavetrx --gtid-set=af6b22ee-7b0b-11e4-aa8d-606720440b68:7-9
WARNING: Using a password on the command line interface can be insecure.
# GTID set to be skipped for each server:
# - localhost@3311: af6b22ee-7b0b-11e4-aa8d-606720440b68:7-9
# - localhost@3312: af6b22ee-7b0b-11e4-aa8d-606720440b68:7-9
# Injecting empty transactions for 'localhost:3311'...
# Injecting empty transactions for 'localhost:3312'...