View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
1. We provide a platform to build your own and free awesome web site for any device
2. About 40M Registered Users
3. Around 1.3M new registrations every month
4. About 500 employees with 4 offices around the world.
Why do we need Multi-Master topology?
The Vision: Multiple, active DBMS servers with exactly the same data
1. Simple high availability model
2. Operate systems over multiple sites
3. Access geographically “close” data
MySQLNative Replication Summary
• Built in with well-known capabilities
• MySQL replication by default is asynchronous. In addition to the built-in asynchronous
replication, MySQL 5.5 and above supports semi-synchronous replication.
• Very limited topology support
• Very limited conflict avoidance
• Not a good choice for multi-master if there are
writes to more than 1 master
How Does NDB Work?
Mysql Client Mysql Client
NDB Eventual Consistency Algorithm
• NDB has built-in cross-cluster conflict detection based on epochs and primary keys
• Updates to primary always succeed
• Update on secondary may be rolled back if primary has a conflicting update
• MySQL Cluster resends updates from the primary to “cure” conflicts on the
MySQLNDB Cluster Summary
• Allows active/active operation on 2 clusters
• Fully synchronous, no action can be returned to client until transactions on all nodes are
• NDB is mainly an in memory database and also if it support table on disk the cost of
them not always make sense.
• Use horizontal partition to equally distribute data cross node, but none of them has the
• Covers failure of individual MySQL nodes inside the cluster by replication factor
• Detects conflicts automatically on rows
How Does Galera Work?
Master 1 Master 2 Master 3
wsrep API* wsrep API wsrep API
wsrep API (write set replication API), defines the interface between Galera replication and the DBMS
Galera approach is Data Centric
• Data does not belong to a node – Node belong to data. Using global transaction Id’s
• Connect to any nodes for writes
• No headache for auto increment. Galera will do it for you
• Galera replicate the full dataset across ALL nodes.
• Galera replicate data synchronously from one node to cluster on the commit, but
apply them on each node by a FIFO queue (multi thread).
• Galera require InnoDB to work.
• Galera data replication overhead, increase with the number of nodes present in the
• Galera do not offers any parallelism between the nodes when retrieving the data;
clients rely on the single node they access.
• Synchronous replication
• Percona XtraDB Cluster is based on Galera
How Does Tungsten Replication Work
Tungsten Failure Handling
• Replication stops and resumes automatically when network link goes down
• Replication stops on replicator or DBMS failure and recovers after operator restart
• Conflicts can break replication. Auto increment keys should be manually configured
on each node
• Have his own filters for data replication
Tungsten Supported Topologies
• Allows active/active operation on N clusters
• Transfer is asynchronous
• Links can be down for days or weeks if required
• It is the application’s responsibility to ensure there are no conflicts
• Tungsten Replicator can replicate data from MySQL to
MongoDB, Oracle, NuoDB, Vertica and others
• Tungsten allows replication from Oracle by using Change Data Capture (CDC).
Destination DBMS can be MySQL or Oracle
MySQL NDB Galera Tungsten
InnoDB + - + +
Asynchronous + - + +
Statement based + + - +
Row Based + - + +
Semi-synchronous + - - -
Synchronous - + + -
Global TRX Id + + + +
Time delay replication + - - +
Thank you all