Codership Best Practices Articles

Whereas the Troubleshooting section relates to handling problems with a cluster, this section of the KB provide information and guidance on improving the performance of a cluster and optimizing configuration of the nodes.

Group Commit

Length: 322 words; Published: ; Topic: Performance

If there are several transactions trying to commit at the same time, group commit will force them to be flushed to the disk with a single system call, rather than one system call for each commit. This can greatly reduce the need for flush operations, and greatly improve the throughput of TPS.

Large Transactions

Length: 443 words; Published: ; Topic: Performance

Large transactions, especially ones which delete millions of rows from a table at once, can lead to diminished performance. One reason is that the table may reindexed and rescanned after each row is deleted.

Parallel Slave Threads

Length: 366 words; Published: ; Topic: Performance

There is no rule about how many slave threads you need for replication. Parallel threads do not guarantee better performance, but they don’t impair regular operation performance and they may in fact speed up the synchronization of new nodes joining a cluster.

Slow Nodes

Length: 297 words; Published: ; Topic: Performance

By design, the performance of a cluster cannot be higher than the performance of the slowest node in the cluster. Even if you have only one node, its performance can be considerably slower when compared with running the same server in a standalone mode (i.e., without a wsrep Provider).

WAN Latency

Length: 221 words; Published: ; Topic: Performance

When using Galera Cluster over a WAN (Wide Area Network), remember that WAN links can have exceptionally high latency. You can check this by taking Round-Trip Time (RTT) measurements between cluster nodes. If there is a latency, you can correct for this by adjusting all of the temporal parameters.

WAN Replication

Length: 161 words; Published: ; Topic: Performance

When running the cluster over a WAN (Wide Area Network), you may frequently experience transient network connectivity failures. To prevent this from partitioning the cluster, you may want to increase the keepalive timeouts.

Write-Set Cache Size

Length: 467 words; Published: ; Topic: Performance

You can define the size of the write-set cache using the gcache.size parameter. Set the size to one less than that of the data directory.

Write-Set Caching during State Transfers

Length: 156 words; Published: ; Topic: Performance

Under normal operations, nodes do not consume much more memory than the regular stand-alone database server. The certification index and uncommitted write-sets do cause some additional usage, but in typical applications this is not usually noticeable. Write-set caching during state transfers is the exception.

Multi-Master Setup

Length: 55 words; Published: ; Topic: Topology

A master is a node that can simultaneously process writes from clients. The more masters in a cluster, the higher the probability of certification conflicts. This can lead to undesirable rollbacks and performance degradation.

Single Master Setup

Length: 81 words; Published: ; Topic: Topology

If a cluster uses only one node as a master, there are certain requirements (e.g., the slave queue size) that can be relaxed.

Two-Node Clusters

Length: 399 words; Published: ; Topic: Topology

Although it may seem simple to maintain a cluster of only two nodes, there is an inherent potential problem. In a two-node cluster, when one node fails, it will cause the other to stop.

SELinux with Galera Cluster

Length: 180 words; Published: ; Topic: Security

When you first enable Galera Cluster on a node that runs SELinux, it will prohibit all cluster activities. In order to enable replication on the node, you need a policy so that SELinux can recognize cluster activities as legitimate.

Synchronization Functions

Length: 391 words; Published: ; Topic:

Occasionally, an application may need to perform a critical read–queries that require that the local database reaches the most up-to-date state possible before they’re executed. You can use synchronization functions to tie the synchronization process to specific transactions so that the node waits only until a specific transaction is applied before executing the query.