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 — 172.16.10.1
Bitrix2 — 172.16.10.2
Be sure to write the following lines in the host's files on both machines:
172.16.10.1 bitrix1
172.16.10.2 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.
binlog_format=row
Error logs:
log=/var/log/mysqld.log
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
replicate-ignore-db=test
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
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:
log-slave-updates
After that restart mysql:
[root@bitrix1 /]# /etc/init.d/mysqld restart
