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:
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:
Application performance and MySQL database responsiveness is always high priority for highly-available, business-critical use cases. That’s why Tungsten Clustering offers features and options to tune for maximum performance, such as Parallel Apply. When does Parallel Apply work best? What are the limitations? To find out, read this blog from MySQL industry vet, Eric M. Stone, the COO of Continuent!
This blog discusses Asynchronous versus Synchronous MySQL replication for MySQL clustering. Synchronous replication is viewed as the ‘holy grail’ of clustering. But unfortunately, when something is too good to be true, it often is. Before the Tungsten cluster solution Continuent built two synchronous replication cluster solutions (m/cluster, uni/cluster), but we abandoned those for good reasons.
In this MySQL Case Study blog we look at a customer of ours who were able to grow their SaaS business from tens of customers to thousands of enterprise customers once they achieved continuous MySQL operations with Continuent Tungsten.