• GTID Replication
• Multi threated slave
• Crash- safe slave configuration
• Delay replication
• Multi source replication
• No-SQL with MYSQL
• 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 GTIDs.
SID. This is the server’s 128 bit identification
number (SERVER_UUID). It identifies where
the transaction was originated. Every server
has its own SERVER_UUID.
GNO. This is the transaction identification
number. It is a sequence number that
increments with every new transaction. Note
the 1-5 is a group of transactions.
What problems GTID solves?
• It is possible to identify a transaction uniquely across the replication servers.
• Make the automation of failover process much easier. There is no need to do
calculations, inspect the binary log and so on. Just MASTER_AUTO_POSITION=1.
• At application level it is easier to do WRITE/READ split. After a write on the MASTER
you have a GTID so just check if that GTID has been executed on the SLAVE that you
use for reads.
• Development of new automation tools isn’t a pain now.
More on GTID
• A high-availability solution
• GTIDs do not provide replication monitoring
• GTIDs do not provide failover
• But they make HA so much easier
Multi-Threaded Slaves (MTS)
• Coordinator thread on slave dispatches work across several
• Each worker thread commits trx in isolation
Multi Threated Slave
• Before 5.6 MySQL Replication is SINGLE threaded
• MySQL 5.6 is multi-threaded at the database level
• MySQL 5.7 is multi-threaded at the table level
Crash-safe slaves- transactional replication
• The MySQL replication team implemented crash-safety by moving the
replication progress information into system tables.
• This is a more flexible solution and has advantages compared to storing the
positions in the InnoDB transaction log:
◦ If the replication information and data is stored in the same storage engine, it
will allow both the data and the replication position to be updated as a single
transaction, which means that it is crash-safe.
Crash-safe slaves Contd..
• The replication information is flushed to disk together with the transaction
• Hence writing the replication information directly to the InnoDB redo log does
not offer a speed advantage, but does not prevent the user from reading the
replication progress information easily.
• The tables can be read from a normal session using SQL commands, which also
means that it can be incorporated into such things as stored procedures and
Crash-safe slaves Contd..
The replication information is stored in two files:
This file contain information about the connection to the master—such as
hostname, user, and password—but also information about how much of the
binary log that has been transferred to the slave.
This file contain information about the current state of replication, that is,
how much of the relay log that has been applied.
• MySQL 5.6 supports delayed replication such that a slave server deliberately
lags behind the master by at least a specified amount of time.
• Delayed replication can be used for several purposes:
◦ To protect against user mistakes on the master. A DBA can roll back a delayed
slave to the time just before the disaster.
◦ To test how the system behaves when there is a lag. For example, in an
application, a lag might be caused by a heavy load on the slave.
◦ To inspect what the database looked like long ago, without having to reload a
backup. For example, if the delay is one week and the DBA needs to see what
the database looked like before the last few days' worth of development, the
delayed slave can be inspected.
Delayed Replication Contd..
• When the slave SQL thread is waiting for the delay to elapse before executing
an event, SHOW PROCESSLIST displays its State value as Waiting until
MASTER_DELAY seconds after master executed event.
• The relay-log.info file now contains the delay value, so the file format has
• In particular, the first line of the file now indicates how many lines are in the
• If you downgrade a slave server to a version older than MySQL 5.6, the older
server will not read the file correctly. To address this, modify the file in a text
editor to delete the initial line containing the number of lines.
• On March 10, 2015, with the release MySQL-5.7.6 a new feature called multi-source
replication was introduced which provides the ability for a MySQL slave server to replicate
from more than one MySQL master.
• Note that there is no conflict detection or resolution built into multi-source replication. We
expect the application to make sure that data coming from different sources are non-
Here we have three MySQL sources replicating
to the only slave acting as a sink to collect all
the data from all the three sources.
MySQL Multi-Source Replication
• MySQL Multi-Source Replication enables a replication slave to receive
transactions from multiple sources simultaneously.
• Multi-source replication can be used to back up multiple servers to a single
server, to merge table shards, and consolidate data from multiple servers to a
• Multi-source replication does not implement any conflict detection or
resolution when applying the transactions, and those tasks are left to the
application if required.
• In a multi-source replication topology, a slave creates a replication channel for
each master that it should receive transactions from.
No-SQL with MYSQL - document store
• Relational databases such as MySQL usually required a document schema to
be defined before documents can be stored.
• MySQL as a document store is a schema-less, and therefore schema-flexible,
storage system for documents.
• When using MySQL as a document store, to create documents describing
products you do not need to know and define all possible attributes of any
products before storing them and operating with them.
• This differs from working with a relational database and storing products in a
table, when all columns of the table must be known and defined before adding
any products to the database.
Some Key Concepts
• A Document is a set of key and value pairs, as represented by a JSON object. A
Document is represented internally using the MySQL binary JSON object,
through the JSON MySQL datatype. The values of fields can contain other
documents, arrays, and lists of documents.
• A Collection is a container that may be used to store Documents in a MySQL
Some Key Concepts Contd..
• Create, Read, Update and Delete (CRUD) operations are the four basic operations that can be
performed on a database Collection or Table. In terms of MySQL this means:
◦ Create a new entry (insertion or addition)
◦ Read entries (queries)
◦ Update entries
◦ Delete entries
• The MySQL Server plugin which enables communication using X Protocol.
• A protocol to communicate with a MySQL Server running X Plugin.