MariaDB Galera cluster solution
MariaDB Galera cluster solution {.post-title}
Cloud web platform synergy
It is an Enterprise Level System for reactive applications which aims to be a highly available.
In order to achieve this goals it is imperative to also be:
event-driven
scalable
resilient
responsive.
In order to achieve this goals, any database used must be also:
- resilient (durable to any disruptions )
- self-healing (must continue working , even if a part is temporarly unaccessible due to maintance or some critical error )
DB Clustering
A cluster is a collection of individual nodes. Every node is a database in itself. The power of clustering can be leveraged by connecting individual nodes and let it work synchronized. This makes the whole database cluster intelligent. The nodes communicate together, help each other, balance their work between them and work in an integrated fashion.
MariaDB cluster
MySQL is one of the most used databases (if not the most used database). MariaDB is an enchanced cousin of MySQL. It can work by itself, but only working in cluster makes it highly available.
In comparison to other existing databases, it is:
- A high availability solution with synchronous replication, failover and resynchronization
- No loss of data
- All servers have up-to-date data (no slave lag)
- Read scalability
- Pretty good’ write scalability
- High availability across data centers
Topology
When running on only one physical computer, it is vulnerable to this computer failing to work.
Connecting more than one computer in a cluster creates a database topology.
In a topology clear rules must be set, so that not every node fights with each other.
Traditionally, this was acheieved by using a master, which coordinates the communication and slaves that obey to this. In case the master fails, the whole cluster is uncoordinated. First solutions to this problems made a fail mechanism, where one of the remaining slaves would be declared master. When the original master returned, it could only be a slave. There can only be one.
MariaDB galera technology takes a different approach. It is composed of donors and joiners. First node which starts the cluster is the original donor. It is bootstraped in order to create the cluster. Any incoming node will become joiner. However, it can be a donor for some another joiner. Some nodes serve as mediators and the cluster selforganizes into an unified working unit. In case of some nodes failing, this is detected and the remaining nodes reconnect. All of this is done behind scenes.
Writing to the database and reading from the database happen on a “agree first” basis. All the node members are asked when a write operation is performed, and when all agree, it is carried out and the result is propagated throughout the cluster. Should a write operation happen on the same data on more than one node, a livelock occurs. This is however not critical, since only retires in different times must be performed. The same data cannot be written at the same time to more than one node. Data consistency is warranted. Read operations can occur at any time at any number of nodes, since the data is consistent when having been written.
Quorum
In order to decide what must be done next, at least an uneven number of nodes must agree. It is recommended to use at least 3 nodes. The number of nodes which have the mayority decide how to resolve a confliclicting situation. Connections in a cluster between some nodes could fail. This is known as a split brain or brain split. Each partition would continue to work on it’s own, what is the least wanted behaviour. Therefore only the majority continues, while the minority goes into a sleep-mode. Upon reconnecting to the majority, the cluster continous to work in unison. This is self-healing and resiliency.
Current status within Open Source Osijek community
The MariaDB database galera aim is to serve as the main backend for the Synergy Platform. As it does heavy work of keeping any data consistent and does it quite well, the choice over some other existing alternatives was not difficult. Tests show low resource usage and the multimaster functionality is better choice than using a traditional master-slave model.
In order to have a minimum working system with quorum, Open Source Osijek has chosen to have a 3-node MariaDB Galera cluster.
References
https://mariadb.com/kb/en/galera/
https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/
http://en.wikipedia.org/wiki/High_availability
http://en.wikipedia.org/wiki/Redundancy_%28databases%29
http://en.wikipedia.org/wiki/Replication_%28computing%29
http://www.percona.com/live/mysql-conference-2013/sessions/how-understand-galera-replication-0