Posts by Eric M. Stone

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.

Prometheus is one of the more popular ways to monitor your resources, and starting with version 7.0.0, Continuent has embedded the Prometheus exporter functionality into our core MySQL and MariaDB clustering products. This blog post covers how to enable the exporters, getting metrics and what metrics are available, along with cli tools, customizing the config, documentation references and a little bit about Grafana Dashboard for Tungsten Clusters.

Continuent provides multiple methods out of the box to monitor the cluster health. It integrates with monitoring and alerting tools like Nagios/NRPE, Zabbix, and Pagerduty. This blog post shows you the thinking behind each included Tungsten Cluster monitoring tool, and when to use which tool.

This blog is about troubleshooting failed DDL across all Replicas in a composite active/active (CAA) Tungsten Cluster. The issue was resolved by setting a more permissive SQL_MODE, then locating and cleaning the bad data with proper NULLs before re-issuing the ALTER TABLE.

Customers often use AWS to deploy MySQL or MariaDB Tungsten Clusters. This blog is about changing an AWS instance type from t2.large to t3.large specifically on Amazon Linux 1. It contains the steps to follow when changing AWS instance families to use enhanced networking.

SmartScale is a special mode of the Tungsten Connector (aka Tungsten Proxy), which allows read requests to be intelligently routed to either a replica or the primary to ensure that the data returned is not stale. This feature is available when the Connector is running in the application-layer Proxy mode. Learn more about the behavior of SmartScale in this blog.