Blog

This blog is about testing time and test suites management. “Battle-tested” is the Continuent Tungsten QA (Quality Assurance) guarantee. Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB used by some of the largest MySQL estates to achieve continuous MySQL operations, locally and globally (HA, DR and Geo Distribution). Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “Tungsten just works.”

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.

If Continuent Support was depicted as a cartoon character, who would you choose? I know who I would choose...I’ll give you a clue...Very Fast...Beep Beep…

In this blog we will explore Continuent Support...What we do, how we do it and the tools available to the customer that make all that happen at lightning speed.

On August 20th, 2020 we released v6.1.6 of our Tungsten Clustering and Tungsten Replicator products. On August 17th, 2021, we released v6.1.14. In this blog we take a look back over the last 12 months and highlight some of our key updates and fixes.

This blog is about Bug Hunting. “Battle-tested” is the Continuent Tungsten QA (Quality Assurance) guarantee. Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB used by some of the largest MySQL estates to achieve continuous MySQL operations, locally and globally (HA, DR and Geo Distribution). Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “Tungsten just works.”

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.

“Battle-tested” is the Continuent Tungsten QA (Quality Assurance) guarantee. Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB used by some of the largest MySQL estates to achieve continuous MySQL operations and uptime; why? Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “It just works.”“Battle-tested” is the Continuent Tungsten QA (Quality Assurance) guarantee. Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB used by some of the largest MySQL estates to achieve continuous MySQL operations and uptime; why? Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “It just works.”

Doing a search with InnoDB Cluster with DR (Disaster Recovery) yields lots of results, but does it actually work in the enterprise?

Doing a search with InnoDB Cluster with DR (Disaster Recovery) yields lots of results, but does it actually work in the enterprise?

For MySQL and MariaDB database clusters, Saas, Fintech and other organizations with mission-critical databases typically require what’s called a managed “composite” cluster, or “cluster-of-clusters.” This blog is about active/active versus active/passive composite clusters for MySQL and MariaDB database systems.

This blog is the first blog in a new series about Tungsten’s QA (Quality Assurance). Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB, used by some of the largest MySQL estates to achieve continuous MySQL operations and uptime; why? Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “It just works.”

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.