The Question Recently, a customer asked us:

What would cause a node switch to fail in a Tungsten Cluster?

For example, we saw the following during a recent session where a switch failed:

cctrl> switch to db3 

SELECTED SLAVE: db3@alpha 
SET POLICY: MAINTENANCE => MAINTENANCE 
PURGE REMAINING ACTIVE SESSIONS ON CURRENT MASTER 'db1@alpha' 
PURGED A TOTAL OF 0 ACTIVE SESSIONS ON MASTER 'db1@alpha' 
FLUSH TRANSACTIONS ON CURRENT MASTER 'db1@alpha' 
Exception encountered during SWITCH. 
Failed while setting the replicator 'db1' role to 'slave' 
ClusterManagerException: Exception while executing command 'replicatorStatus' on manager 'db1' 
Exception=Failed to execute '/alpha/db1/manager/ClusterManagementHelper/replicatorStatus alpha db3' 
Reason= 
CLUSTER_MEMBER(true) 
STATUS(FAIL) 
+----------------------------------------------------------------------------+ 
|alpha | …

The Question Recently, a customer asked us:

Why would heavy disk IO cause the Tungsten Manager and not MySQL to be starved of resources?

For example, we saw the following in the Manager log file tmsvc.log:

2019/06/03 00:50:30 | Pinging the JVM took 29 seconds to respond.
2019/06/03 00:50:30 | Pinging the JVM took 25 seconds to respond.
2019/06/03 00:50:30 | Pinging the JVM took 21 seconds to respond.
2019/06/03 00:50:30 | Pinging the JVM took 16 seconds to respond.
2019/06/03 00:50:30 | Pinging the JVM took 12 seconds to respond.
2019/06/03 00:50:30 | Pinging the JVM took 8 seconds to respond.

The Answer Why a Java application might be slow or freezing

The answer is that if a filesystem is busy being written to by another process, the background I/O will cause the Java JVM garbage collection (GC) to pause.

This problem is not specific to Continuent Tungsten …

Background The Skinny

Performing schema changes often requires extended downtime for applications. This is due to MySQL needing to rebuild tables for common schema change operations. Tools like pt-online-schema-change have been written to try to overcome the downtime associated with schema changes, however they are complex and put a high load on the database. Amazon’s Aurora improves some schema changes operations, but still requires a table rebuild for common operations like adding a column using before or after, or simply to add a column with a default value. Rebuilding a table with millions of rows can take hours and prevent writes to that table the entire time.

How Can Tungsten Clustering Keep Applications Running? How Does It All Work?

…

We’re pleased to share our webinar “Multi-Region AWS Aurora vs Continuent Tungsten for MySQL & MariaDB”, recorded live on Thursday, April 18th, 2019.

Our colleague Matt Lang walks you through a comparison of building a global, multi-region MySQL / MariaDB / Percona cloud back-end using AWS Aurora versus Continuent Tungsten.

If you’d like to find out how multi-region AWS Aurora deployments can be improved – then this webinar is for you!

We hope you enjoy it!

Recorded:

Thursday, April 18th at 10am PST / 1pm EST / 4pm BST / 5pm CEST

Recording: follow this link to watch

Slides: …

In case you missed the Multimaster webinar recorded live on Thursday, March 28th, 2019:

Learn how NewVoiceMedia built a global, multi-region MySQL cloud back-end to support a high-volume cloud contact center. 

Agenda:

Find out how to deploy Multimaster MySQL / MariaDB / Percona with the following design criteria:

• Geographically distributed, low-latency data
• Fast local response times for read & write traffic
• Full ACID compliance – atomic operations, guaranteed consistency, isolation, and durability
• Local rapid-failover, automated high availability

Speaker:

Chris Parker

Director of Professional Services – EMEA/APAC, is based in the UK, and has over 20 …

For those of you who missed the webinar, “Geo-Scale MySQL in AWS,” recorded live on Thursday, March 14th, 2019:

Learn how to build a global, multi-region MySQL / MariaDB / Percona cloud back-end capable of serving hundreds of millions of online multiplayer game accounts.

Agenda:

Find out how Riot Games serves a globally distributed audience with low-latency, fast response times for read traffic, rapid-failover automated high availability, simple administration, system visibility, and stability.

Speaker:

Eric M. Stone

COO at Continuent, is a veteran of fast-paced, large-scale enterprise environments with 35 years of Information Technology experience. With a focus on HA/DR, from building data centers and trading floors to world-wide deployments, Eric has …

ProxySQL in its versions up to 1.x did not natively support Percona XtraDB Cluster (PXC). Instead, it relied on the flexibility offered by the scheduler. This approach allowed users to implement their own preferred way to manage the ProxySQL behaviour in relation to the Galera events.

From version 2.0 we can use native ProxySQL support for PXC.. The mechanism to activate native support is very similar to the one already in place for group replication.

In brief it is based on the table [runtime_]mysql_galera_hostgroups and the information needed is mostly the same:

• writer_hostgroup: the hostgroup ID that refers to the WRITER
• …

We are growing!

Consequently, Continuent needs additional talented staff.

We are currently looking for a person who would be a good fit for our “Database Clustering Technical Sales & Support Engineer” position, in the US Pacific timezone.

If you know someone who would be a good fit for this role and our company’s culture, please send them our way.

Watch the relay of this webinar and learn how Bluefin Payment Systems provides 24/7/365 operation and application availability for their PayConex payment gateway and Decryptx decryption-as-a-service, essential to point-of-sale (POS) solutions in retail, mobile, call centers and kiosks.

We discuss why Bluefin uses Continuent Clustering, and how Bluefin runs two co-located data centers with multimaster replication between each cluster in each data center, with full failover within the cluster and between clusters, handling 350 million records each month.

Watch this webinar replay at https://youtu.be/crlgsflH7Gw

In this blog post, we talk about how to run applications across multiple clouds (i.e. AWS, Google Cloud, Microsoft Azure) using Continuent Clustering. You want your business-critical applications to withstand node, datacenter, availability-zone or regional failures. For SaaS apps, you also want to bring data close to your application users for faster response times and a better user experience. With cross-cloud capability, Continuent also helps avoid lock-in to any particular cloud provider.

The key to success for the database layer is to be available and respond rapidly.

From both a business and operational perspective, spreading the application across cloud environments from different vendors provides significant protection against vendor-specific outages and vendor lock-in. Running on multiple platforms provides greater …