Hallo allerseits!
Sobald eine Aufgabe im Job angezeigt wurde - auf mehreren virtuellen Maschinen mit Centos 7.5 scheint es einen konfigurierten Test-InnoDB-Cluster zu geben. Sie müssen ihn untersuchen und ein paar weitere Knoten hinzufügen. Sie können brechen und verspotten, wie Sie möchten. Klingt verlockend.
Zuvor hatte ich keine Erfahrung mit einem solchen Cluster, aber Google half.
Mit wenigen Ausnahmen befanden sich alle Links darin und in Yandex entweder auf dev.mysql.com oder in diesem
Artikel auf Habr . Es scheint, als wäre ein Cluster von zwei Knoten darauf konfiguriert worden.
Nun, ich habe den Artikel gelesen, ich war etwas überrascht über die Komplexität des Hinzufügens von Knoten und das Fehlen vieler Details, aber na ja. Mit einer Sünde fügte ich einen halben neuen Knoten hinzu (einige der Befehle waren nicht nützlich, andere brachen alles), woraufhin ich anfing, mit dem Neustart der Knoten usw. zu experimentieren.
Nach mehreren Ansätzen und unzähligen Todesfällen von Nervenzellen konnte der Cluster es nicht ertragen. Ein Knoten wollte unter keinen Umständen hinzugefügt werden, der andere legte auf, als ich versuchte, auf die Datenbank zuzugreifen, der dritte tat so, als sei alles in Ordnung. Ich musste schießen und von vorne anfangen.
Beim Erstellen eines neuen Clusters traten leider viele Probleme und Inkonsistenzen auf. Vielleicht liegt der Punkt in Softwareversionen, ich habe MySQL 5.7 ausprobiert. Vielleicht in der Distribution. Infolgedessen stoppte ich gedankenlose Versuche, alles auf einem Stück Papier zu tun, und begann, es durch Tippen einzurichten. Und google.
Ein paar angenehme Abende und Nächte, und die Gruppe versammelte sich und weigerte sich sogar, zusammenzubrechen.
Gleichzeitig unterschied sich die Methode ihrer Erstellung deutlich von früheren Versuchen, und ich wollte sie teilen, weil Im Internet habe ich keine anderen relevanten detaillierten verständlichen Anweisungen zum Einrichten des inndoDB-Clusters gefunden.
Wir haben also drei identische virtuelle Maschinen mit dem neu installierten Centos 7.5 Minimum 1804 und deaktiviertem Selinux und Firewalld:
1.1.1.1
1.1.1.2
1.1.1.3
Für die Arbeit habe ich MySQL 5.7 verwendet, also verwenden wir es. Beginnen wir mit 1.1.1.1:
1. Installieren Sie das MySQL-Community-Repository:
rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
Schalten Sie das Repository für 8 aus, schalten Sie es für 5.7 ein und überprüfen Sie, ob alles in Ordnung ist. Installieren Sie dann mysql:
yum install yum-utils yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community yum repolist yum install mysql-community-server mysql-shell
2. Wir bringen /etc/my.cnf in dieses Formular:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid bind-address=0.0.0.0 port=3301 # Replication part server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW plugin-load = group_replication.so # Group replication part transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot = OFF loose-group_replication_local_address = 1.1.1.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 1.1.1.1
Hier ist 3301 der Port, an dem MySQL lauscht, und 33011 ist der Port, an dem die Knoten miteinander kommunizieren.
3. Starten Sie MySQL und führen Sie die vorläufige Konfiguration durch:
systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation
4. Erstellen Sie einen Cluster sowie einen separaten Benutzer, um ihn zu verwalten. Wenn Sie die IP-Adressen der Knoten im Voraus kennen, können Sie sie sofort in der ipWhitelist auflisten. Wir werden so tun, als wüssten wir noch nichts über 1.1.1.2. und 1.1.1.3:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.1:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '1.1.1.1'}) > dba.configureLocalInstance() > cl.status()
Fertig! cl.status sollte ungefähr Folgendes ausgeben:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Beim Ändern des Clusters muss der Befehl dba.configureLocalInstance () lokal auf allen Knoten ausgeführt werden, um die Änderungen zu speichern:
WARNING: On instance '1.1.1.1:3301' membership change cannot be persisted since MySQL version 5.7.23 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the <Dba>.configureLocalInstance command locally to persist the changes.
Weil Wir werden ein paar weitere Knoten hinzufügen. Wir schließen die Verbindung mit Server 1.1.1.1 nicht, dies ist praktisch für uns.
Versuchen wir nun, dem Cluster den Knoten 1.1.1.2 hinzuzufügen. Zu diesem Zweck führen wir dieselben Befehle in bis zu 3 Schritten aus, wobei wir nicht vergessen, server_id, lose Gruppenreplikationslokaladresse und report_host zu ändern.
4. Wir führen am 1.1.1.2 aus:
mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
Ich habe versucht, diese Variable über mysqlsh festzulegen und in den SQL-Modus zu wechseln, aber die dortigen Aktionen hatten keine Auswirkungen auf mysql. Weiter:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.2:3301 > dba.checkInstanceConfiguration()
5. Kehren Sie zum ersten Knoten 1.1.1.1 zurück. Wenn Sie die Verbindung geschlossen haben, können Sie schnell eine Verbindung zum Cluster herstellen:
mysqlsh --uri cladmin@1.1.1.1:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="1.1.1.1,1.1.1.2"; > START GROUP_REPLICATION; > \js > cluster.addInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2'}) > cluster.status()
Wenn Sie einen Knoten ohne die Option ipWhitelist hinzufügen, wird er aus irgendeinem Grund nicht automatisch an ihn übertragen. Daher geben wir ihn manuell an.
Wenn Ihre Whitelist anfänglich für alle Knoten oder ein Subnetz konfiguriert ist, können Befehle im SQL-Modus übersprungen werden.
Vergessen Sie nicht, dba.configureLocalInstance () auf allen Knoten auszuführen, um die Konfiguration zu speichern.
Der Cluster ihrer beiden Knoten stellte sich heraus:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Nun, es gibt einen Cluster aus zwei Knoten, aber im Modus "Cluster ist NICHT tolerant gegenüber Fehlern"
Fügen Sie einen dritten hinzu, der Algorithmus ist im Grunde der gleiche wie das Hinzufügen eines zweiten.
Wenn Sie die Whitelist erneut ändern müssen, müssen Sie die Befehle auf dem R / W-Knoten ausführen, weil Auf R / O-Knoten scheint es zu nichts zu führen. In diesem Fall fallen die R / O-Knoten ab und müssen erneut verbunden werden, wobei gleichzeitig eine neue Whitelist gemeldet wird.
In unserem Fall:
> cluster.rejoinInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2,1.1.1.3'})
Vergessen Sie auch hier nicht, dba.configureLocalInstance () auf allen Knoten auszuführen, um die Konfiguration zu speichern.
Ein Cluster von drei Knoten sieht folgendermaßen aus:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.3:3301": { "address": "1.1.1.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Wenn der Cluster auf den Status eines Knotens zusammengebrochen ist, muss er mit dem Parameter lose-Gruppenreplikation_bootstrap_group = ON in /etc/my.cnf gestartet werden
Nach dem Start muss der Parameter wieder ausgeschaltet werden, andernfalls wird dieser Knoten immer vom Cluster getrennt und behält seinen eigenen bei.
Die Installation des MySQL-Routers wird
hier ausführlich beschrieben, sodass ich keinen Sinn darin sehe, sie zu duplizieren.
Das ist alles, das ist es, ich hoffe, jemand wird meine Erfahrung nützlich finden.
Vielen Dank für Ihre Aufmerksamkeit.