1C-Bitrix Sharding: Master-Slave, Module Separation & Cache Tuning

Optimizing 1C-Bitrix Performance with Database Sharding

Partitioning splits a table within one server. Sharding distributes data across multiple database servers. When a single MySQL server cannot handle the load (100% CPU, disk I/O bottleneck), horizontal scaling via sharding is an option. For Bitrix, this is a non-trivial task because the core is designed to work with one database. According to the Bitrix Cluster Module Documentation, the built-in cluster module supports master-slave and module-level separation but not full sharding. Our team, with 7+ years of Bitrix experience, has completed over 100 high-load projects. We have 30+ certified specialists and a 98% client satisfaction rate.

When Is Sharding Needed?

If after configuring caching (Redis, tagged cache), enabling composite mode, and setting up master-slave replication the database still hits CPU limits, it's time to consider sharding. On one project with a catalog of 2 million products, complex queries took 30 seconds without sharding. After offloading the statistics and search modules to separate servers, the time dropped to 300 ms — a 99% improvement for those queries. In another case, we reduced database CPU usage from 95% to 40% within a week.

Built-in Mechanism: the cluster Module

Bitrix provides the cluster module (available in Business and Enterprise editions). It supports:

• Master-slave replication — writes to master, reads from one or more slaves. Not pure sharding, but relieves read load.
• Moving modules to a separate database — a specific module (e.g., search or statistic) can use its own database on another server.

Configuring master-slave via cluster:

1. Set up MySQL/MariaDB replication using standard methods (GTID or positional).
2. In the Bitrix admin panel: Settings → Web Cluster → Databases → Add.
3. Provide the slave server parameters: host, port, login, password.
4. Bitrix automatically routes SELECT queries to the slave, and INSERT/UPDATE/DELETE to the master.

The module monitors replication lag (Seconds_Behind_Master) and switches reads back to the master if the threshold is exceeded.

Module-Level Sharding

The cluster module allows moving tables of a specific module to a separate database server. In practice:

• statistic module — tables b_stat_* generate 80% of INSERT load on a typical site. Moving them offloads the main database.
• search module — tables b_search_* are heavy for full-text search. An alternative is to offload search to Elasticsearch.
• forum / blog module — if the forum or blog is active, their tables can be isolated.

Configuration: Web Cluster → Databases → [server] → Modules — select the module to move. Bitrix redirects queries to that module's tables to the specified server.

Horizontal Data Sharding

Full sharding — splitting one table by a key (e.g., products with IDs 1–100000 on server A, 100001–200000 on server B) — is not supported out of the box by Bitrix. The D7 ORM and the legacy API work with a single database connection.

Implementation is possible but requires:

• A proxy layer — Vitess or ProxySQL routes queries according to sharding rules transparently to the application.
• A custom DB class — inheriting from Bitrix\Main\DB\MysqliConnection with routing logic.
• Limitations: JOINs across shards are impossible, aggregate queries must be collected in the application.

In practice, full horizontal sharding for Bitrix is rarely used. More common is a combination: master-slave + offloading heavy modules + caching.

Impact of Sharding on Architecture

Sharding requires changing query logic: JOINs only within a shard, aggregates via UNION, transaction support only at the shard level. If sharding is implemented via a proxy layer, the application does not change, but the proxy handles routing and can become a bottleneck. Our experience: Vitess is better than ProxySQL for Bitrix because it supports automatic shard rebalancing.

Process of Setup

1. Audit the current database architecture, measure load, analyze slow query logs.
2. Choose a topology: master-slave, module offloading, or sharding.
3. Configure replication and monitoring (lag < 1 sec).
4. Move modules to separate servers, conduct load testing.
5. If full sharding is needed, install a proxy, migrate data.
6. Optimize caching: Redis, tagged cache, composite mode.

Timelines — from 2 weeks for master-slave to 2 months for full sharding. Typical cost ranges from $5,000 to $20,000 depending on complexity. Clients typically save 30-50% compared to upgrading all hardware.

What's Included in the Work

We provide:

• Architecture diagram with data location.
• Configuration files for MySQL/MariaDB, ProxySQL/Vitess.
• Scripts for monitoring lag and integrity.
• Documentation for disaster recovery procedures.
• Training for administrators and developers.
• Guarantee of stable operation — 30 days of 24/7 support after launch.

Contact us for an assessment of your project. Our team: 7+ years of Bitrix experience, 100+ high-load projects, 30+ certified specialists, 98% client satisfaction rate. Get a consultation on sharding — reach out, and we'll estimate the scope of work.