Migrating to the cloud with zero downtime is a problem that companies running mission-critical applications have to solve, but not on their own. If you’re running a MySQL or MariaDB database it can be easy. Many of our customers have done this successfully, simplifying their overall Cloud migration process by making the database layer easy to move. It’s one less thing to worry about.
Thinking transparent reconnects of applications is the grail of HA? It is! But Active/Active setups make them risky.
When an application is a primary source of revenue for an organization, keeping Production operations going is critical. This blog discusses three things that can help prevent issues in Production. In fact, that’s why multiple environments exist - to make sure that the final act, delivered in Production, runs smoothly; read on to find out how to make sure your labor is not in vain!
In this blog post we examine in depth how to best provision one MySQL database cluster node from another using rsync. Since there are many possible ways to handle provisioning by rsync, we will do multiple posts on the topic, starting with the most basic - both the source and target database nodes are fully offline for the duration of the rsync. While this is not an ideal scenario because two nodes are down at once, it does allow one replica to be provisioned from another replica when all else fails.
Migrating from Galera to Tungsten Clustering is easy with the tools provided by Tungsten Clustering. Because replication happens in the background, applications can stay online with a quick cutover to Tungsten Clustering when ready.
A telco company recently came to us looking for an improvement to their Galera deployment. Their two main complaints were the unplanned downtime forced by Galera Cluster [aka MariaDB Cluster or Percona XtraDB Cluster], and the lack of reliable geo-scale deployment.
Continuent showed them how our solution, Tungsten Clustering, provides maximum MySQL uptime and is built for geo-scale (active/passive and active/active) MySQL deployments.
Performing MySQL schema changes often requires downtime for applications. In this blog, we cover two ways we can perform MySQL schema changes without risking downtime or other MySQL data problems. In this real-life customer example, we perform a schema change to modify the column data type from varchar(20) to varchar(50) on approx. 35 tables from 3GB to 10GB in size. Two of the tables are partitioned, and one of them is about 100GB combining all partitions for that table.
This MySQL high availability and disaster recovery use case is based on a customer of ours who is a government-regulated lottery service and who needs 24x7x365 operations as well as be able to perform maintenance without any disruption to their public facing gaming website.
This is the second post in a series of MySQL case study blogs. It discusses a SaaS provider dealing with sensitive medical data and their need to be able to quickly deploy clusters in AWS and recover from multi-zone AWS outages.
