In this blog, we cover tprovision. tprovision is a complete rewrite of the provisioning tool “tungsten_provision_slave,” included with Tungsten Cluster. It is streamlined and allows easy provisioning of replica databases.
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.
Thinking transparent reconnects of applications is the grail of HA? It is! But Active/Active setups make them risky.
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.
When an application is a primary source of revenue for an organization, keeping Production operations going is critical. This blog discusses three things that can help prevent issues in Production. In fact, that’s why multiple environments exist - to make sure that the final act, delivered in Production, runs smoothly; read on to find out how to make sure your labor is not in vain!
This is the third post in a short series about Tungsten Clustering topologies. In this post we will highlight the key differences between Composite Active/Passive, Composite Active/Active (CAA), and the newly available Dynamic Active/Active topology. In short, DAA blends the simplicity of CAP with the automated continuous operations of CAA.
You’ve seen the recent news about AWS outages; enterprises have to think about where their physical AWS data centers are and treat them as a single point of failure. As such, enterprises running business-critical and mission-critical applications are accounting for geography of public cloud resources in their business-continuity plans. Learn about a solution for continuous operations for your MySQL database that’s a step above traditional MySQL Disaster Recovery (DR).
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?
Galera Cluster provides high availability and scalability for MySQL. While this provides high availability in a local region or site, it does not provide any provisions for disaster recovery (DR) or any multi-site deployment in general, so let’s explore how we could extend the functionality of Galera Cluster to deploy at geo-scale.
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.
