Tungsten Clustering contains many tools to monitor your cluster, and today we will look at a new one - the `tungsten_get_status` command, included with Tungsten versions 6.1.19+ and 7.0.2+. This tool was created in response to a customer request for a simple script that could display the status of all nodes cluster-wide for any topology from a single place. The status includes the datasource and replicator layers along with the policy for each cluster.
Tungsten Replicator is a powerful tool with many great features, and today we will look at a new one - the ability to Pause and Resume a replication service. Until now, the only way to stop a replication stream was to take the service offline, and put it back online when it is needed again. The online process involves a number of internal steps and overhead, and if there are many THL files on disk, it could take some time to index them all before the service can come fully online. To remove the overhead of the startup time, the new pause/resume feature was developed for the Replicator, and is accessed via the `trepctl` command.
Tungsten Clustering is a powerful tool with many moving parts, including the Tungsten Connectors which may be installed on any application server. During a troubleshooting event, it is helpful to understand what to look for and where, in addition to understanding how the logs work together to provide a clear picture of the situation. In Tungsten version 7, we introduced a number of features designed to make troubleshooting easier, and this blog will cover some of that too.
This blog post will walk you through configuring HA Proxy for the Tungsten Dashboard, along with the new command `tpm generate-haproxy-for-api` which helps automate the process by translating existing INI files into haproxy.cfg config file format. The Tungsten Dashboard is a browser-based GUI, designed to make using a Tungsten Cluster as easy as possible.
Transaction History Log (THL) files are the core of Tungsten Replication, containing the actual MySQL write events that are replicated to the replicas. These files can take up considerable amounts of disk space, making them of interest for housekeeping operations to limit the consumption and ultimately, the cost. This blog post will walk you through THL management, along with the new command `tpm purge-thl` which helps automate the process when THL needs to be removed prior to the automatic rotation window.
Performance tuning any system provides more speed for the same hardware spend, gives the end-user a better, faster experience and typically reduces the stress on staff all around. Security tuning locks down critical data to prevent unauthorized access. Today we will explore both the security and performance enhancements available for the Tungsten Replicator THL sub-system as of version 7.x.
Sometimes you really, really want to know what a MySQL client is asking of the MySQL server. As of Tungsten Clustering v7.0.0, you may now enable Connector Audit Logging, which captures data transferred between client applications and MySQL servers to a file, database or socket. This blog post will walk you through the feature and how to enable, configure and disable Tungsten Connector Audit Logging.
In this post we will explore a new command in v7.0.1, tpm report. The purpose of tpm report is to provide easy access to all of the settings that pertain to a specific topic. Since Security is a high priority at Continuent, the current default (and only) topic is the Security stance. The tpm report command will evolve and grow over time. This first version is Continuent’s way of providing as much transparency about Tungsten Cluster Security as possible.
In our last blog post on this topic we covered the basics of the new REST API available with Tungsten version 7.0.0. In this post, Part 2, we explore the REST API in more detail, including payloads and advanced functionality. The API provides a vast pool of capabilities, and here we barely scratch the surface of what can be accomplished.
In this short post we will highlight the key differences between Multi-Site Active/Active (MSAA) and Composite Active/Active (CAA) topologies. The core principle behind an active/active topology is that you have more than one writable cluster. So why do we have more than one type of Active/Active topology?