This is the first in a series of use case blogs. It discusses the concept of ‘Geo-scale MySQL’ - or how to build a global, multi-region MySQL cloud back-end capable of serving hundreds of user accounts.
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.
Why does the DIY approach fail to deliver vs. the Tungsten Clustering solution for geo-distributed MySQL multimaster deployments? Before we dive into the 10 reasons, note why commercially-supported enterprise software is less risky and in fact less costly.
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.
Tungsten Clustering offers a graphical administration tool called the Tungsten Dashboard™ to help with your management burden. The GUI makes the deployment much easier to visualize and administer.
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?
In this blog post, we talk about how to run applications across multiple clouds (i.e. AWS, Google Cloud, Microsoft Azure) using Tungsten Clustering. You want your business-critical applications to withstand node, datacenter, availability-zone or regional failures. For SaaS apps, you also want to bring data close to your application users for faster response times and a better user experience. With cross-cloud capability, Tungsten also helps avoid lock-in to any particular cloud provider.
This distributed topology, perfect for multi-region SaaS models, allows you to have all the benefits of high availability with centralized writes and local reads for all regions. Latency is limited only by the WAN link and the speed of the target node.
