Recovery & Repair

MHA (Master High Availability) is a popular failover solution used in MySQL Master-Slave topologies. It is stable and used in production by large companies such as Facebook. In this blog, we outline the most common but important issues that you might encounter when running MHA. We’ll also see how to resolve them.

It might not be possible to avoid disasters, but with some preparation, it is certainly feasible to reduce the impact on your business. Automatic failover is one of those things. The goal of database failover automation is to minimize your downtime and reduce loss of money. However, failover can not always be automated as there are risks; false positives may lead to unnecessary escalations.

In this blog, we’ll have a look components you may use to build an automated stack, and take a closer look at ClusterControl’s failover functionality.

TimescaleDB uses a stream of write-ahead log (WAL) records to keep the standby databases synchronized. In this blog, we’ll review some concepts related to Streaming Replication and how ClusterControl can help us configure it in an easy way.

In case of master failure in a MySQL Replication setup, the most updated slave can be promoted to new master and all slaves repointed to the new master. But once the failed master has been fixed, what is the best way to re-introduce it as master, so as to restore the original topology.

This blog post shows how to perform the MySQL master failback operation.

Failover is the process of moving to a healthy standby component, during a failure or maintenance event. The quicker it can be done, the faster you can be back online. If you’re looking at minimizing downtime and meet your SLAs through an automated approach for TimescaleDB, then this blog is for you.

How do I ensure that MHA (Master High Availability Manager) will always perform the failover for me? What would happen if it crashes? This blog post will answer your questions.

To insulate our database infrastructure from failures, we build redundant cluster systems. For instance, MySQL and MariaDB high availability can be implemented by master-slave as well as master-master replication solutions. There are a number of variables that affect our choice solution. In this blog, we will look into considerations around latency.

Business continuity for databases means databases must be continuously operational even during the disasters. It is imperative to ensure that production databases are available for the applications all the time even during the disasters, otherwise, could end-up being an expensive deal.

In a busy database environment with larger size databases, the need for real-time data replication is a common occurrence. Applications often need the production data to be replicated in real-time to remote sites for analytics and other critical business operations needs. This blog provides an overview of several options you can use to replicate your PostgreSQL data to a remote site.

Replication and Galera Cluster are both widely used to implement high availability for MySQL/MariaDB, but when should you pick one over the other? What are the limitations of each solution, and what are the trade offs?
In this blog post, we will look at the differences in terms of data consistency, conflict resolution, failover, node provisioning and robustness.

Learn how to set up a Galera cluster with just 2 nodes and use Garbd to retain high availability.

This blog explains how to utilize streaming replication and point in time recovery to achieve high availability using failover.

Watch the replay of this webinar for a detailed overview of what failover processes may look like in MySQL, MariaDB and PostgreSQL replication setups. We’ll cover the dangers related to the failover process and look at how ClusterControl manages it as well as how it can be configured for both assisted and automated failover.

A delayed replication slave is useful in recovering from accidental data deletion. But how long should the delay be? Too short delay might not be enough for you to get to a terminal and stop an offending query. Too long delay means a long recovery time when catching up.

This blog post shows how to deploy multiple MySQL delayed slaves on one single physical host with Docker, and shows some of the recovery scenarios.

Maintenance is something that an operation team can not avoid. ClusterControl can be configured to simplify your maintenance routines. In this post, we’ll show you some advanced use cases of cluster-wide maintenance with iterations using ClusterControl CLI.

In this blog, we will review some important concepts of High Availability, possible database HA architectures and useful components when implementing PostgreSQL HA. Then we will see how to use ClusterControl to deploy an entire high availability stack for PostgreSQL.

ClusterControl provides you with a set of monitoring and performance advisors to add stability to your database infrastructures. It enables you to detect and solve unique problems in your environments. In this blog, you will see how you can also create custom advisors to extend your database environment monitoring with ClusterControl for free.

How do you get multiple databases to co-exist in Postgres? Do you place them in separate databases within the same cluster? Or is a harder separation approach better? Are there any implications on security or the ability to get a consolidated view of the data? As we will see in this blog, there are different approaches to consider.

With this blog post we aim to give you an introduction to failover handling in MySQL & MariaDB by discussing what failover is, why it is unavoidable and what the difference is between failover and switchover. We also discuss the failover process in its most generic form and touch a bit on different issues that you will have to deal with in relation to the failover process.

Watch the replay of this webinar with Vinay Joosery, CEO at Severalnines, during which he explains key disaster recovery concepts and walks us through the relevant options from the MySQL & MariaDB ecosystem in order to meet different tiers of disaster recovery requirements; and learn how ClusterControl can help user fully automate an appropriate disaster recovery plan.

Asynchronous replication places no low latency demands on the network, so it is possible to keep Galera Clusters in sync even when they are thousands of miles apart and utilise low-cost connections. We effectively can achieve a global system of loosely-coupled clusters. However, managing the global state translates into managing failover and failback operations at both node and cluster level.