MasteringGaleraData Masters
Special Thanks To…
1010 NE 2nd AveMiami, FL 33132
305-735-1274www.venturehive.co
Our Sponsor!
John Jadvani954-527-0090
Short bio about me… Andrew Simkovsky 15 years working with database technology
Oracle, MySQL/MariaDB, SQL Server, Postgres Redis, MongoDB, CouchDB, Cassandra, Neo4j
Worked across many industries Consulting, Retail, Telecommunications,
Energy Data, Marketing, Gaming, Health care
Let’s Get Started!
Galera Cluster for MySQL
High availability (HA) and scaling solution for MySQL/MariaDB
A clustering solution that integrates with MySQL / MariaDB
Galera Cluster Concept
MySQL/MariaDB
Galera
Other HA and Scaling Solutions
Sharding Master / Slave(s) Master / Master Master / Master plus Slaves
Sharding
A..F G..L M..R …
Application
Master / Slave(s)
Master Slave
Application
Master / Slave(s)
Master
Slave
Application
Slave Slave
Master / Master
Master Master
Application
Master / Master Plus Slaves
Master
Slave
Application
Slave Slave
Master
Slave Slave Slave
Basic Galera Concepts
Contains multiple nodes Each node has a full copy of the data Synchronous multi-master replication across all
nodes All changes to every node are replicated to all
other nodes Each node can be for reads and writes All nodes can be accessed at the same time
Galera Concept
Galera Galera Galera Galera Galera
Node Node Node Node Node
Application
Quorum Commit
Don’t have to wait for all nodes to answer back for your changes
“Majority” rules Committed nodes >= (N / 2 ) + 1 Minimum recommended number of nodes is 3
Split Brain Syndrome Network partition between the nodes Each node thinks its in charge Both nodes keep taking traffic Now both nodes have different contents When nodes start talking to each other again,
they are very confused
Galera Galera
Split Brain Syndrome
Node Node
Application
Application
Data Center 1 Data Center 2
Arbitrator Node “Cheating” with 2 nodes Acts as a third node Doesn’t store any data Aware of cluster state and replication status Provides that third “commit” vote Replication changes pass through it Loss of direct connectivity between nodes can still be
handled if arbitrator can talk to both
Arbitrator Node
Galera Galera
Node Node
Application
Application
Data Center 1 Data Center 2
Data Center 3
Arbitrator
Some Other “Gotchas” Be careful with non-deterministic functions like NOW(),
CURTIME(), etc DELETE commands on tables without a primary key are
not supported Direct writes to system tables (“mysql” database) are not
replicated Cluster enforces optimistic concurrency control
“I got here first, my transaction is good” All other transactions locking the same row get deadlock
error Application should be configured to retry the transaction
Setup Overview
Stuff to install on each node
Operating system MariaDB server Galera Percona XtraBackup
Setup Steps On each node:
Set up configuration files Start up MySQL
On first node: during startup, you tell it that it’s the first node. The data it contains will become the “master” copy.
For each additional node that starts up, it will seek out one of its “neighbors”, and try to sync a copy of the data to itself Source node is called the “donor”
After syncing the data, the node joins the cluster and becomes active
Database State Transfer When starting up, each node needs a copy of the data The copying of the data is called a “state transfer” Will copy from existing nodes using one of these methods:
mysqldump rsync xtrabackup
For mysqldump and rsync, the donor is locked for writes during the entire copy process
Percona’s xtrabackup allows writes to happen on donor node during copy process
Live Demo!
Questions?
Thank You For Coming!
Please rate this Meet Up:www.meetup.com/data-masters
(or go there to join!)Check out my blog and forums:
www.dbtekpro.com