Clustering on the example of BitrixVM: simple and clear

Ensuring fault tolerance is the key to the continuous operation and, in general, complete satisfaction of both users and administrators. In our today's material, we will talk about how you can cluster BitrixVM using simple and affordable tools so that everyone is happy and nothing prevents you from working calmly.

So, we have two servers with BitrixVM and Bitrix24 systems deployed on them. The first thing to do is to maintain the same type of data on both nodes and perform synchronization both between databases and between bitrix files.

Bitrix1 —
Bitrix2 —

Be sure to write the following lines in the host's files on both machines: bitrix1 bitrix2

For the database, we will use master-master data replication. To do this, we need to correct the settings in the /etc/my.cnf files

Bitrix recommends creating the /etc/mysql/conf.d/z_bx_custom.cnf file to override your own settings, in which you should edit:

[root@bitrix1 /]# cat /etc/my.cnf
# Basic mysql configuration. Use bvat for advanced settings.
# Parameters set by bvat are stored in /etc/mysql/conf.d/bvat.cnf
# If you want to change any parameter, you'll have to redefine it in #/etc/mysql/conf.d/z_bx_custom.cnf

Let's create a file in accordance with the recommendation:

touch /etc/mysql/conf.d/z_bx_custom.cnf

[root@bitrix1 /]# nano /etc/mysql/conf.d/z_bx_custom.cnf [mysqld]

Unique server identifier among replication participants:

server-id = 1

Changed binary data is written to the logs. Without specifying this option, an error may occur both in the logs and when entering the bitrix portal itself:

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is #READ #COMMITTED or READ UNCOMMITTED.

Error logs:

log_error = /var/log/mysqld.log

Path to the server transaction logs (binlog maintained by the master):

log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index

Path to slave relay logs (binlog downloaded from the master):

relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index

Databases that need or do not need to be replicated (we only perform replication for the standard bitrix database - sitemanager0):

replicate-do-db = sitemanager0

Don't binlog the database:

binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema

To avoid auto-increment conflicts, we tell the server to generate ids starting from the 3rd one, adding 10 each, i.e. 13, 23, 33, 43 onwards:

auto_increment_increment = 10
auto_increment_offset = 3

Save logs from the master to your binlog to send to the slave:


After that restart mysql:

[root@bitrix1 /]# /etc/init.d/mysqld restart

Next, you need to switch to the second BitrixVM, i.e. bitrix2, and perform similar settings for mysql, after also creating the z_bx_custom.cnf file in /etc/mysql/conf.d/, while changing the server-id and auto_increment_offset:

[root@bitrix2 ~]# cat /etc/mysql/conf.d/z_bx_custom.cnf [mysqld]
server-id = 2

log_error = /var/log/mysqld.log

log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index

relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index

replicate-do-db = sitemanager0

binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
auto_increment_increment = 10
auto_increment_offset = 4


Let's restart mysql on the second machine:

[root@bitrix2 ~]# /etc/init.d/mysqld restart

For replication, create a replicator user on both machines:

root@bitrix1 /]# mysql -u root -p
Enter password:
mysql> create user 'replicator'@'%' identified by 'aGiV4uac';
mysql> grant replication slave on *.* to 'replicator'@'%';

root@bitrix2 /]# mysql -u root -p
Enter password:
mysql> create user 'replicator'@'%' identified by 'aGiV4uac';
mysql> grant replication slave on *.* to 'replicator'@'%';

Again we pass to the first machine and we start replication. To do this, you need to know the master_log name and master_log_position of the second bitrix2 machine:

[root@bitrix2 /]# mysql -u root -p -e 'show master status;'

| File |Position|Binlog_Do_DB| Binlog_Ignore_DB |
|server-mysql-bin.000029| 819 | |information_schema,mysql,performance_schema|

From the resulting list it follows that MASTER_LOG_FILE = server-mysql-bin.000029 and MASTER_LOG_POS = 819

We use this data to set up replication on the first machine:

[root@bitrix1 /]# root -p -e "CHANGE MASTER TO MASTER_HOST = '', MASTER_USER = 'replicator', MASTER_PASSWORD = 'aGiV4uac', MASTER_LOG_FILE = 'server-mysql-bin.000029', MASTER_LOG_POS = 819;"

We start the slave:

[root@bitrix1 /]# mysql -u root -p -e 'start slave;'
Dedicated Server

Dedicated server

Check out SIM-Networks’ powerful pre-made server configurations

See packages

Checking the status:

[root@bitrix1 /]# mysql -u root -p -e 'show slave status \G;'
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: server-mysql-bin.000029
Read_Master_Log_Pos: 819
Relay_Log_File: slave-mysql-relay-bin.000002
Relay_Log_Pos: 72951
Relay_Master_Log_File: server-mysql-bin.000029
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: sitemanager0
Replicate_Ignore_DB: test,information_schema,mysql,performance_schema
Last_Errno: 0
Skip_Counter: 0
Exec_Master_Log_Pos: 819
Relay_Log_Space: 73113
Until_Condition: None
Until_Log_Pos: 0
Master_SSL_Allowed: No
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_SQL_Errno: 0
Master_Server_Id: 2

The Seconds_Behind_Master parameter (the time the replica lags behind the master) must be zero: Slave_IO_State should say «Waiting for master to send even» Slave_IO_Running = Yes Slave_SQL_Running = Yes

If there is no value in the line Slave_IO_State and Seconds_Behind_Master is NULL, then replication has not started.

Find out the master_log and master_log_position of the first bitrix1 machine:

[root@bitrix1 /]# mysql -u root -p -e 'show master status;'

| File |Position|Binlog_Do_DB| Binlog_Ignore_DB |
|server-mysql-bin.000026| 2930 | |information_schema,mysql,performance_schema|

Set up replication on the second bitrix2 machine:

[root@bitrix2 ~]# mysql -u root -p -e "CHANGE MASTER TO MASTER_HOST = '', MASTER_USER = 'replicator', MASTER_PASSWORD = 'aGiV4uac', MASTER_LOG_FILE = 'server-mysql-bin.000026', MASTER_LOG_POS = 2930;"

[root@bitrix2 ~]# mysql -u root -p -e 'stop slave;'
[root@bitrix2 ~]# mysql -u root -p -e 'show slave status \G;'

The following parameters should be displayed: Seconds_Behind_Master, Slave_IO_State, Slave_IO_Running, and Slave_SQL_Running with the same parameters as in the case of setting up replication on the bitrix1 machine.

Next, you need to move on to synchronizing the data itself between Bitrix24. We will synchronize files using csync2.

The csync installation must be done on both machines:

[root@bitrix1 /]# yum install csync2
[root@bitrix2 /]# yum install csync2

Enable on both machines:

chkconfig xinetd on
chkconfig csync2 on

We generate certificates while being on the first bitrix1 machine:

[root@bitrix1 /]# openssl genrsa -out /etc/csync2/csync2_ssl_key.pem 1024
[root@bitrix1 /]# openssl req -new -key /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.csr
[root@bitrix1 /]# openssl x509 -req -days 600 -in /etc/csync2/csync2_ssl_cert.csr -signkey /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.pem

Generate csync2 key:

csync2 -k /etc/csync2/csync2.cluster.key

After a rather long generation process, the csync2.cluster.key will appear in the /etc/csync2/ folder

The csync config looks like this:

[root@bitrix1 /]# cat /etc/csync2/csync2.cfg
group cluster
host bitrix1 bitrix2;

key /etc/csync2/csync2.cluster.key;

include /home/bitrix/www;

We exclude the database connection settings files, since we use different passwords on both machines. We also exclude cache directories:

exclude /home/bitrix/www/bitrix/php_interface/dbconn.php;
exclude /home/bitrix/www/bitrix/.settings.php;
exclude /home/bitrix/www/bitrix/cache;
exclude /home/bitrix/www/bitrix/managed_cache;

Set the file selection parameter: the newest one remains:

auto younger;

Copy the generated keys along with the csync2.cfg configuration file from bitrix1 to bitrix2, for example, via scp:

scp /etc/csync2/csync2* root@

Let's build a local database of all project files that csync2 will work with.

[root@bitrix1 csync2]# csync2 -cr /

After - run:

[root@bitrix1 /]# /usr/sbin/csync2 –xv

In case of errors, you can use /usr/sbin/csync2 –Tv

If the command completed without errors, then you can add an entry to /etc/crontab on both machines to run csync every minute:

*/1 * * * * root /usr/sbin/csync2 -x >/dev/null 2>&1

It remains to check: by creating, for example, a message in the portal itself, in the bitrix24 chat, delete it, create a file and make sure that the changes made are transferred between the nodes.

As one of the options for a single point of entry, you can use HAProxy, located on an additional server. An overview of the installation and configuration of HAProxy will not be considered in this article, because. There are enough manuals on this issue, but for an example, let's give the config file /etc/haproxy/haproxy.cfg:

[root@haproxy haproxy]# cat haproxy.cfg global
log local2 notice

chroot /var/lib/haproxy
pidfile /var/run/
maxconn 4000
user haproxy
group haproxy
nbproc 1 # Number of processing cores.
ulimit-n 65536
# turn on stats unix socket
stats socket /var/lib/haproxy/stats

mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except
option redispatch
retries 3
timeout http-request 5000
timeout queue 5000
timeout connect 5000
timeout client 5000
timeout server 5000
timeout http-keep-alive 30
timeout check 20 #
maxconn 3000

frontend bitrix.local
mode http
bind :80
default_backend bitrix

backend bitrix
mode http
balance roundrobin
option httpchk
option httpclose
server bitrix1 check
server bitrix2 check

Cluster your servers for health and may the Force be with you!

Was this article helpful?



Did you like the article?

Cookie consent

By clicking «I agree», you consent to our website's use of cookies to give you the most relevant experience by remembering your preferences and repeat visits. However, you may visit «Manage сookies» to provide controlled consent. Learn more

Cookies settings


Necessary cookies are crucial for the basic functions of the website and the website will not work in its intended way without them.


Analytical cookies are used to understand how visitors interact with the website.


Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns.