Blog Series: MySQL High Availability (HA) & Disaster Recovery (DR)

This blog discusses Asynchronous versus Synchronous MySQL replication for MySQL clustering. Synchronous replication is viewed as the ‘holy grail’ of clustering. But unfortunately, when something is too good to be true, it often is. Before the Tungsten cluster solution Continuent built two synchronous replication cluster solutions (m/cluster, uni/cluster), but we abandoned those for good reasons.

What is the difference between MySQL replication and MySQL clustering? While clustering involves a layer of replication, the capabilities, benefits, and reasons for using clustering versus replication are very different. At Continuent, we offer both clustering and replication for your MySQL, MariaDB, and Percona MySQL - in the cloud, on-prem, hybrid-cloud and multi-cloud, with no application changes or downtime necessary.

Disaster Recovery for Continuous MySQL Operations does not have to be hard, but it does have to be WAN: Multi-Site, Hybrid-Cloud, Multi-Cloud. This blog discusses Business Continuity, Disaster Recovery, or “DR,” and an overlooked clustering feature that makes continuous database operations easy, affordable, and manageable.

Do-it-Yourself (DIY), database migration; what other approaches are there to challenges of MySQL availability, reliability, scalability and application performance?

Continuent Tungsten enables greater application availability and performance especially across WAN, it saves tons of manual labor and headache, it’s backed by premium 24/7/365 support, and it enables all sorts of new freedom and possibilities for data infrastructure including multi-cloud, hybrid-cloud, and advanced, real-time analytics.

People approach Continuent for many reasons, including: MySQL Continuous Operations: their business is using MySQL for business-critical applications that require zero downtime, including for maintenance updates MySQL Performance: their application performance and user experience are suffering due to a faltering MySQL backend

Real time database replication is a must for clustering and other key business purposes, like reporting. There are a number of replication technologies available for MySQL, and some are even bundled into various solutions. When choosing a replication methodology, it is paramount to understand just how the data moves from source to target. In this blog post, we will examine how asynchronous, synchronous, and "semi-synchronous" replication behave when used for clustering. Also, we will explore how replication affects database performance and data availability.

Database Administration is a tough, often ungrateful job. Especially if you run a 24/7 business-critical MySQL or MariaDB deployment.

Great SaaS - starts with great software. But not enough is said about the people and values behind great software; so that’s what I want to talk about here.

This blog explains data replication and clustering in a way that anybody can understand.

Enterprises require high availability for their business-critical applications. Even the smallest unplanned outage or even a planned maintenance operation can cause lost sales, productivity, and erode customer confidence. Additionally, updating and retrieving data needs to be robust to keep up with user demand.

Think about it - your global, cloud-based application needs to be online and available for the business to run. Downtime is to be avoided like the plague. Perhaps you even have multiple cloud providers to span.

How do we create a database service layer that handles all kinds of failures?

Think about it - your application needs to be online and available for the business to run. Downtime is to be avoided like the plague. The buzz is all about five nines of uptime.

How do we as systems architects, DBAs and sysadmins create an environment where routine maintenance is not a thing to be feared and put off, but embraced to allow for proper and needed updates and upgrades to take place?