Blog

We are pleased to announce that Tungsten Clustering and Tungsten Replicator GA versions 7.0 are now available. This new major release includes the Tungsten RESTful API (API v2.0), enhanced security, monitoring, performance, management, new commands, a new and improved Dashboard, and new Dynamic Active/Active (DAA) topology. Tungsten v7.0 is the culmination of years of planning and work, and it lays the foundation for even more pinnacle developments. Read this blog to learn about the new v7 release!

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.

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.

Watch the replay of this webinar to learn about how Modernizing Medicine dealt with a lack of high availability in AWS with the help of Continuent Tungsten and/or sign up for one of our other upcoming use case webinars in this series.

Where are the logs for a Tungsten Cluster and which are the proper log files to monitor if I do a master role switch to another node?

Latency-sensitive applications running in Java sometimes experience unacceptable delays under heavy I/O load. This blog discusses why this problem occurs and what to do about it for applications running Tungsten Clustering for MySQL.

In this blog post we will discuss how to best integrate various Continuent-bundled cluster monitoring solutions with PagerDuty (pagerduty.com), a popular alerting service.

This post covers some standard Nagios checks that would keep your MySQL / MariaDB / Percona Server cluster nodes healthy.

A robust monitoring setup is essential for cluster health and viability - if your replicator goes offline and you do not know about it, then that Replica becomes effectively useless because it has stale data. This means keeping a close watch on the health of the MySQL / MariaDB / Percona Server database nodes from many perspectives, from ensuring sufficient disk space to testing that replication traffic is flowing.