Die Sicherstellung der Ausfallsicherheit ist der Schlüssel für einen kontinuierlichen Betrieb und generell für die Zufriedenheit von Benutzern und Administratoren. In diesem Artikel zeigen wir Ihnen, wie Sie BitrixVM mit einfachen und kostengünstigen Mitteln clustern können, damit alle Beteiligten zufrieden sind und einem ruhigen Arbeiten nichts im Wege steht.
Wir verfügen in diesem Fall über zwei Server, auf denen die Systeme BitrixVM und Bitrix24 installiert sind. Das erste, was zu tun ist, ist die Aufrechterhaltung der gleichen Art von Daten auf beiden Knoten. Führen Sie die Synchronisation sowohl zwischen den Datenbanken als auch zwischen den Bitrix-Dateien durch. ить синхронизацию как между базами данных, так и между файлами bitrix.
Bitrix1 — 172.16.10.1
Bitrix2 — 172.16.10.2
Stellen Sie sicher, dass Sie die folgenden Zeilen in die Dateien des Hosts auf beiden Maschinen schreiben:
172.16.10.1 bitrix1
172.16.10.2 bitrix2
Für die Datenbank werden wir die Master-Master-Datenreplikation verwenden. Dazu müssen wir die Einstellungen in den /etc/my.cnf-Dateien korrigieren
Bitrix empfiehlt, die Datei /etc/mysql/conf.d/z_bx_custom.cnf zu erstellen, um Ihre eigenen Einstellungen zu überschreiben, die Sie bearbeiten sollten:
[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
#
Lassen Sie uns eine Datei gemäß der Empfehlung erstellen:
touch /etc/mysql/conf.d/z_bx_custom.cnf
[root@bitrix1 /]# nano /etc/mysql/conf.d/z_bx_custom.cnf [mysqld]
Eindeutiger Server-Identifikator unter den Replikationsteilnehmern:
server-id = 1
Geänderte Binärdaten werden in die Logs geschrieben. Ohne Angabe dieser Option kann sowohl in den Logs als auch beim Aufruf des bitrix-Portals selbst ein Fehler auftreten:
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
Fehlerprotokolle:
log=/var/log/mysqld.log
log_error = /var/log/mysqld.log
Pfad zu den Transaktionsprotokollen des Servers (binlog wird vom Master verwaltet):
log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index
Pfad zu den Slave-Relay-Protokollen (binlog wird vom Master heruntergeladen):
relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
Datenbanken, die repliziert werden müssen bzw. nicht repliziert werden müssen (wir führen nur eine Replikation für die Standard-Bitrix-Datenbank - sitemanager0 durch):
replicate-do-db = sitemanager0
replicate-ignore-db=test
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
Die Datenbank nicht binloggen:
binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
Um Auto-Increment-Konflikte zu vermeiden, weisen wir den Server an, die IDs ab der 3. zu generieren und jeweils 10 hinzuzufügen, d. h. 13, 23, 33, 43 usw:
auto_increment_increment = 10
auto_increment_offset = 3
Speichern Sie die Logs vom Master in Ihrem binlog, um sie an den Slave zu senden:
log-slave-updates
Starten Sie danach mysql neu:
[root@bitrix1 /]# /etc/init.d/mysqld restart
