Blog

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.

Galera Cluster provides high availability and scalability for MySQL. While this provides high availability in a local region or site, it does not provide any provisions for disaster recovery (DR) or any multi-site deployment in general, so let’s explore how we could extend the functionality of Galera Cluster to deploy at geo-scale.

Recently a customer asked, “Are there any issues with running a specific node with parallel apply enabled, and the rest of the nodes using a single stream (parallel disabled)? Just curious because that would be easiest for A/B testing of the replication effects.” Firstly, the answer is yes, you may certainly enable Parallel Apply on a single node within a Tungsten Cluster.

In this blog post we explore the implications and best practices for using Parallel Apply in this way.

The tungsten_merge_logs command is designed to aid troubleshooting by consolidating the various log files into one place (merged.log), ordered by time. There are many moving parts to a cluster and they are spread over multiple nodes (usually three). When there is an issue, the logs are the key resource to find out what is going on. The best practice is to gather the log files into one place and then read through them all. This can be difficult with many files on multiple nodes. For this reason, the `tungsten_merge_logs` tool was created.

In this blog post we will explore the procedure for getting an email notification every time a file is uploaded to an AWS S3 bucket. Instead of having to poll the AWS S3 bucket manually for new uploads, we wanted a way to be notified by email every time a file landed. The solution was a combination of an SNS Topic used by an SNS Subscription, and called by an S3 bucket Event notification.

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.

A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they are within the same network. This blog provides step-by-step instructions on how to set up VPC networking between regions (also known as inter-region VPC peering connections).

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.

MySQL High Availability (HA) is typically what architects and technologists look for in building business-critical and mission-critical applications, and they aspire to measure MySQL uptime in 4 or preferably more “nines.” This blog explores the modern world of continuous MySQL operations - cross-region, global, hybrid-cloud, and multi-cloud - and why you might need a different approach.

A short contemplation about the current state of the programming languages. What language to choose for a new project? What are the differences between them? Is there a best language for everything?

Standards allow modern systems to advance, and the REST specification is one very important example. 

Since this post is about the Tungsten API in specific, let me simply say this - a RESTful API adheres to six principles: Client-server, stateless, cacheable, uniform interface, layered system and optionally code on demand. As part of the watchability/monitoring goal, our upcoming version 7.0.0 includes a proper RESTful API - what we call APIv2. This API will be fully documented and public.