1C-Bitrix Cluster Setup: Load Balancing, Replication, Synchronization

You launch an ad campaign, your 1C-Bitrix site gets slammed with 3000+ concurrent visitors, and the server goes down. MySQL hits 100% CPU, cache flushes every two seconds, users see 502 Bad Gateway. Sound familiar? The typical solution is a web cluster of three nodes with load balancing and database replication. Proper setup of such a cluster can handle up to 10,000 visitors, and ownership costs drop by 30-50% thanks to cheap replicas. For example, BitrixVM Enterprise costs $199/month per node, but a 3-node cluster reduces monthly hosting costs from $500 to $250. We've configured 50+ clusters with a proven track record and know where the pitfalls lie.

The "Web Cluster" module in Bitrix is a set of mechanisms that make multiple servers work as one: shared cache, file replication, unified sessions. Without proper configuration of each component, the cluster behaves unpredictably — one node invalidates cache, another serves stale data. Below we break down what the module includes, how to configure read/write split and file sync, and what hidden gotchas await.

What's Included in the Web Cluster Module

The cluster module (BitrixVM Enterprise or separate license) includes:

• Node management — server registration, availability monitoring.
• Load balancing — request routing between nodes.
• Cache synchronization — invalidation across all nodes via shared Memcached, which is 10x faster than file-based caching and reduces page load time by 40%.
• File replication — synchronization of upload/ between servers.
• Database replication — read/write split configuration for MySQL, reducing master load by 60-80%.

Official 1C-Bitrix documentation: "The cluster module allows combining multiple servers into a cluster for fault tolerance and scaling."

How to Activate and Configure Nodes?

The module is installed on each node but managed through one admin panel. Adding a node via API:

\Bitrix\Main\Loader::includeModule('cluster'); $result = \Bitrix\Cluster\Node::add([ 'NAME' => 'web-02', 'HOST' => '10.0.0.12', 'PORT' => 443, 'HTTPS' => 'Y', 'STATUS' => 'ACTIVE', 'SORT' => 100, ]); if ($result->isSuccess()) { echo 'Node added: ' . $result->getId(); } 

Read/Write Split for the Database

The most valuable part of the cluster for highload is directing SELECT queries to replicas and INSERT/UPDATE/DELETE to the master. This reduces master load by 60-80% with a typical read/write ratio of 10:1. With a properly configured split, response times drop by 50%.

In .settings.php:

'connections' => [ 'value' => [ 'default' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-master:3306', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'secret', ], 'slave' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-replica:3306', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'secret_ro', ], ], ], 

The cluster module configuration specifies which queries go to which connection. Transactional queries are forced to the master regardless of operation type.

File Synchronization: Built-in Module vs lsyncd

The built-in module syncs files between nodes via HTTP requests to agents. When a file is uploaded on node-1, the module automatically copies it to node-2 and node-3. To protect the agent, restrict IP access in Nginx: allow 10.0.0.0/24; deny all;.

An alternative is inotify + rsync via lsyncd. It is faster and more reliable for large volumes. Example lsyncd config:

sync { default.rsync, source = "/var/www/bitrix/upload", target = "web-02:/var/www/bitrix/upload", delay = 1, rsync = { compress = false, owner = true, perms = true, } } 

Why Should Sessions Be Stored in Memcached?

File-based sessions don't work in a cluster — requests from the same user can hit different nodes. Switch to Memcached or Redis. Sticky sessions on the load balancer are a temporary fix, not recommended: if a node fails, all its users lose their session. We always set up centralized storage. Memcached sessions are 10x faster than file-based and reduce page load time by 40%.

Example PHP configuration for Memcached:

session.save_handler = memcached session.save_path = "10.0.0.30:11211,10.0.0.31:11211" 

Load Balancer Comparison for 1C-Bitrix Web Cluster

How to Verify Cluster Operation?

Use a shell script to check node status and clear cache:

# Check node status curl http://admin:[email protected]/bitrix/admin/cluster_nodes.php?ajax=Y # Clear cache on all nodes php -r "\Bitrix\Main\Loader::includeModule('cluster'); \Bitrix\Cluster\Cache::clearAll(); echo 'Cache cleared';" 

Step-by-Step Web Cluster Setup Guide

1. Install BitrixVM Enterprise on each node.
2. Configure MySQL replication: master-slave.
3. In the Bitrix admin panel, add nodes via the cluster module.
4. Configure read/write split in .settings.php.
5. Choose file synchronization method: built-in or lsyncd.
6. Move sessions to Memcached or Redis.
7. Configure the load balancer (nginx, haproxy, or cloud LB).
8. Verify functionality via cluster_nodes.php.

Typical Setup Mistakes

The most common is ignoring caching: without a shared Memcached, cache is invalidated separately on each node, leading to data inconsistency. Also frequent are incorrect file sync agent permissions — the agent cannot read a file or write it to another node. Lack of node connectivity monitoring causes traffic to be sent to a failed node. And finally, using sticky sessions without a centralized session store — when a node goes down, all its users lose data.

For a medium project (up to 5000 visitors), 2-3 nodes are sufficient. For high-load (over 10,000), 5+ nodes with DB sharding are required.

Learn more about the concept of clusters on Wikipedia.

Our team has extensive experience in setting up 1C-Bitrix clusters. We guarantee a certified setup with a 99.9% uptime SLA. Contact us for a cluster audit — get an optimization plan tailored to your load. Request a consultation, and we'll help set up a cluster that withstands any peak.