Posts by Eric M. Stone

In our last blog post on this topic we covered the basics of the new REST  API available with Tungsten version 7.0.0. In this post, Part 2, we explore the REST API in more detail, including payloads and advanced functionality. The API provides a vast pool of capabilities, and here we barely scratch the surface of what can be accomplished.

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.

In this short post we will highlight the key differences between Multi-Site Active/Active (MSAA) and Composite Active/Active (CAA) topologies. The core principle behind an active/active topology is that you have more than one writable cluster. So why do we have more than one type of Active/Active topology?

As system administrators, we are called upon to be responsible for a vast quantity of discrete subsystems, each with its own set of operating rules. When starting and stopping any subsystem, it is the best practice to do so gracefully whenever possible to ensure data integrity. In this blog post, we detail the best practices for stopping and starting a Tungsten Cluster.

Recently, a Continuent customer asked: “What is your approach for scaling up MySQL clusters for a higher number of queries per second and larger data sets?” Scaling, like availability, is a multifaceted question. In this blog post we will detail and discuss the best practices for scaling Tungsten Clusters.

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.

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.

“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).

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.