The MySQL High Availability Landscape and where Galera Cluster fits in

The MySQL High Availability
Landscape and where Galera
Cluster ﬁts in
Colin Charles, colin.charles@galeracluster.com

9 April 2019

https://twitter.com/galeracluster | www.galeracluster.com

Codership Webinar
!1

Agenda
• Codership

• What is High Availability?

• Redundancy through MySQL replication

• Failover frameworks

• Proxies

• Galera Cluster

• Cloud-based solutions

• Conclusion
!2

Codership
• The developers and experts of Galera Cluster

• Established in 2007, 3 founders, all engineers

• Seppo Jaakola, CEO, Teemu Ollakka, CTO, Alex Yurchenko, architect

• Services business model, producing 100% open source software

• Thousands of users in various industries: e-commerce, betting/gambling,
telecoms, banking, insurance, gaming, healthcare, media, marketing,
advertising, travel, education, software as a service, PaaS, IaaS, etc.
!3

Myriad solutions
• Galera Cluster (which includes MariaDB Galera Cluster and Percona XtraDB Cluster
(PXC))

• Linbit DRBD

• Failover frameworks: MHA, mysqlfailover, Orchestrator

• MySQL NDB Cluster

• Group replication and MySQL InnoDB Cluster

• The cloud with “HA-out-of-the-box”

• Proxies: MySQL Router, MariaDB MaxScale, ProxySQL
!5

Uptime
Percentile target Max downtime per year
90% 36 days
99% 3.65 days
99.5% 1.83 days
99.9% 8.76 hours
99.99% 52.56 minutes
99.999% 5.25 minutes
99.9999% 31.5 seconds
!6

Estimating levels of availability
Method
Levels of
Availability
Regular asynchronous
replication
98-99.9%
SAN 99.5-99.9%
DRBD, MHA 99.9%
NDBCluster, Galera Cluster 99.999%
!7

High Availability is about redundancy
• RAID: disk crashes? Another works

• Clustering: server crashes? Another works

• Power: fuse blows? Redundant power supplies

• Network: Switch/NIC crashes? 2nd network route

• Geographical: Datacenter oﬄine/destroyed? Computation to another DC
!8

High Availability is about Durability in your data
• Data stored on disks

• Is it really written to the disk?

• being durable means calling fsync() on each commit

• Is it written in a transactional way to guarantee atomicity, crash safety,
integrity?
!9

High Availability for databases
• HA is harder for databases

• Hardware resources and data need to be redundant

• Remember, this isn’t just data - constantly changing data

• HA means the operation can continue uninterrupted, not
by restoring a new/backup server

• uninterrupted: measured in percentiles
!10

High Availability solutions we won’t cover
• Client-side XA transactions

• Shared storage via a SAN (scale up vs. scale out, expensive!)

• Virtual Machine (VM) based failover

• MySQL NDB Cluster (niche)

• Commercial solutions

• SeveralNines ClusterControl while not a High Availability solution, has a GUI that
works well with Galera Cluster

• Continuent Tungsten Replicator is no longer an open source solution
!11

Redundancy through disk replication
• DRBD

• Linux administration vs. DBA skills

• Synchronous

• Second set of data inaccessible for use

• Passive server acting as hot standby

• Failover: 1-30 minutes

• Performance hit: DRBD is worse than single node performance, with higher average
latencies
!12

Redundancy through MySQL replication
• Replication is asynchronous and was statement-based till row-based was
introduced in MySQL 5.1, and it became the default in MySQL 5.7

• MariaDB Server uses mixed-mode replication, which is STATEMENT unless
calling dangerous statements which then switches to ROW based (e.g.
server variable used in statement, USER function, etc.)

• Semi-synchronous introduced as a plugin in MySQL 5.5+, and built into
MariaDB Server 10.3+

• semi-sync nowadays has no phantom read issues (5.7+), as it only
acknowledges a transaction event after written to the relay log and
ﬂushed to disk
!13

Failover frameworks
• When you use asynchronous or semi-synchronous (preferred) replication, you can use a failover
framework to help with automated failovers (i.e. when the primary dies, a secondary takes over
as the new primary)

• Orchestrator has a GUI

• MHA has been tried and tested

• MySQL Utilities comes with mysqlfailover

• Linux chops? Pacemaker Resource Agents exist

• Beware that not all these tools work with the GTID of MariaDB Server (they tend to be tuned for
MySQL)

• Replication Manager works with both GTIDs
!14

Proxies
• MySQL Router — part of InnoDB Cluster, transparent routing between
application and MySQL backends

• MariaDB MaxScale — database proxy, well suited for MariaDB Server
deployments

• ProxySQL — supports Galera Cluster hostgroups

• HAProxy — does not understand the SQL protocol, but is commonly used
as a load balancer in front of MySQL
!15

Galera Cluster
• MariaDB Server (which comes with Galera Cluster) has over 12 million downloads as of
March 2017; Percona XtraDB Cluster (PXC) has over 1.3 million downloads; more from
galeracluster.com; we can’t count distributions!

• Cloud platforms recommend Galera Cluster usage for High Availability — e.g.
OpenStack

• Thousands of users in various industries (e-commerce, gaming, telecom, banking,
insurance, healthcare, SaaS, IaaS, PaaS, etc) have trusted Galera Cluster over a decade.

• MySQL Community Award: Application of the Year 2014

• Included in many mainstream Linux/BSD distributions (Ubuntu, Debian, Fedora, RHEL8,
openSUSE, FreeBSD, etc.)
!16

Galera Cluster is all about multi-master replication
• Can be described as virtually synchronous replication

• High Availability with no data loss, and consistent data across all nodes — no Single Point of Failure (SPoF)

• Quorum based failure handling

• Optimistic concurrency control

• 100% multi-master cluster (all nodes are equal in terms of having the data, so no lagging secondaries, 24/7
availability, etc.)

• This is a core feature of the product by design, has automatic transaction conﬂict detection and management,
and your application can issue any transaction to any Galera Cluster node. Works well in WAN/Clouds

• Parallel replication

• You do not need automatic failovers via a framework, no need to designate single nodes for writes and the rest for
reads, conﬁguration is simple, easier handling of scheduled downtime
!18

Galera Cluster optimised for the cloud
• Optimised network protocol as packets are only exchanged over the WAN at
transaction commit time

• Topology-aware replication, so each transaction is sent to the data centre only
once

• Detection and automatic eviction of unreliable nodes

• eviction if due to network ﬂaps or node failure, will not be able to rejoin without
manual intervention

• Split brain recovery/management

• Traﬃc encryption (key in the cloud)
!19

MySQL InnoDB Cluster and group replication
• While the underlying protocol is diﬀerent, the paper it is based on is similar to Galera Cluster

• Newer kid on the block, Galera Cluster has been around for a long time (since 2007)

• e.g. features like failover consistency (eventual or “read your writes”) only appear in 8.0.14+

• You will have to use the MySQL Shell for administration, so something new to learn

• Single primary mode with automatic primary election or multi-primary mode (multi-master), where all servers
can accept updates issued concurrently (but this is sold as an advanced use case)

• There are limitations, e.g. around very large transactions to be executed, some of which get mitigated in an
unreleased 8.0.16 (where large messages are automatically fragmented). Also support for TLSv1.3 exists in
8.0.16, but this is not baked yet for group replication.

• Maximum of 9 servers in a group

• However, it does work on Microsoft Windows
!20

Galera Cluster branches
• Upstream: galeracluster.com

• Built-into MariaDB Galera Cluster — we work actively with MariaDB
Corporation, from roadmaps, testing systems together as well as working
with customers together.

• MariaDB Server 10.4 is the ﬁrst release candidate to include Galera
Cluster 4!

• Separate download as Percona XtraDB Cluster (PXC)
!21

Some feature highlights of Galera 3.x and 4
• Intelligent donor selection, preferring a donor that can do an Incremental
State Transfer (IST)

• Cluster crash recovery, say, after a power failure via pc.recovery=ON so all
nodes maintain cluster information persistently, not requiring a bootstrap

• Streaming replication, which replicates transactions of any size; transaction
replicated in small increments. Huge transaction support!

• Consistency voting protocol in the event of inconsistencies, all nodes vote
when such is detected

• DDL optimisation, so the lock only applies to the aﬀected table
!23

Cloud solutions
• By far, the most popular is Amazon Web Services Relational Database
Service (RDS) for MySQL / MariaDB Server

• Multi-AZ gives you High Availability, but no second readable node; it
makes use of DRBD for failover

• Amazon Aurora is gaining popularity for those that outgrow RDS, but
you’re not getting 100% MySQL (it is a branch of 5.6 and 5.7 with physical
replication)

• Google Cloud SQL oﬀers semi-synchronous replication
!25

Conclusion
• Codership: The developers and experts of Galera Cluster

• Galera Cluster used and deployed for over a decade in thousands of
environments

• If you’re looking for 5 9’s uptime, cannot tolerate downtime, data loss or a
loss in transactions, Galera Cluster could be the right solution for you!
!26

Questions?
Colin Charles, colin.charles@galeracluster.com

https://twitter.com/galeracluster | www.galeracluster.com
!27

The MySQL High Availability Landscape and where Galera Cluster fits in

Recommended

More Related Content

What's hot (20)

Similar to The MySQL High Availability Landscape and where Galera Cluster fits in (20)

Recently uploaded (20)

The MySQL High Availability Landscape and where Galera Cluster fits in