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.

Approach to HA

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.

White Paper

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.

Automatic failover

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.

Disaster recovery

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.

MariaDB Master Synchronous Replication

Recorded Webinar

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