Percona Cluster

Percona/Galera clusters rely on quorum to maintain data consistency and high availability. For a cluster to function correctly and tolerate node failures, a minimum of three nodes is recommended. Losing quorum, meaning a majority of nodes cannot see each other or agree on the cluster state, prevents the cluster from processing writes and can leave nodes in an 'Initialized' or non-primary state. This article provides a step-by-step guide to safely restoring your cluster to an operational state a...

When deploying a Percona Cluster with three nodes, importing hundreds of databases, each containing approximately 110 tables in our case, resulted in thousands of tables being managed by MySQL. In such environments, you may encounter issues related to the open files limit, which can impact the ability to restart cluster nodes and synchronize with xtrabackup (we were given Broken pipe error in our case). Understanding the Problem MySQL requires a file descriptor for each open table, database, a...

Memory allocation efficiency is critical to maximizing the performance of MySQL databases, especially in high-traffic, write-intensive environments like Percona XtraDB Cluster. The default system memory allocator (such as glibc’s malloc) can lead to significant memory fragmentation and inefficiencies under heavy workloads, ultimately limiting database throughput. Deploying an alternative memory allocator—such as jemalloc—can provide substantial improvements in resource management and overall clu...

During the administration and performance tuning of a Percona Cluster, it’s common to configure different parameters on individual nodes. To ensure consistency and maintain synchronization across all nodes, you can use the following command to compare configuration settings: pt-config-diff h=<node1> h=<node2> h=<node3> -u <user> -p <password> This command helps identify configuration differences between nodes, making it easier to keep your cluster settings aligned...

In our environment, we operate a Percona Cluster consisting of three nodes, load-balanced using HAProxy. When restarting a node, it is essential to first make the node inaccessible to application servers. Once all active connections and traffic have ceased, the Percona server can be safely restarted. Since HAProxy monitors node availability through the xinetd service, the simplest way to mark a node as unavailable is to stop the xinetd service before restarting MySQL. After the restart is comp...