Why five servers could not handle the load: how we redesigned the database architecture
How we resolved Galera Cluster overload with eight Proxmox VMs, MySQL replication and ProxySQL query caching, without buying more servers.
Technologies: Galera Cluster, MySQL, Proxmox VE, ProxySQL, Cloudflare
The problem: heavy load on Galera Cluster
The project ran Galera Cluster across five physical servers. When bots actively collected published information, the number of database requests rose sharply. During these periods the database could no longer keep up, causing service failures.
Resources were already spread across several servers, yet the request-processing architecture could not sustain the project’s traffic pattern. We needed to understand which work was being repeated and where it could be reduced.
Why not simply block the bots?
Restricting traffic through Cloudflare looked like a quick way to relieve the database. In practice, those restrictions also affected real visitors: some users had trouble reaching the website.
The requirement was to keep the service accessible while continuing to handle this traffic. We therefore focused on the infrastructure itself: request routing, replication and caching query results.
The analysis: why adding servers did not solve the problem
The analysis showed that adding servers did not remove the cause of the overload. Automated systems repeatedly requested the same information, making the database perform similar read operations again and again.
We chose to reorganize the existing hardware. Some data and client reads could be served separately, while repeated SELECT results could be returned from cache. That became the basis of the new design.
The solution: virtualization, replication and caching
Two of the five physical servers were removed from the original cluster and repurposed for virtualized infrastructure. The remaining three stayed in the main cluster. The solution required no additional physical servers.
Architecture illustration based on the case. This is not a performance benchmark.
1. Deploying virtual infrastructure on Proxmox VE
We installed Proxmox VE on the two repurposed hosts and created four virtual machines on each. The first host held four independent databases containing the information most frequently requested by automated systems. The second held their replicas.
This produced eight VMs and four database/replica pairs, with each pair spread across two physical hosts. The instances exchanged data over the local network.
2. Separating writes from reads
The application wrote changes to the databases on the first host. Replication carried those changes to the corresponding instances on the second, while client requests received read-only access.
This separated data changes from the stream of requests used to collect information. Dedicated database instances served the intensive reads, distributing the work between them.
3. Caching SELECT queries with ProxySQL
We configured ProxySQL in front of the databases to cache SELECT query results. When a suitable repeated query had a cached result, ProxySQL could return it without another request to the database server. For bots requesting the same information many times, that changed the processing path.
A portion of repeated reads consequently stopped reaching the databases. Automated requests continued to be served, without needing Cloudflare restrictions that affected real visitors.
The result: stable operation without additional hardware
After the architecture changed, the previous overload no longer caused database failures. Repeated requests were served through the cache, writes and reads had separate handling, and users retained access without additional Cloudflare restrictions.
The solution used the original hardware: three servers in the main cluster and two Proxmox hosts running eight VMs. The improvement came from redistributing load and reducing repeated work.
- 8 virtual machines on 2 existing hosts
- 4 database / replica pairs
- Repeated SELECT queries served from cache
Architecture illustration based on the case. This is not a performance benchmark.
The takeaway: architecture matters more than server count
Five servers were sufficient once the data-processing architecture was revised. Virtualization provided separate database instances, replication separated their roles, and ProxySQL reduced repeated requests reaching them. Together, these changes addressed the bottleneck in the previous configuration.
For similar symptoms, it is useful to begin with query patterns and access paths. That makes it possible to judge whether more resources are needed or the existing hardware can be used more effectively.
Having server or database performance problems?
If a database keeps overloading while additional resources bring diminishing returns, we can review its queries and infrastructure. We will look for repeated work and assess whether reads, writes and caching should be separated. The proposed changes will follow the project’s actual workload.