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.
Scalability is necessary to keep your database from crumbling under increased traffic. A scalable database must be able to handle larger data sets and more queries per second (both read and write), and the architecture must support these higher workloads seamlessly and efficiently. This blog attempts to explain what sharding is versus the pod architecture that some of our customers employ.
Tungsten is the go-to replication and clustering solution for MySQL - powering real-world, geo-distributed business-critical applications. Sometimes we get asked by those who are not familiar with us, what we mean by “MySQL,” and this blog is meant to shed some light on this question.
One of the common misconceptions about Continuent is that because Tungsten does not have an open source license, we do not support open source. In fact, quite the opposite, in everything we do. The whole purpose of Tungsten Clustering is to empower and enable teams that build business-critical applications on open source databases.
This leads us to the subject of this blog: how Tungsten is designed for openness.
There are many options for databases, and many organizations use multiple different types for their various use cases. In this blog we explore the use case of a business-critical or mission-critical application that requires a performant, robust and reliable OLTP RDBMS, and a few reasons to stick with a native open source database for this use case.
This is the third post in a short series about Tungsten Clustering topologies. In this post we will highlight the key differences between Composite Active/Passive, Composite Active/Active (CAA), and the newly available Dynamic Active/Active topology. In short, DAA blends the simplicity of CAP with the automated continuous operations of CAA.
You’ve seen the recent news about AWS outages; enterprises have to think about where their physical AWS data centers are and treat them as a single point of failure. As such, enterprises running business-critical and mission-critical applications are accounting for geography of public cloud resources in their business-continuity plans. Learn about a solution for continuous operations for your MySQL database that’s a step above traditional MySQL Disaster Recovery (DR).
This blog takes a look at three stacks: networking, LAMP, and the modern MySQL database clustering stack. The networking stack is a foundational element of geo-distributed MySQL database services. LAMP is a common software solution stack used by web and other client-server applications. The modern database clustering stack enables multi-site, multi-region and globally distributed MySQL database systems for continuous operations, which Tungsten Clustering provides in a complete, fully-integrated and tested package.
“How can I simulate a failure of the Active half of an Active/Passive Cluster to test the Failover to the Passive half?”
In this blog post we explore the best practices for simulating a failure of the Active cluster in an Active/Passive Composite Cluster.
As we are all being pushed to the limit to meet unprecedented demands online, the pandemic shined a light on many new frontiers and achievements in technology. This blog is about continuous MySQL database operations when you have a global user base, particularly the VMworld 2021 Global Multi-Cloud conference.
