Galera
Galera
Galera Replication is a
synchronous multi- master replication plug-in for InnoD. It is very different
from the regular MYSQL Replication, and addressess a number of issues
including write conflicts when writing
on multiple masters, replication lag and slaves being out of sync with the
master. Galera easy is an easy-to-use, high-availability solution, which
provides high system update, no data loss and scalability for future growth.
Galera Replication
-> Galera replication happens at transaction commit time,
by broadcasting transaction write set to the cluster for applying
-> Clients connects
directly to the DBMS and experiances close to native DBMS behavior
-> wsrep API (write set
replication API), define the interface between Galera replication and
the DBMS
Synchronous vs
Asynchronous Replication
The basic difference between
Synchronous and Asynchronous replication is that “synchronous” guarantees that
if changes happened on one node of the cluster, they happened on other nodes
“sychronously”. “Asynchronous” give no
guarantees about the delay between applying changes on “master” node and the propagation of changes to
“slave” nodes. The delay can be short or long – it is a matter of luck. This
also implies that if master node crashes, some of the latest changes my be
lost.
Theoretically synchronous
replication has a number of advantages over asynchronous.
-> It is always available
(there is no data loss when one nodes crashes and data replicas are always
consistent.)
-> transactions can be
executed on all nodes in parallel.
-> it can guarantee
causality across the whole cluster (SELECT S issued after transaction T will
always see the effects of transaction even if it is executed on another node)
What is difference between
MYSQL Replication and Galera Replication?
MYSQL Replication is part of
the standard MYSQL database, and is mainly asynchronous in nature. Update are
always done on master, and these are propagated to slaves. It is possible to
create a ring topology with multiple masters, howecer that is not recommeneded
as it is very easy for the servers to get out of sync on case of a master
failing. There is no automatic failover or resynchronization in these cases.
Galera Replication is a
plug-in to MySQL, and enables a true master- master setup for InnDB. In a
Galera replication cluster, all nodes are masters and applications can read and
write from any node. Transactions are synchronously commited on all nodes. In
case on node failing, the other nodes will continue to operate and kept up to
date. When the failed node comes up again, it automatically sychronizes with
the other nodes before it is allowed back into the cluster. No data is lost
when a node fails.
Advantages of Galera
-> A high avalibility
solution with synchronous replication, failover and resynchroniztion.
-> No less of data
-> All servers have
up-to-date data (no slave lag)
-> Read scalability
-> “Pretty good” write
scalability
-> High availability
across data centers.
-> No need to learn new
storage engine technology like NDBCluster. Learning new technology will require
some time to learn. It just similar to InnoDB with added of cluster
functionality.
Disadvantages of Galera
-> It’s new. There isn’t a
huge body of experience with its strengths, weaknesses, and appropriate use
cases.
-> It support only InnoDB.
-> The whole cluster
performs writes as slowly as the weakest node. Thus, all nodes need similar
hardware, and if one node slows down (e.g., because the RAID card does a
battery-learn cycle), all of them slow down. If one node has probability P of
being slow to accept writes, a three-node cluster has probability 3P of being
slow.
-> Because of the cross-node communication required at
transaction commit, writes will get slower, and deadlocks and rollbacks will get more frequent, as you add
nodes to the cluster.
-> A minimal Galera
cluster consists of 3 nodes. The reason is that, should there be a problem
applying a transaction on one node (e.g., network problem or the machine
becomes unresponsive), the two other nodes will have a quorum (i.e. a majority)
and will be able to proceed with the transaction commit.
-> Both node are depended
to each other , means node1 depended on node3, and node2 depended on node1, and
node3 depended on node2, you need to start cluster on secuance way.
-> With increasing number of writeable
masters, the transaction rollback may increase, especially if there is write
contention on the same dataset. This increases transaction latency.
-> It is possiable for a
slow/overloaded master node to affect performance of the Galera replication
cluster, therefore it is recommended to have uniform servers across the
cluster.
How to configure Galera cluster on Rhel6.5
In this Galera cluster setup,
I have taken 3 node to illustrate.
|
node1(RHEL6.5) -
192.168.56.112
node2(RHEL6.5) -
192.168.56.113
node3(RHEL6.5) -
192.168.56.114
|
Packages Required.
1 galera-25.3.2-1.rhel6.x86_64.rpm
(https://launchpad.net/galera)
2
mysql-5.6.14_wsrep_25.1-linux-x86_64.tar.gz
(https://launchpad.net/codership-mysql)
3 rsync
Install MySQL Package on all
the 3 nodes, using the standard procedure.
1. First install the
dependencies
|
# yum install
libaio.x86_64 libaio-devel.x86_64 libdbi-dbd-mysql.x86_64 ibdbi.x86_64
libdbi-drivers.x86_64 perl.x86_64 perl-DBD-MySQL.x86_64
|
2. Configure Galera
|
Preparing...
########################################### [100%]
1:galera
########################################### [100%]
[root@galera1 opt]#
[root@galera2 opt]# ls
-ltrh /usr/lib64/galera/libgalera_smm.so
-rwxr-xr-x. 1 root root
28M Feb 19 12:07 /usr/lib64/galera/libgalera_smm.so
|
3. Initial MySQL setup on
first node.
|
service mysql start
mysql
mysql> DROP USER
'root'@'127.0.0.1';
mysql> DELETE FROM
mysql.user WHERE user='';
mysql> GRANT ALL ON
*.* TO root@'%' IDENTIFIED BY 'P@ssw0rd';
mysql> UPDATE
mysql.user SET Password=PASSWORD('P@ssw0rd') WHERE User='root';
mysql> quit
|
4. Create directory and copy
files:
|
#mkdir /etc/mysql
# cp
/usr/share/mysql/wsrep.cnf /etc/mysql/
#cp /usr/share/mysql/my-small.cnf
/etc/my.cnf
|
5. Edit my.cnf:
|
vi /etc/my.cnf
add line:
!includedir /etc/mysql
|
6. Edit wsrep.cnf:
|
vi /etc/mysql/wsrep.cnf
change lines to:
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_sst_auth=root:P@ssw0rd
# Group communication
system handle
wsrep_cluster_address="gcomm://"
wsrep_cluster_name="mygalera"
wsrep_cluster_method=rsync
|
7. Restart Msql:
|
# service mysql restart
|
8. Log in and check cluster
is up:
|
mysql
mysql> show status
like 'wsrep%';
must be :
| wsrep_cluster_size |
1 |
| wsrep_ready | ON |
|
9. Second node setup:
|
repeat steps 4-8, in
step 6 write:
wsrep_cluster_address="gcomm://IP_of_first_node"
in step 8 you'll see:
must be :
| wsrep_cluster_size |
2 |
| wsrep_ready | ON |
|
10. Third node setup:
|
repeat steps 4-8, in
step 6 write:
wsrep_cluster_address="gcomm://IP_of_second_node"
in step 8 you'll see:
must be :
| wsrep_cluster_size |
3 |
| wsrep_ready | ON |
|
11. Reconfigure the first node:
|
vi /etc/mysql/wsrep.cnf
change cluster address
to:
wsrep_cluster_address="gcomm://IP_of_third_node"
|
12 Restart mysql.
service mysql restart
Your cluster is ready to
accept connection.
