High availability and disaster recovery:
replication, clustering and restore/rollback
When it comes to databases, high availability (HA) and disaster recovery (DR) should not require expensive solutions with complex architectures. HA/DR should be built-in, easy to use and flexible enough for any use case.
The choice is yours
Choose between asynchronous, semi-synchronous or synchronous replication to find the balance of performance, consistency and availability for your application(s) – including synchronous replication with automatic failover for maximum uptime with multi-master clustering.
Top 5 reasons to choose MariaDB TX
Replication and clustering
You can use asynchronous and semi-synchronous master/slave replication built on the binary log (binlog), global transaction IDs (GTIDs) and innovative performance options: parallel replication, delayed replication, read throttling, binlog compression and more. If that’s not enough, you can use synchronous replication via multi-master clustering.
Transparent topology changes
You can use MariaDB MaxScale, a next-generation database proxy, to not only detect topology changes, but to make them without having to update the application, enabling database administrators to add/remove nodes on demand or perform a failover – ideal during a spike in traffic or unplanned hardware/network issues.
You can use MariaDB MaxScale to support automatic failover by promoting the slave to master in a simple two-node deployments, or when there are multiple slaves, executing a command line script to perform a failover when the master fails or detecting topology changes when third-party tools (e.g., MHA) perform an automatic failover.
Denial of service protection
You can use MariaDB MaxScale, with its built-in firewall and result set limiting, to prevent malicious queries from returning excessive results, thousands, millions or billions of rows, to reduce availability by slowing down your database.
You get backup/restore tools with encryption and compression support (e.g., MariaDB Backup) as well as MariaDB Flashback, a recovery tool for point-in-time rollback using the binary log – enabling database administrators to recover data faster by rolling back the entire database, or a single table, to a previous point in time without performing a full restore.
Example: HA topology with intelligent routing
The example topology below uses MariaDB Cluster for synchronous, multi-master replication and MariaDB MaxScale for splitting read and writes, routing all writes to a single node (chosen by the proxy) and routing all reads to remaining nodes with load balancing.
Best practices for high availability with MariaDB TX
You have options, but when it comes to choosing between master/slave replication or multi-master clustering, asynchronous or semi-synchronous replication and manual or automatic failover, it helps to understand the pros and cons as well as the impact on performance and consistency.
In this webinar, we’ll discuss:
- Strategies for achieving high availability
- Pros and cons of different approaches
- Use cases and different topologies
- Methods of failover, switchover and failback
- Transparent topology changes with a proxy
- Tools for managing disaster recovery