High Availability with MariaDB Enterprise

© SkySQL Corporation Ab. Company Confidential.09/06/2014

© SkySQL Corporation Ab. Company Confidential.

High Availability with MariaDB Enterprise

Stephane VaroquiProfessional Services, SkySQL

* *09/06/2014


Agenda

❏ Introduction to High Availability❏Different services that need HA❏Different components of High Availability❏Different MariaDB HA Solutions

❏ HA using MariaDB Replication❏ HA using MariaDB Galera Cluster

09/06/2014


Introduction to High Availability

High availability is a system design protocol and associated

implementation that ensures a certain degree of operational continuity during

a given measurement period

09/06/2014



09/06/2014

❏High Availability != Long Uptime“up” might still not be accessible“down” just once, but for a long time

❏High Availability rather meansLong Mean Time Between Failures (MTBF)Short Mean Time To Recover (MTTR)



❏ Availability level is measured as the ratio of time the system is available over a year, expressed as a percentage

❏ 99.9% availability means that the system is available at least 8751 of 8760 hours in a year, or that it is unavailable at the most 9 hours per year

❏ 99.999% availability means that the system is available at least 525595 or 525600 minutes in a year, or that it is unavailable at the most 5 minutes per year

09/06/2014


Maintaining High Availability

❏ There are two common situations that we try to protect ourselves from using an HA solution❏ Datacenter failure – A whole datacenter

becomes unavailable for some reason, like power failure, network failure, a virus or similar situations

❏ Server failure – An individualserver fails because of ahardware failure or somethingsimilar

09/06/2014


Layers in HA Solution

❏ All services that make up the application stack needs HA for the system to achieve HA

Web serversApplication serversApplicationsDatabase serversStorageNetwork

09/06/2014

TCO for Unbreakable

Hardware


Services in an HA Solution

❏Of the different types of services, there are two types

Stateless servicesThese servers has no state beyond the current operation. If such a server fails, another server of the same type can replace it without having to transfer any set of data. Webservers and application servers are typical stateless services

Stateful servicesThese services maintains a state, and that state needs to be preserved if a server fails, and has to be made available to any other server that takes it place. A database service such as a MariaDB server is a typical stateful service

09/06/2014


Components of High Availability

❏Monitoring and ManagementAvailability of the services needs to be monitored, to be able to take action when there is a failure.A failover can be manual or automatic, but it has to be managed

❏ Failover / Load Balancing mechanismSome mechanism to redirect traffic from the failed server or Datacenter and to a working one

❏Data redundancyFor stateful services, we need to make sure that data is somehow made redundant

09/06/2014


Monitoring and Management

❏ There are many different solutions here, some focused on specific services (in particular database), some as part of a Load Balancing software solution of an Appliance or a pure software based solution such as LinuxHA, HaProxy, MaxScale, Mha

09/06/2014


Failover mechanism

❏ There is a wide range of options here too, in particular when it comes to Datacenter failover, which can be more complicated

❏ Common mechanisms range from application based failover and DNS failover to Load Balancing and Network Failover

09/06/2014


Data Redundancy

❏ Providing Data Redundancy is complex, error prone and takes a toll on performance

❏ It also has to be mentioned that a SAN does not provide redundancy just because a disk set can be failed over from one server to another. A SAN might be a SPOF, but in some cases that is a risk that some customers is willing to take

09/06/2014


Data Redundancy with MariaDB

❏ MariaDB Internal Replication❏ Assync❏ Semi-sync❏ Sync per table with spider

❏ MariaDB Galera Cluster

❏ Storage based redundancy (Active / Passive setups)❏ DRBD (Distributed Replicated Block Device)❏ SAN (Storage Area Network)❏ VMWare replication

09/06/2014


HA using MariaDB Replication

❏ In many cases best solution ❏ Well known and easy to use technology

❏ The cluster is very loosely coupled, not all nodes are aware of all the other nodes for example it’s self healing solution, no sensibility to network latency, and replication node speed (hardware variability)

❏ Offer the lowest master performance impact so far ❏ Multi node read scalability with best possible query

latency, network data distribution still slow vs in memory scale up (photonic bus & memory is for 2020)

09/06/2014



❏ In many cases the best solution

❏ Logical replication no corruption propagated

❏ Various topologies using multi source , storage engine switching, multi master , peer to peer

❏ Row vs Statement for strong network compression

❏MariaDB fixing the gotcha ❏ Parallel replication , group commit, checksum, heartbeat ❏ Can be extended with per session consistency using

GTID_POS_WAIT

09/06/2014


HA MariaDB Replication GTID

SET GLOBAL GTID_SLAVE_POS = BINLOG_GTID_POS("master-bin.00024", 1600);

CHANGE MASTER TO master_host="10.2.3.4", master_use_gtid=slave_pos; START SLAVE;

CHANGE MASTER TO master_host="10.2.3.5";



❏ Replication gotcha ❏ Can lose data on master crash without semi-sync and

semi sync performance should be address in next release❏ Adding a slave stay manual and complex (MyISAM)❏ Failover is more complex, found the most up to date

slave, depends external product like MHA and scripting to LB or HA solutions (maxscale can fix)

❏ Automatic Strong consistency (maxscale can fix)❏ No map reduce queries (spider temporary table can fix)

09/06/2014


HA using MariaDB❏ This a software-only solution

09/06/2014

MariaDB Server MariaDB Server MariaDB Server

Galera wsrep Library Galera wsrep Library Galera wsrep Library

Synchronous Replication

Load Balancer / Failover

Application / Application server


Installing MariaDB

❏ MariaDB Galera Cluster consists of separate MariaDB binary that in turns talks to the Galera wsrep library

❏ Once set up, Galera is configured using the usual my.cnf file, and is monitored using the SHOW GLOBAL STATUS command

09/06/2014


HA using MariaDB

09/06/2014

❏ Scales reads

❏ Limited impact on concurrent writes, despite long distance network latency

❏ Proper Cluster with easy failover, optimistic locking, split-brain protection, no possible data lost on failover

❏ Synchronous replication with low overhead due to optimistic locking , paxos queue, parallel event replication

❏ Transparent provisioning

❏Galera best point


HA using MariaDB

09/06/2014

❏ InnoDB only solution

❏ Network architecture reliability

❏ Local Committed Read only (select for update)

❏ Deadlock error prone

❏Galera dark side

For transactional scenarios it may still need read write splitting !


Failover with MariaDB

❏ MariaDB Galera Cluster handles failed servers internally provide a status, that tells about membership of the cluster

❏ MariaDB Galera Cluster also handles split-brain protection and this requires at least 3 servers

❏ MariaDB Galera Cluster can also be configured without split-brain protection, for example when failover is manual or is handled in some other way

09/06/2014


Setting up MariaDB

❏ Necessary to allow for protection against split-brain scenarios, but only using 2 database servers, a third server can be set up with a Galera specific arbitration agent (grbd)

❏ Galera also can be used with it’s own simple Load Balancer, (glb) , auto detect new nodes, although it is much more common that other technologies are used, such as HA aware Connectors or a Load Balancer, in this case use a backup policy and no load balancing for write

❏ For advance setup without application control, auto balancing reads and write to a single node we advise you to try out our maxscale proxy

09/06/2014


Questions?

09/06/2014

Technology

High Availability with MariaDB Enterprise