SlideShare a Scribd company logo
MariaDB High
Availability
Max Mether
Field CTO
High
Availability
Defined
In information technology,
high availability refers to a
system or component that is
continuously operational for a
desirably long length of time.
Availability – Wikipedia
up time / total time
Uptime,
Downtime, 9s
• 90% -> 36.5 days/year or 72 hours/month
• 99% -> 3.65 days/year or 7.2 hours/month
• 99.9% -> 8.76 hours/year or 43.8 minutes/month
• 99.99% -> 52.56 minutes/year or 4.38 minutes/month
• 99.999% -> 5.26 minutes/year or 25.9 seconds/month
• 99.9999% -> 31.5 seconds/year or 2.59 seconds/month
Availability = uptime /
(uptime + downtime)
Availability and HIGH Availability
Source: http://en.wikipedia.org/wiki/High_availability
High Availability Background
• High Availability isn’t always equal to long Uptime
– A system is “up” but it might not be accessible
– A system that is “down” just once, but for a long time, is NOT highly available
• High Availability rather means
– Long Mean Time Between Failures (MTBF)
– Short Mean Time To Recover (MTTR)
• High availability is:
– a system design protocol and associated implementation that ensures a certain degree of
operational continuity during a given measurement period.
Approach to HA
Backup /
Restore
1
< 99.9%
Replication /
Automatic
failover
3
~ 99.99%
Simple
replication /
manual
failover
2
~ 99.9%
3 nodes Galera
Cluster
~ 99.999%
4 5
Other
Strategies for High Availability
An average of 80 percent of mission-critical application service
downtime is directly caused by people or process failures. The
other 20 percent is caused by technology failure, environmental
failure or a disaster
Gartner Research
High Availability Components
High availability is a system design protocol and associated implementation that
ensures a certain degree of operational continuity during a measurement period.
For stateful services, we
need to make sure that
data is made redundant.
It is not a replace for
backups!
Data Redundancy
Some mechanism to
redirect traffic from the
failed server or
Datacenter to a working
one
Failover or Switchover
Solution
Availability of the
services needs to be
monitored, to take
action when there is a
failure or even to
prevent them
Monitoring and
Management
HA Dictionary
General Terms
• Single Point of Failure (SPOF)
– An element is a SPOF when its failure results in a full stop of the service as no other element
can take over (storage, WAN connection, replication channel)
– It is important to evaluate the costs for eliminating the SPOF, the likelyhood that it fails, the
time required to bring it into service again
• Shared Storage Architecture
– Shared storage systems like SANs can provide built-in high availability, though this comes with
equally high costs
– Not really suitable for Disaster Recover scenario on multiple Data Center
• Shared Nothing Architecture
– Each node is independent and self-sufficient
General Terms
• Split-Brain
– When nodes in the cluster continue running but cannot communicate causing them to be
inconsistent
– To be avoided at all cost
• Switchover
– When a manual process is used to switch from one system to a redundant or standby system in
case of a failure
• Failover
– Automatic switchover, without human intervention
• Failback
– A (often-underestimated) task to handle the recovery of a failed system and how to fail-back to
this system after recovery
Data Redundancy
HA for MariaDB
MariaDB Replication
• Replication enables data from one MariaDB server (the master) to be replicated to one or
more MariaDB servers (the slaves).
• MariaDB Replication is:
– very easy to setup
– used to scale out read workloads
– provide a first level of high availability and geographic redundancy
– offload backups and analytic jobs.
The Binary Log
• Each MariaDB server has a binary log that should be enabled in most cases
• The server stores all changes that happen on the server in the binary log
• The binary log has three modes:
a. ROW: Row change events are stored in the binary log
b. STATEMENT: SQL Statements that change data are stored in the binary log
c. MIXED: Most events are replicated in STATEMENT based but some ROW based
Asynchronous Replication
• MariaDB Replication is asynchronous by default.
• Slave determines how much to read and from which point in the binary log
• Slave can be behind master in reading and applying changes
• If the master crashes, transactions might not have been transmitted to any slave
• Asynchronous replication is great for read scaling as adding more replicas does not
impact replication latency
Asynchronous Replication Phases
• 3 phases for each transaction:
1. The transaction is committed and written to the masters binary log
2. The slave reads the transaction and writes it to its relay log
3. The transaction is applied on the slave
Asynchronous Replication-Switch Over
1. The master server is taken down or we encounter a fault by our monitoring
2. The slave server is updated to the last position in the relay log
3. The clients point at the designated slave server
4. The designated slave server becomes the master server
5. All steps are manual
Master and Slaves
ReadOnly Slaves
Master and Slaves
ReadOnly Slaves
Async Replication Topologies
Master and Slaves
ReadOnly Slaves
Master with Relay Slave Circular Replication
Semi-synchronous Replication
• MariaDB supports semi-synchronous replication:
– the master does not confirm transactions to the client application until at least one slave has
copied the change to its relay log, and flushed it to disk.
– In semi-synchronous replication, only after the events have been written to the relay log and
flushed the slave does acknowledge receipt of a transaction's events
– Semi-synchronous is a practical solution for many cases where high availability and no data-loss
is important.
– When a commit returns successfully, it is known that the data exists in at least two places (on the
master and at least one slave).
– Semi- synchronous has a performance impact due to the additional round trip
MariaDB Enhanced Semi-synchronous Replication
• One or more slaves can be defined as working semi-synchronously.
• For these slaves, the master waits until the I/O thread on one or more of the semi-synch slaves
has flushed the transaction to disk.
• This ensures that all committed transactions are at least stored in the relay log of the slave.
• Standard semi-synchronous replication would commit the transaction before it gets the
acknowledge of the binlog event from a slave (AFTER_COMMIT or AFTER_SYNC)
Semi-synchronous Replication – Switch Over
• The steps for a failover are the same as when using the standard replication
• but in Step 2, a slave should be chosen among those (if many) that are be semi- synched
with the master
Master and Slaves
Semi-Sync
Slave
Async Slaves
Master and Slaves
Async Slaves
Semi-Sync Replication Topologies
• Semi- synchronous replication is used between master
and backup master
• Semi- sync replication has a performance impact, but the
risk for data loss is minimized.
• This topology works well when performing master
failover
– The backup master acts as a warm-standby server
– it has the highest probability of having up-to-date data if
compared to other slaves.
Semi_sync
Asynchronous
ReadOnly/
Backup Master
ReadOnly
MariaDB Multi-Source Replication
• It enables a slave to receive transactions from
multiple sources simultaneously.
• It can be used to backup multiple servers to a
single server, to merge table shards, and
consolidate data from multiple servers to a single
server.
Master 2Master 1 Master 3
Slave
Synchronous Replication
MariaDB Galera Cluster
• Galera Replication is a synchronous multi-master
replication feature enables a true master-master
setup for InnoDB.
• Every node is a share nothing server
• All nodes are masters and applications can read and
write from any node
• A minimal Galera cluster consists of 3 nodes:
– A proper cluster needs to reach a quorum (i.e. the
majority of the nodes of the cluster)
• Transactions are synchronously committed on all
nodes.
MariaDB
MariaDB
MariaDB
How it works
• A transaction is started by connecting to one of the
nodes
• Everything (locks, modifications etc) is local until
the transaction is committed
• Upon commit, the writeset is sent out to the other
nodes for certificaton
• The other nodes verify that the transaction doesn't
conflict with any open transactions local to them and
at the same time store the writeset
• If certified the transaction is committed on all nodes
• If the certification fails (due to a conflict) the
transaction is aborted
MariaDB
MariaDB
MariaDB
MariaDB Cluster Pros
• PROS
– 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
MariaDB
MariaDB
MariaDB
MariaDB Cluster Cons
• CONS
– It only supports InnoDB
– The transaction rollback rate and hence the
transaction latency, can increase with the number of
the cluster nodes
– The cluster performs as its less performing note: an
overloaded master affects the performance of the
Galera cluster
MariaDB
MariaDB
MariaDB
MaxScale for HA
MDBE
Cluster Failover
Clustered nodes cooperate
to remain in sync
With multiple master nodes,
reads and updates both scale*
Synchronous replication with
optimistic locking delivers high
availability with little overhead
Fast failover because all
nodes remains synchronizedMariaDB
MariaDB
MariaDB
Load Balancing
and Failover
Application /
App Server
MaxScale Use Case
Master/Slaves Async
Replication
MaxScale monitors a MariaDB Topology
Master/Slaves + R/W split routing
Max
Scale
MariaDB
MaxScale Use Case
Master/Slaves Async
Replication
Master/Slaves + R/W split routing
Max
Scale
MariaDB
1
1 . Master failure
MaxScale Use Case
Master/Slaves Async
Replication
1 . Master failure
2 . MaxScale Monitor detects the master_down
event
Master/Slaves + R/W split routing
Max
Scale
MariaDB
script
Failover Script
Monitor
master_down event
2
MaxScale Use Case
Master/Slaves Async
Replication
1 . Master failure
2 . MaxScale Monitor detects the master_down
event
3 . In case it is configured, MaxScale launches a
Failover Script that promotes a slave as a new
Master
Master/Slaves + R/W split routing
Max
Scale
MariaDB
script
Failover Script
Monitor
master_down event
2
Promote as master3
MaxScale Use Case
Master/Slaves Async
Replication
1 . Master failure
2 . MaxScale Monitor detects the master_down
event
3 . In case it is configured, MaxScale launches a
Failover Script that promotes a slave as a new
Master
Master/Slaves + R/W split routing
Max
Scale
MariaDB
script
Failover Script
Monitor
master_down event
2
Promote as master3
MaxScale Use Case
Master/Slaves Async
Replication
1 . Master failure
2 . MaxScale Monitor detects the master_down
event
3 . In case it is configured, MaxScale launches a
Failover Script that promotes a slave as a new
Master
4 . MaxScale monitor automatically detects new
replication topology after the switch
Master/Slaves + R/W split routing
Max
Scale
MariaDB
Monitor 2
4
MaxScale Use Case
MDBE Cluster
Synchronous Replication
Each application server
uses only 1 connection
MaxScale selects one node
as “master” and the other
nodes as “slaves”
If the “master” node fails,
a new one can be elected
immediately
Galera Cluster + R/W split routing
Max
Scale
MariaDB HA: MaxScale
• Re-route traffic between
master and slave(s)
• Does not manage servers
• Failover / slave promotion
is an external process
• Implemented for Booking.com
• Part of MaxScale release
• All slaves are in sync,
easy to promote any slave
Read / Write Splitter
Detects Active Master
Binary Log
Server
Thank you
Max Mether
Field CTO
max@mariadb.com

More Related Content

What's hot

Höchste Datenbankleistung durch Anpassung und Optimierung
Höchste Datenbankleistung durch Anpassung und OptimierungHöchste Datenbankleistung durch Anpassung und Optimierung
Höchste Datenbankleistung durch Anpassung und Optimierung
MariaDB plc
 
Apache Kafka Best Practices
Apache Kafka Best PracticesApache Kafka Best Practices
Apache Kafka Best Practices
DataWorks Summit/Hadoop Summit
 
Chef conf-2015-chef-patterns-at-bloomberg-scale
Chef conf-2015-chef-patterns-at-bloomberg-scaleChef conf-2015-chef-patterns-at-bloomberg-scale
Chef conf-2015-chef-patterns-at-bloomberg-scale
Biju Nair
 
How to make data available for analytics ASAP
How to make data available for analytics ASAPHow to make data available for analytics ASAP
How to make data available for analytics ASAP
MariaDB plc
 
Global Data Replication with Galera for Ansell Guardian®
Global Data Replication with Galera for Ansell Guardian®Global Data Replication with Galera for Ansell Guardian®
Global Data Replication with Galera for Ansell Guardian®
MariaDB plc
 
02 2017 emea_roadshow_milan_ha
02 2017 emea_roadshow_milan_ha02 2017 emea_roadshow_milan_ha
02 2017 emea_roadshow_milan_ha
mlraviol
 
Planning for Disaster Recovery (DR) with Galera Cluster
Planning for Disaster Recovery (DR) with Galera ClusterPlanning for Disaster Recovery (DR) with Galera Cluster
Planning for Disaster Recovery (DR) with Galera Cluster
Codership Oy - Creators of Galera Cluster
 
Kafka blr-meetup-presentation - Kafka internals
Kafka blr-meetup-presentation - Kafka internalsKafka blr-meetup-presentation - Kafka internals
Kafka blr-meetup-presentation - Kafka internals
Ayyappadas Ravindran (Appu)
 
High Availability with MariaDB Enterprise
High Availability with MariaDB EnterpriseHigh Availability with MariaDB Enterprise
High Availability with MariaDB Enterprise
MariaDB Corporation
 
Master master vs master-slave database
Master master vs master-slave databaseMaster master vs master-slave database
Master master vs master-slave database
Wipro
 
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
confluent
 
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera ClusterWebinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
Continuent
 
Client Drivers and Cassandra, the Right Way
Client Drivers and Cassandra, the Right WayClient Drivers and Cassandra, the Right Way
Client Drivers and Cassandra, the Right Way
DataStax Academy
 
Apache Kafka
Apache KafkaApache Kafka
Apache Kafka
Joe Stein
 
From Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
From Message to Cluster: A Realworld Introduction to Kafka Capacity PlanningFrom Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
From Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
confluent
 
Running Galera Cluster on Microsoft Azure
Running Galera Cluster on Microsoft AzureRunning Galera Cluster on Microsoft Azure
Running Galera Cluster on Microsoft Azure
Codership Oy - Creators of Galera Cluster
 
MariaDB MaxScale
MariaDB MaxScaleMariaDB MaxScale
MariaDB MaxScale
MariaDB plc
 
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
Microsoft Technet France
 
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
Microsoft Technet France
 
PostreSQL HA and DR Setup & Use Cases
PostreSQL HA and DR Setup & Use CasesPostreSQL HA and DR Setup & Use Cases
PostreSQL HA and DR Setup & Use Cases
Ashnikbiz
 

What's hot (20)

Höchste Datenbankleistung durch Anpassung und Optimierung
Höchste Datenbankleistung durch Anpassung und OptimierungHöchste Datenbankleistung durch Anpassung und Optimierung
Höchste Datenbankleistung durch Anpassung und Optimierung
 
Apache Kafka Best Practices
Apache Kafka Best PracticesApache Kafka Best Practices
Apache Kafka Best Practices
 
Chef conf-2015-chef-patterns-at-bloomberg-scale
Chef conf-2015-chef-patterns-at-bloomberg-scaleChef conf-2015-chef-patterns-at-bloomberg-scale
Chef conf-2015-chef-patterns-at-bloomberg-scale
 
How to make data available for analytics ASAP
How to make data available for analytics ASAPHow to make data available for analytics ASAP
How to make data available for analytics ASAP
 
Global Data Replication with Galera for Ansell Guardian®
Global Data Replication with Galera for Ansell Guardian®Global Data Replication with Galera for Ansell Guardian®
Global Data Replication with Galera for Ansell Guardian®
 
02 2017 emea_roadshow_milan_ha
02 2017 emea_roadshow_milan_ha02 2017 emea_roadshow_milan_ha
02 2017 emea_roadshow_milan_ha
 
Planning for Disaster Recovery (DR) with Galera Cluster
Planning for Disaster Recovery (DR) with Galera ClusterPlanning for Disaster Recovery (DR) with Galera Cluster
Planning for Disaster Recovery (DR) with Galera Cluster
 
Kafka blr-meetup-presentation - Kafka internals
Kafka blr-meetup-presentation - Kafka internalsKafka blr-meetup-presentation - Kafka internals
Kafka blr-meetup-presentation - Kafka internals
 
High Availability with MariaDB Enterprise
High Availability with MariaDB EnterpriseHigh Availability with MariaDB Enterprise
High Availability with MariaDB Enterprise
 
Master master vs master-slave database
Master master vs master-slave databaseMaster master vs master-slave database
Master master vs master-slave database
 
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
 
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera ClusterWebinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera Cluster
 
Client Drivers and Cassandra, the Right Way
Client Drivers and Cassandra, the Right WayClient Drivers and Cassandra, the Right Way
Client Drivers and Cassandra, the Right Way
 
Apache Kafka
Apache KafkaApache Kafka
Apache Kafka
 
From Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
From Message to Cluster: A Realworld Introduction to Kafka Capacity PlanningFrom Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
From Message to Cluster: A Realworld Introduction to Kafka Capacity Planning
 
Running Galera Cluster on Microsoft Azure
Running Galera Cluster on Microsoft AzureRunning Galera Cluster on Microsoft Azure
Running Galera Cluster on Microsoft Azure
 
MariaDB MaxScale
MariaDB MaxScaleMariaDB MaxScale
MariaDB MaxScale
 
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...
 
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
Exchange 2013 Haute disponibilité et tolérance aux sinistres (Session 1/2 pre...
 
PostreSQL HA and DR Setup & Use Cases
PostreSQL HA and DR Setup & Use CasesPostreSQL HA and DR Setup & Use Cases
PostreSQL HA and DR Setup & Use Cases
 

Similar to MariaDB High Availability Webinar

Choosing the right high availability strategy
Choosing the right high availability strategyChoosing the right high availability strategy
Choosing the right high availability strategy
MariaDB plc
 
Fault tolerant presentation
Fault tolerant presentationFault tolerant presentation
Fault tolerant presentation
skadyan1
 
IBM MQ High Availabillity and Disaster Recovery (2017 version)
IBM MQ High Availabillity and Disaster Recovery (2017 version)IBM MQ High Availabillity and Disaster Recovery (2017 version)
IBM MQ High Availabillity and Disaster Recovery (2017 version)
MarkTaylorIBM
 
IBM MQ - High Availability and Disaster Recovery
IBM MQ - High Availability and Disaster RecoveryIBM MQ - High Availability and Disaster Recovery
IBM MQ - High Availability and Disaster Recovery
MarkTaylorIBM
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
Codership Oy - Creators of Galera Cluster
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
Sakari Keskitalo
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
Sakari Keskitalo
 
Maria DB Galera Cluster for High Availability
Maria DB Galera Cluster for High AvailabilityMaria DB Galera Cluster for High Availability
Maria DB Galera Cluster for High Availability
OSSCube
 
MariaDB Galera Cluster
MariaDB Galera ClusterMariaDB Galera Cluster
MariaDB Galera Cluster
Abdul Manaf
 
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
Continuent
 
Taking Full Advantage of Galera Multi Master Cluster
Taking Full Advantage of Galera Multi Master ClusterTaking Full Advantage of Galera Multi Master Cluster
Taking Full Advantage of Galera Multi Master Cluster
Codership Oy - Creators of Galera Cluster
 
Galera webinar migration to galera cluster from my sql async replication
Galera webinar migration to galera cluster from my sql async replicationGalera webinar migration to galera cluster from my sql async replication
Galera webinar migration to galera cluster from my sql async replication
Codership Oy - Creators of Galera Cluster
 
MySQL 5.7 clustering: The developer perspective
MySQL 5.7 clustering: The developer perspectiveMySQL 5.7 clustering: The developer perspective
MySQL 5.7 clustering: The developer perspective
Ulf Wendel
 
Db spof(mssql, my sql)
Db spof(mssql, my sql)Db spof(mssql, my sql)
Db spof(mssql, my sql)
재원 최
 
Database replication
Database replicationDatabase replication
Database replication
Arslan111
 
Megastore by Google
Megastore by GoogleMegastore by Google
Megastore by Google
Ankita Kapratwar
 
Training Slides: Basics 102: Introduction to Tungsten Clustering
Training Slides: Basics 102: Introduction to Tungsten ClusteringTraining Slides: Basics 102: Introduction to Tungsten Clustering
Training Slides: Basics 102: Introduction to Tungsten Clustering
Continuent
 
Replication.ppt
Replication.pptReplication.ppt
Replication.ppt
Mohamed716666
 
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
MariaDB Corporation
 
18 philbe replication stanford99
18 philbe replication stanford9918 philbe replication stanford99
18 philbe replication stanford99
ashish61_scs
 

Similar to MariaDB High Availability Webinar (20)

Choosing the right high availability strategy
Choosing the right high availability strategyChoosing the right high availability strategy
Choosing the right high availability strategy
 
Fault tolerant presentation
Fault tolerant presentationFault tolerant presentation
Fault tolerant presentation
 
IBM MQ High Availabillity and Disaster Recovery (2017 version)
IBM MQ High Availabillity and Disaster Recovery (2017 version)IBM MQ High Availabillity and Disaster Recovery (2017 version)
IBM MQ High Availabillity and Disaster Recovery (2017 version)
 
IBM MQ - High Availability and Disaster Recovery
IBM MQ - High Availability and Disaster RecoveryIBM MQ - High Availability and Disaster Recovery
IBM MQ - High Availability and Disaster Recovery
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
 
Using galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wanUsing galera replication to create geo distributed clusters on the wan
Using galera replication to create geo distributed clusters on the wan
 
Maria DB Galera Cluster for High Availability
Maria DB Galera Cluster for High AvailabilityMaria DB Galera Cluster for High Availability
Maria DB Galera Cluster for High Availability
 
MariaDB Galera Cluster
MariaDB Galera ClusterMariaDB Galera Cluster
MariaDB Galera Cluster
 
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!
 
Taking Full Advantage of Galera Multi Master Cluster
Taking Full Advantage of Galera Multi Master ClusterTaking Full Advantage of Galera Multi Master Cluster
Taking Full Advantage of Galera Multi Master Cluster
 
Galera webinar migration to galera cluster from my sql async replication
Galera webinar migration to galera cluster from my sql async replicationGalera webinar migration to galera cluster from my sql async replication
Galera webinar migration to galera cluster from my sql async replication
 
MySQL 5.7 clustering: The developer perspective
MySQL 5.7 clustering: The developer perspectiveMySQL 5.7 clustering: The developer perspective
MySQL 5.7 clustering: The developer perspective
 
Db spof(mssql, my sql)
Db spof(mssql, my sql)Db spof(mssql, my sql)
Db spof(mssql, my sql)
 
Database replication
Database replicationDatabase replication
Database replication
 
Megastore by Google
Megastore by GoogleMegastore by Google
Megastore by Google
 
Training Slides: Basics 102: Introduction to Tungsten Clustering
Training Slides: Basics 102: Introduction to Tungsten ClusteringTraining Slides: Basics 102: Introduction to Tungsten Clustering
Training Slides: Basics 102: Introduction to Tungsten Clustering
 
Replication.ppt
Replication.pptReplication.ppt
Replication.ppt
 
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
Hochverfügbarkeit mit MariaDB Enterprise - MariaDB Roadshow Summer 2014 Hambu...
 
18 philbe replication stanford99
18 philbe replication stanford9918 philbe replication stanford99
18 philbe replication stanford99
 

More from MariaDB plc

MariaDB Paris Workshop 2023 - MaxScale 23.02.x
MariaDB Paris Workshop 2023 - MaxScale 23.02.xMariaDB Paris Workshop 2023 - MaxScale 23.02.x
MariaDB Paris Workshop 2023 - MaxScale 23.02.x
MariaDB plc
 
MariaDB Paris Workshop 2023 - Newpharma
MariaDB Paris Workshop 2023 - NewpharmaMariaDB Paris Workshop 2023 - Newpharma
MariaDB Paris Workshop 2023 - Newpharma
MariaDB plc
 
MariaDB Paris Workshop 2023 - Cloud
MariaDB Paris Workshop 2023 - CloudMariaDB Paris Workshop 2023 - Cloud
MariaDB Paris Workshop 2023 - Cloud
MariaDB plc
 
MariaDB Paris Workshop 2023 - MariaDB Enterprise
MariaDB Paris Workshop 2023 - MariaDB EnterpriseMariaDB Paris Workshop 2023 - MariaDB Enterprise
MariaDB Paris Workshop 2023 - MariaDB Enterprise
MariaDB plc
 
MariaDB Paris Workshop 2023 - Performance Optimization
MariaDB Paris Workshop 2023 - Performance OptimizationMariaDB Paris Workshop 2023 - Performance Optimization
MariaDB Paris Workshop 2023 - Performance Optimization
MariaDB plc
 
MariaDB Paris Workshop 2023 - MaxScale
MariaDB Paris Workshop 2023 - MaxScale MariaDB Paris Workshop 2023 - MaxScale
MariaDB Paris Workshop 2023 - MaxScale
MariaDB plc
 
MariaDB Paris Workshop 2023 - novadys presentation
MariaDB Paris Workshop 2023 - novadys presentationMariaDB Paris Workshop 2023 - novadys presentation
MariaDB Paris Workshop 2023 - novadys presentation
MariaDB plc
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB plc
 
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
MariaDB plc
 
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-BackupMariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
MariaDB plc
 
Einführung : MariaDB Tech und Business Update Hamburg 2023
Einführung : MariaDB Tech und Business Update Hamburg 2023Einführung : MariaDB Tech und Business Update Hamburg 2023
Einführung : MariaDB Tech und Business Update Hamburg 2023
MariaDB plc
 
Hochverfügbarkeitslösungen mit MariaDB
Hochverfügbarkeitslösungen mit MariaDBHochverfügbarkeitslösungen mit MariaDB
Hochverfügbarkeitslösungen mit MariaDB
MariaDB plc
 
Die Neuheiten in MariaDB Enterprise Server
Die Neuheiten in MariaDB Enterprise ServerDie Neuheiten in MariaDB Enterprise Server
Die Neuheiten in MariaDB Enterprise Server
MariaDB plc
 
Introducing workload analysis
Introducing workload analysisIntroducing workload analysis
Introducing workload analysis
MariaDB plc
 
Under the hood: SkySQL monitoring
Under the hood: SkySQL monitoringUnder the hood: SkySQL monitoring
Under the hood: SkySQL monitoring
MariaDB plc
 
Introducing the R2DBC async Java connector
Introducing the R2DBC async Java connectorIntroducing the R2DBC async Java connector
Introducing the R2DBC async Java connector
MariaDB plc
 
MariaDB Enterprise Tools introduction
MariaDB Enterprise Tools introductionMariaDB Enterprise Tools introduction
MariaDB Enterprise Tools introduction
MariaDB plc
 
Faster, better, stronger: The new InnoDB
Faster, better, stronger: The new InnoDBFaster, better, stronger: The new InnoDB
Faster, better, stronger: The new InnoDB
MariaDB plc
 
The architecture of SkySQL
The architecture of SkySQLThe architecture of SkySQL
The architecture of SkySQL
MariaDB plc
 
What to expect from MariaDB Platform X5, part 1
What to expect from MariaDB Platform X5, part 1What to expect from MariaDB Platform X5, part 1
What to expect from MariaDB Platform X5, part 1
MariaDB plc
 

More from MariaDB plc (20)

MariaDB Paris Workshop 2023 - MaxScale 23.02.x
MariaDB Paris Workshop 2023 - MaxScale 23.02.xMariaDB Paris Workshop 2023 - MaxScale 23.02.x
MariaDB Paris Workshop 2023 - MaxScale 23.02.x
 
MariaDB Paris Workshop 2023 - Newpharma
MariaDB Paris Workshop 2023 - NewpharmaMariaDB Paris Workshop 2023 - Newpharma
MariaDB Paris Workshop 2023 - Newpharma
 
MariaDB Paris Workshop 2023 - Cloud
MariaDB Paris Workshop 2023 - CloudMariaDB Paris Workshop 2023 - Cloud
MariaDB Paris Workshop 2023 - Cloud
 
MariaDB Paris Workshop 2023 - MariaDB Enterprise
MariaDB Paris Workshop 2023 - MariaDB EnterpriseMariaDB Paris Workshop 2023 - MariaDB Enterprise
MariaDB Paris Workshop 2023 - MariaDB Enterprise
 
MariaDB Paris Workshop 2023 - Performance Optimization
MariaDB Paris Workshop 2023 - Performance OptimizationMariaDB Paris Workshop 2023 - Performance Optimization
MariaDB Paris Workshop 2023 - Performance Optimization
 
MariaDB Paris Workshop 2023 - MaxScale
MariaDB Paris Workshop 2023 - MaxScale MariaDB Paris Workshop 2023 - MaxScale
MariaDB Paris Workshop 2023 - MaxScale
 
MariaDB Paris Workshop 2023 - novadys presentation
MariaDB Paris Workshop 2023 - novadys presentationMariaDB Paris Workshop 2023 - novadys presentation
MariaDB Paris Workshop 2023 - novadys presentation
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentation
 
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server
 
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-BackupMariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
MariaDB SkySQL Autonome Skalierung, Observability, Cloud-Backup
 
Einführung : MariaDB Tech und Business Update Hamburg 2023
Einführung : MariaDB Tech und Business Update Hamburg 2023Einführung : MariaDB Tech und Business Update Hamburg 2023
Einführung : MariaDB Tech und Business Update Hamburg 2023
 
Hochverfügbarkeitslösungen mit MariaDB
Hochverfügbarkeitslösungen mit MariaDBHochverfügbarkeitslösungen mit MariaDB
Hochverfügbarkeitslösungen mit MariaDB
 
Die Neuheiten in MariaDB Enterprise Server
Die Neuheiten in MariaDB Enterprise ServerDie Neuheiten in MariaDB Enterprise Server
Die Neuheiten in MariaDB Enterprise Server
 
Introducing workload analysis
Introducing workload analysisIntroducing workload analysis
Introducing workload analysis
 
Under the hood: SkySQL monitoring
Under the hood: SkySQL monitoringUnder the hood: SkySQL monitoring
Under the hood: SkySQL monitoring
 
Introducing the R2DBC async Java connector
Introducing the R2DBC async Java connectorIntroducing the R2DBC async Java connector
Introducing the R2DBC async Java connector
 
MariaDB Enterprise Tools introduction
MariaDB Enterprise Tools introductionMariaDB Enterprise Tools introduction
MariaDB Enterprise Tools introduction
 
Faster, better, stronger: The new InnoDB
Faster, better, stronger: The new InnoDBFaster, better, stronger: The new InnoDB
Faster, better, stronger: The new InnoDB
 
The architecture of SkySQL
The architecture of SkySQLThe architecture of SkySQL
The architecture of SkySQL
 
What to expect from MariaDB Platform X5, part 1
What to expect from MariaDB Platform X5, part 1What to expect from MariaDB Platform X5, part 1
What to expect from MariaDB Platform X5, part 1
 

Recently uploaded

Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
Antonios Katsarakis
 
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge GraphGraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
Neo4j
 
Christine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptxChristine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptx
christinelarrosa
 
What is an RPA CoE? Session 2 – CoE Roles
What is an RPA CoE?  Session 2 – CoE RolesWhat is an RPA CoE?  Session 2 – CoE Roles
What is an RPA CoE? Session 2 – CoE Roles
DianaGray10
 
ScyllaDB Tablets: Rethinking Replication
ScyllaDB Tablets: Rethinking ReplicationScyllaDB Tablets: Rethinking Replication
ScyllaDB Tablets: Rethinking Replication
ScyllaDB
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving
 
"What does it really mean for your system to be available, or how to define w...
"What does it really mean for your system to be available, or how to define w..."What does it really mean for your system to be available, or how to define w...
"What does it really mean for your system to be available, or how to define w...
Fwdays
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
Miro Wengner
 
High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024
Vadym Kazulkin
 
Introduction of Cybersecurity with OSS at Code Europe 2024
Introduction of Cybersecurity with OSS  at Code Europe 2024Introduction of Cybersecurity with OSS  at Code Europe 2024
Introduction of Cybersecurity with OSS at Code Europe 2024
Hiroshi SHIBATA
 
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeckPoznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
FilipTomaszewski5
 
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectorsConnector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
DianaGray10
 
Principle of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptxPrinciple of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptx
BibashShahi
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
Javier Junquera
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
c5vrf27qcz
 
Day 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio FundamentalsDay 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio Fundamentals
UiPathCommunity
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
Neo4j
 
"NATO Hackathon Winner: AI-Powered Drug Search", Taras Kloba
"NATO Hackathon Winner: AI-Powered Drug Search",  Taras Kloba"NATO Hackathon Winner: AI-Powered Drug Search",  Taras Kloba
"NATO Hackathon Winner: AI-Powered Drug Search", Taras Kloba
Fwdays
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
Jason Yip
 

Recently uploaded (20)

Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
 
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge GraphGraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
 
Christine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptxChristine's Supplier Sourcing Presentaion.pptx
Christine's Supplier Sourcing Presentaion.pptx
 
What is an RPA CoE? Session 2 – CoE Roles
What is an RPA CoE?  Session 2 – CoE RolesWhat is an RPA CoE?  Session 2 – CoE Roles
What is an RPA CoE? Session 2 – CoE Roles
 
ScyllaDB Tablets: Rethinking Replication
ScyllaDB Tablets: Rethinking ReplicationScyllaDB Tablets: Rethinking Replication
ScyllaDB Tablets: Rethinking Replication
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
 
"What does it really mean for your system to be available, or how to define w...
"What does it really mean for your system to be available, or how to define w..."What does it really mean for your system to be available, or how to define w...
"What does it really mean for your system to be available, or how to define w...
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
 
High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024
 
Introduction of Cybersecurity with OSS at Code Europe 2024
Introduction of Cybersecurity with OSS  at Code Europe 2024Introduction of Cybersecurity with OSS  at Code Europe 2024
Introduction of Cybersecurity with OSS at Code Europe 2024
 
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeckPoznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
 
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectorsConnector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectors
 
Principle of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptxPrinciple of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptx
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
 
Day 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio FundamentalsDay 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio Fundamentals
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
 
"NATO Hackathon Winner: AI-Powered Drug Search", Taras Kloba
"NATO Hackathon Winner: AI-Powered Drug Search",  Taras Kloba"NATO Hackathon Winner: AI-Powered Drug Search",  Taras Kloba
"NATO Hackathon Winner: AI-Powered Drug Search", Taras Kloba
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
 

MariaDB High Availability Webinar

  • 2. High Availability Defined In information technology, high availability refers to a system or component that is continuously operational for a desirably long length of time. Availability – Wikipedia up time / total time
  • 3. Uptime, Downtime, 9s • 90% -> 36.5 days/year or 72 hours/month • 99% -> 3.65 days/year or 7.2 hours/month • 99.9% -> 8.76 hours/year or 43.8 minutes/month • 99.99% -> 52.56 minutes/year or 4.38 minutes/month • 99.999% -> 5.26 minutes/year or 25.9 seconds/month • 99.9999% -> 31.5 seconds/year or 2.59 seconds/month Availability = uptime / (uptime + downtime) Availability and HIGH Availability Source: http://en.wikipedia.org/wiki/High_availability
  • 4. High Availability Background • High Availability isn’t always equal to long Uptime – A system is “up” but it might not be accessible – A system that is “down” just once, but for a long time, is NOT highly available • High Availability rather means – Long Mean Time Between Failures (MTBF) – Short Mean Time To Recover (MTTR) • High availability is: – a system design protocol and associated implementation that ensures a certain degree of operational continuity during a given measurement period.
  • 5. Approach to HA Backup / Restore 1 < 99.9% Replication / Automatic failover 3 ~ 99.99% Simple replication / manual failover 2 ~ 99.9% 3 nodes Galera Cluster ~ 99.999% 4 5 Other Strategies for High Availability
  • 6. An average of 80 percent of mission-critical application service downtime is directly caused by people or process failures. The other 20 percent is caused by technology failure, environmental failure or a disaster Gartner Research
  • 7. High Availability Components High availability is a system design protocol and associated implementation that ensures a certain degree of operational continuity during a measurement period. For stateful services, we need to make sure that data is made redundant. It is not a replace for backups! Data Redundancy Some mechanism to redirect traffic from the failed server or Datacenter to a working one Failover or Switchover Solution Availability of the services needs to be monitored, to take action when there is a failure or even to prevent them Monitoring and Management
  • 9. General Terms • Single Point of Failure (SPOF) – An element is a SPOF when its failure results in a full stop of the service as no other element can take over (storage, WAN connection, replication channel) – It is important to evaluate the costs for eliminating the SPOF, the likelyhood that it fails, the time required to bring it into service again • Shared Storage Architecture – Shared storage systems like SANs can provide built-in high availability, though this comes with equally high costs – Not really suitable for Disaster Recover scenario on multiple Data Center • Shared Nothing Architecture – Each node is independent and self-sufficient
  • 10. General Terms • Split-Brain – When nodes in the cluster continue running but cannot communicate causing them to be inconsistent – To be avoided at all cost • Switchover – When a manual process is used to switch from one system to a redundant or standby system in case of a failure • Failover – Automatic switchover, without human intervention • Failback – A (often-underestimated) task to handle the recovery of a failed system and how to fail-back to this system after recovery
  • 12. MariaDB Replication • Replication enables data from one MariaDB server (the master) to be replicated to one or more MariaDB servers (the slaves). • MariaDB Replication is: – very easy to setup – used to scale out read workloads – provide a first level of high availability and geographic redundancy – offload backups and analytic jobs.
  • 13. The Binary Log • Each MariaDB server has a binary log that should be enabled in most cases • The server stores all changes that happen on the server in the binary log • The binary log has three modes: a. ROW: Row change events are stored in the binary log b. STATEMENT: SQL Statements that change data are stored in the binary log c. MIXED: Most events are replicated in STATEMENT based but some ROW based
  • 14. Asynchronous Replication • MariaDB Replication is asynchronous by default. • Slave determines how much to read and from which point in the binary log • Slave can be behind master in reading and applying changes • If the master crashes, transactions might not have been transmitted to any slave • Asynchronous replication is great for read scaling as adding more replicas does not impact replication latency
  • 15. Asynchronous Replication Phases • 3 phases for each transaction: 1. The transaction is committed and written to the masters binary log 2. The slave reads the transaction and writes it to its relay log 3. The transaction is applied on the slave
  • 16. Asynchronous Replication-Switch Over 1. The master server is taken down or we encounter a fault by our monitoring 2. The slave server is updated to the last position in the relay log 3. The clients point at the designated slave server 4. The designated slave server becomes the master server 5. All steps are manual Master and Slaves ReadOnly Slaves Master and Slaves ReadOnly Slaves
  • 17. Async Replication Topologies Master and Slaves ReadOnly Slaves Master with Relay Slave Circular Replication
  • 18. Semi-synchronous Replication • MariaDB supports semi-synchronous replication: – the master does not confirm transactions to the client application until at least one slave has copied the change to its relay log, and flushed it to disk. – In semi-synchronous replication, only after the events have been written to the relay log and flushed the slave does acknowledge receipt of a transaction's events – Semi-synchronous is a practical solution for many cases where high availability and no data-loss is important. – When a commit returns successfully, it is known that the data exists in at least two places (on the master and at least one slave). – Semi- synchronous has a performance impact due to the additional round trip
  • 19. MariaDB Enhanced Semi-synchronous Replication • One or more slaves can be defined as working semi-synchronously. • For these slaves, the master waits until the I/O thread on one or more of the semi-synch slaves has flushed the transaction to disk. • This ensures that all committed transactions are at least stored in the relay log of the slave. • Standard semi-synchronous replication would commit the transaction before it gets the acknowledge of the binlog event from a slave (AFTER_COMMIT or AFTER_SYNC)
  • 20. Semi-synchronous Replication – Switch Over • The steps for a failover are the same as when using the standard replication • but in Step 2, a slave should be chosen among those (if many) that are be semi- synched with the master Master and Slaves Semi-Sync Slave Async Slaves Master and Slaves Async Slaves
  • 21. Semi-Sync Replication Topologies • Semi- synchronous replication is used between master and backup master • Semi- sync replication has a performance impact, but the risk for data loss is minimized. • This topology works well when performing master failover – The backup master acts as a warm-standby server – it has the highest probability of having up-to-date data if compared to other slaves. Semi_sync Asynchronous ReadOnly/ Backup Master ReadOnly
  • 22. MariaDB Multi-Source Replication • It enables a slave to receive transactions from multiple sources simultaneously. • It can be used to backup multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. Master 2Master 1 Master 3 Slave
  • 23. Synchronous Replication MariaDB Galera Cluster • Galera Replication is a synchronous multi-master replication feature enables a true master-master setup for InnoDB. • Every node is a share nothing server • All nodes are masters and applications can read and write from any node • A minimal Galera cluster consists of 3 nodes: – A proper cluster needs to reach a quorum (i.e. the majority of the nodes of the cluster) • Transactions are synchronously committed on all nodes. MariaDB MariaDB MariaDB
  • 24. How it works • A transaction is started by connecting to one of the nodes • Everything (locks, modifications etc) is local until the transaction is committed • Upon commit, the writeset is sent out to the other nodes for certificaton • The other nodes verify that the transaction doesn't conflict with any open transactions local to them and at the same time store the writeset • If certified the transaction is committed on all nodes • If the certification fails (due to a conflict) the transaction is aborted MariaDB MariaDB MariaDB
  • 25. MariaDB Cluster Pros • PROS – 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 MariaDB MariaDB MariaDB
  • 26. MariaDB Cluster Cons • CONS – It only supports InnoDB – The transaction rollback rate and hence the transaction latency, can increase with the number of the cluster nodes – The cluster performs as its less performing note: an overloaded master affects the performance of the Galera cluster MariaDB MariaDB MariaDB
  • 28. MDBE Cluster Failover Clustered nodes cooperate to remain in sync With multiple master nodes, reads and updates both scale* Synchronous replication with optimistic locking delivers high availability with little overhead Fast failover because all nodes remains synchronizedMariaDB MariaDB MariaDB Load Balancing and Failover Application / App Server
  • 29. MaxScale Use Case Master/Slaves Async Replication MaxScale monitors a MariaDB Topology Master/Slaves + R/W split routing Max Scale MariaDB
  • 30. MaxScale Use Case Master/Slaves Async Replication Master/Slaves + R/W split routing Max Scale MariaDB 1 1 . Master failure
  • 31. MaxScale Use Case Master/Slaves Async Replication 1 . Master failure 2 . MaxScale Monitor detects the master_down event Master/Slaves + R/W split routing Max Scale MariaDB script Failover Script Monitor master_down event 2
  • 32. MaxScale Use Case Master/Slaves Async Replication 1 . Master failure 2 . MaxScale Monitor detects the master_down event 3 . In case it is configured, MaxScale launches a Failover Script that promotes a slave as a new Master Master/Slaves + R/W split routing Max Scale MariaDB script Failover Script Monitor master_down event 2 Promote as master3
  • 33. MaxScale Use Case Master/Slaves Async Replication 1 . Master failure 2 . MaxScale Monitor detects the master_down event 3 . In case it is configured, MaxScale launches a Failover Script that promotes a slave as a new Master Master/Slaves + R/W split routing Max Scale MariaDB script Failover Script Monitor master_down event 2 Promote as master3
  • 34. MaxScale Use Case Master/Slaves Async Replication 1 . Master failure 2 . MaxScale Monitor detects the master_down event 3 . In case it is configured, MaxScale launches a Failover Script that promotes a slave as a new Master 4 . MaxScale monitor automatically detects new replication topology after the switch Master/Slaves + R/W split routing Max Scale MariaDB Monitor 2 4
  • 35. MaxScale Use Case MDBE Cluster Synchronous Replication Each application server uses only 1 connection MaxScale selects one node as “master” and the other nodes as “slaves” If the “master” node fails, a new one can be elected immediately Galera Cluster + R/W split routing Max Scale
  • 36. MariaDB HA: MaxScale • Re-route traffic between master and slave(s) • Does not manage servers • Failover / slave promotion is an external process • Implemented for Booking.com • Part of MaxScale release • All slaves are in sync, easy to promote any slave Read / Write Splitter Detects Active Master Binary Log Server
  • 37. Thank you Max Mether Field CTO max@mariadb.com