Showing entries 1 to 10 of 17
7 Older Entries »
Displaying posts with tag: Mastering Tungsten Clustering (reset)
How can I tell which Tungsten Connector mode I am using: Bridge, Proxy/Direct or Proxy/SmartScale?

Overview The Skinny

Part of the power of Tungsten Clustering for MySQL / MariaDB is its intelligent MySQL Proxy, known as the Tungsten Connector. Tungsten Connector has three main modes, and depending on the type of operations you are performing (such as if you need read-write splitting), we help you choose which mode is best.

The Question Recently, a customer asked us:

How can I tell which Tungsten Connector mode I am using: Bridge, Proxy/Direct or Proxy/SmartScale?

The Answer Connect and Observe

You may login through the Connector to tell the difference between Bridge mode and Proxy mode (either Direct or SmartScale):

In Proxy mode, you will see the -tungsten tag appended to the Server version string:

[Read more]
Slick Command-Line Tricks for a Tungsten MySQL / MariaDB Database Cluster

Overview The Skinny

Tungsten Clustering provides high availability, disaster recovery, and a host of other benefits for MySQL / MariaDB / Percona Server databases. In this blog post we will explore some of the shell aliases I use every day to administer various Tungsten Clusters.

Shell Aliases: A Quick Review Quick and Easy

A shell alias is simply a way to create a shortcut for frequently-used command sequences.

For example, I like to shorten the command clear to cls, i.e.

shell> alias cls=clear
shell> cls

If you create an alias on the fly it will be lost when the shell exits.

To save aliases so they are available to all shell sessions, update your shell’s profile or rc script.

For example, add the below line to the bottom of …

[Read more]
Where are the logs for a Tungsten Cluster?

The Question Recently, a customer asked us:

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?

The Answer: Part I Both basic and advanced logs are available!

The basic logs are symbolic links into the log subdirectory for each layer of the cluster.

For example, this is the listing of the default log directory, /opt/continuent/service_logs:

connector-user.log -> /opt/continuent/tungsten/tungsten-connector/log/connector-user.log
manager-user.log -> /opt/continuent/tungsten/tungsten-manager/log/manager-user.log
mysqldump.log -> /opt/continuent/tungsten/tungsten-replicator/log/mysqldump.log
replicator-user.log -> /opt/continuent/tungsten/tungsten-replicator/log/replicator-user.log
xtrabackup.log -> /opt/continuent/tungsten/tungsten-replicator/log/xtrabackup.log

As you can see, each log file is a …

[Read more]
The Fast Way to Import CSV Data Into a Tungsten Cluster

The Question Recently, a customer asked us:

After importing a new section of user data into our Tungsten cluster, we are seeing perpetually rising replication lag. We are sitting at 8.5hrs estimated convergence time after importing around 50 million rows and this lag is climbing continuously. We are currently migrating some of our users from a NoSQL database into our Tungsten cluster. We have a procedure to write out a bunch of CSV files after translating our old data into columns and then we recursively send them to the write master using the mysql client. Specifically our import SQL is doing LOAD DATA LOCAL INFILE and the reading in a large CSV file to do the import. We have 20k records per CSV file and we have 12 workers which insert them in parallel.

Simple Overview The Skinny

In cases like this, the slaves are having trouble with the database unable to keep up with the apply stage …

[Read more]
What is the Best Way to Check the Health of a Tungsten Cluster Before a Switch?

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 | …
[Read more]
What on Earth is a Split-Brain Scenario in a MySQL Database Cluster?

Overview The Skinny

In this blog post we will define what a split-brain scenario means in a MySQL database cluster, and then explore how a Tungsten MySQL database cluster reacts to a split-brain situation.

Agenda What’s Here?

  • Define the term “split-brain”
  • Briefly explore how the Tungsten Manager works to monitor the cluster health and prevent data corruption in the event of a network partition
  • Also explore how the Tungsten Connector works to route writes
  • Describe how a Tungsten MySQL database cluster reacts to a split-brain situation
  • Illustrate various testing and recovery procedures

Split-Brain: Definition and Impact Sounds scary, and it is!

A split-brain occurs when a MySQL database cluster which normally has …

[Read more]
Configuring the Tungsten Connector for PCI Compliance

The Question Recently, a customer asked us:

We were wondering if the Connectors would be able to bind to localhost/127.0.0.1 instead of 0.0.0.0:3306? Since the Connector is installed on the application servers, all of the connections are coming from localhost. We would like to limit this exposure so that the 3306 port is not exposed externally. We ask because we are failing PCI checks that are able to access the database port externally.

The Answer YES!

You may set the IP address for the Connector to listen on by using the tpm command option: property=server.listen.address={IP_ADDRESS}

To force the Connector to listen on the localhost only use the following example:

shell> tools/tpm configure alpha --property=server.listen.address=127.0.0.1
shell> tools/tpm update --replace-release

Use the IP …

[Read more]
Why is My Java Application Freezing Under Heavy I/O Load?

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 …

[Read more]
Using Keep-Alives To Ensure Long-Running MySQL & MariaDB Sessions Stay Connected

Overview The Skinny

In this blog post we will discuss how to use the Tungsten Connector keep-alive feature to ensure long-running MySQL & MariaDB/Percona Server client sessions stay connected in a Tungsten Cluster.

Agenda What’s Here?

  • Briefly explore how the Tungsten Connector works
  • Describe the Connector keep-alives – what are they and why do we use them?
  • Discuss why the keep-alive feature is not available in Bridge mode and why
  • Examine how to tune the keep-alive feature in the Tungsten Connector

Tungsten Connector: A Primer A Very Brief Summary

The Tungsten Connector is an intelligent MySQL database proxy located between the clients and the database servers, providing a single connection point, while routing queries to …

[Read more]
Transparent Proxy Maintenance for MySQL, MariaDB & Percona Server

Overview The Skinny

When it comes to zero downtime, proxies are the first line components of a cluster.

In order to achieve High Availability (HA) for MySQL, MariaDB and Percona Server, a commonly deployed setup consists of configuring load balancers (hardware or software) on top of those proxies.

A Strong Architecture How is Maintenance Made Possible?

With this proxy + load balancer architecture, server maintenance is made possible on any of the proxy hosts, as follows:

  • the proxy is stopped
  • the load balancer detects the dead proxy and removes it from the pool
  • new connection requests go to live proxies

The Problem What Happens to Existing Sessions?

But wait… even though new connections are re-routed correctly, what happens …

[Read more]
Showing entries 1 to 10 of 17
7 Older Entries »