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.

1C-Bitrix Clustering

Imagine: a flash sale, 10,000 users simultaneously on the site, the server goes down with a 502 error, carts disappear, managers call support. We have seen this dozens of times. The solution is clustering: load balancing between servers, database replication, and automatic failover. Order an audit of your current infrastructure — in 2 days we will determine if and what kind of cluster is needed. Our experience: 40+ high-load projects on Bitrix.

Why is 1C-Bitrix clustering critical for fault tolerance?

80-90% of requests in a typical project are SELECT. Catalog, product pages, filters — all reads. Master-slave replication routes SELECTs to slave servers, leaving the master for writes only. The 'Web Cluster' module (Business edition and higher) routes requests automatically.

Common stumbling blocks: on master binlog_format = ROW. STATEMENT-based replication with NOW() or UUID() causes inconsistencies — leading to a week of debugging. Unique server-id, binary log enabled. On slave — read_only = ON, relay-log. Initialization via xtrabackup (not mysqldump, which locks tables for half an hour on a 20 GB database).

Metric #1 — Seconds_Behind_Master. If a slave lags by 5+ seconds, a customer places an order, returns to their personal account — and the order is missing (SELECT went to a lagging slave). The module allows manual exclusion of critical queries from slave routing.

Failover: Orchestrator or ProxySQL promote a slave to master in 15-30 seconds. The module supports up to 9 slave connections with configurable weights. Integrity check — pt-table-checksum from Percona Toolkit. Savings from inefficient infrastructure can be up to 40% of the budget, representing a significant annual amount for projects with 50,000+ unique visitors. For more information on replication, refer to MySQL Replication Documentation and Wikipedia: Database Replication.

When is clustering necessary?

Not every project needs it. Specific markers:

• 50,000-100,000 unique visitors per day — a single server starts returning 502 errors during peak hours
• Peak spikes of 5-10 times (sales, flash sales) — load grows in minutes, vertical scaling is not enough
• SLA 99.9% (no more than 8.7 hours of downtime per year) — unattainable with a single server
• Geographic distribution of users

Sometimes composite caching, SQL optimization, and vertical scaling are sufficient. We will honestly tell you if a cluster is not yet needed. Investments in clustering typically pay off within 3-6 months under peak loads. The average project budget is determined individually.

What does the cluster architecture consist of?

Load balancer. HAProxy, nginx upstream, or cloud LB. Round-robin for even distribution, ip-hash for session stickiness, least connections for adaptive balancing. Health checks remove dead servers from the pool. SSL termination on the balancer offloads web nodes.

Web servers. Identical nginx + php-fpm, each with a full copy of the code. Sessions in Redis/Memcached, not on disk (otherwise users lose their cart when switching servers). In the cloud — auto-scaling: load increases — servers are added, load decreases — they are removed.

Cache. Redis Cluster with data sharding across nodes. Redis Sentinel for small clusters. Memcached is fast but lacks persistence. Configuration in .settings.php — servers, weights, sharding strategy.

File storage. Uploads, images — accessible from each node. NFS for 2-3 servers, but it is a single point of failure. GlusterFS — distributed file system without single point of failure. S3 (MinIO, AWS, Yandex Object Storage) — offload static files to object storage, the Bitrix module works out of the box.

How to ensure failover at each cluster level?

The cluster is 5 times more reliable than a single server — if any node fails, the service continues to operate.

What are common clustering setup mistakes?

• Sessions on files — when a server goes down, users lose cart and authentication.
• Unmonitored Seconds_Behind_Master — sales suffer and SLA is unmet.
• Single point of failure at the file storage level (NFS without replication).
• Lack of replication monitoring — data inconsistencies go undetected.

We include checks for all these points in our audit and testing.

What is the clustering process?

1. Load audit — load profile, bottlenecks, load testing. We find the ceiling of a single server.
2. Design — components tailored to requirements and budget. Not everyone needs GlusterFS — sometimes NFS and backups suffice.
3. Infrastructure — servers, network, firewalls. Ansible for automation — any node can be recreated in minutes.
4. Migration — transfer with minimal downtime. Components are connected sequentially, each step verified.
5. Testing — simulation of peak conditions. We crash the master, disconnect a web server, kill Redis — see how the system behaves.
6. Documentation — architecture diagram, runbook, disaster recovery plans.

What does clustering work include?

What are the typical timelines?

Contact us to get an engineer consultation and a preliminary project estimate within 2 days. We will calculate the cost based on your specific needs. Order an audit to find out the exact architecture and budget.