High Availability with MariaDB Enterprise
Download as PPTX, PDF3 likes3,049 views
The document discusses high availability (HA) with MariaDB, detailing the importance of system design to ensure operational continuity. It covers various HA solutions including replication and Galera clusters, the significance of monitoring and failover mechanisms, and the need for data redundancy. Finally, it emphasizes the challenges and complexities associated with maintaining high availability, especially in relation to database services.
High Availability with MariaDB Enterprise
- 1. © SkySQL Corporation Ab. Company Confidential.09/06/2014
- 2. © SkySQL Corporation Ab. Company Confidential. High Availability with MariaDB Enterprise Stephane Varoqui Professional Services, SkySQL * *09/06/2014
- 3. © SkySQL Corporation Ab. Company Confidential. 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
- 4. © SkySQL Corporation Ab. Company Confidential. 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
- 5. © SkySQL Corporation Ab. Company Confidential. Introduction to High Availability 09/06/2014 ❏ High Availability != Long Uptime “up” might still not be accessible “down” just once, but for a long time ❏ High Availability rather means Long Mean Time Between Failures (MTBF) Short Mean Time To Recover (MTTR)
- 6. © SkySQL Corporation Ab. Company Confidential. Introduction to High Availability ❏ 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
- 7. © SkySQL Corporation Ab. Company Confidential. 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 individual server fails because of a hardware failure or something similar 09/06/2014
- 8. © SkySQL Corporation Ab. Company Confidential. Layers in HA Solution ❏ All services that make up the application stack needs HA for the system to achieve HA Web servers Application servers Applications Database servers Storage Network 09/06/2014 TCO for Unbreakable Hardware
- 9. © SkySQL Corporation Ab. Company Confidential. Services in an HA Solution ❏ Of the different types of services, there are two types Stateless services These 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 services These 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
- 10. © SkySQL Corporation Ab. Company Confidential. Components of High Availability ❏ Monitoring and Management Availability 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 mechanism Some mechanism to redirect traffic from the failed server or Datacenter and to a working one ❏ Data redundancy For stateful services, we need to make sure that data is somehow made redundant 09/06/2014
- 11. © SkySQL Corporation Ab. Company Confidential. 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
- 12. © SkySQL Corporation Ab. Company Confidential. 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
- 13. © SkySQL Corporation Ab. Company Confidential. 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
- 14. © SkySQL Corporation Ab. Company Confidential. 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
- 15. © SkySQL Corporation Ab. Company Confidential. 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
- 16. © SkySQL Corporation Ab. Company Confidential. HA using MariaDB Replication ❏ 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
- 17. © SkySQL Corporation Ab. Company Confidential. 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";
- 18. © SkySQL Corporation Ab. Company Confidential. HA using MariaDB Replication ❏ 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
- 19. © SkySQL Corporation Ab. Company Confidential. 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
- 20. © SkySQL Corporation Ab. Company Confidential. 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
- 21. © SkySQL Corporation Ab. Company Confidential. 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
- 22. © SkySQL Corporation Ab. Company Confidential. 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 !
- 23. © SkySQL Corporation Ab. Company Confidential. 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
- 24. © SkySQL Corporation Ab. Company Confidential. 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
- 25. © SkySQL Corporation Ab. Company Confidential. Questions? 09/06/2014