Author
Daten sind die Währung von heutigen Web-, Mobile-, Sozialen-, Unternehmens- und Cloud-Anwendungen, sodass die Sicherstellung dieser Datenverfügbarkeit die oberste Priorität für jede digitale Organisation darstellt – einige Minuten Ausfallzeit auf Kundenseite können zu erheblichen Verlusten führen und den Ruf irreparabal schädigen. Bei internen Datensystemen kann sich jede Ausfallzeit ernsthaft auf die Produktivität auswirken, da geschäftskritische Abläufe und die Fähigkeit, auf Daten basierende Entscheidungen zu treffen, eingeschränkt werden.
Methoden zum Datenaustausch sind nicht neu, jedoch benötigt die nächste Generation von Web-, Cloud- und Kommunikationsdiensten ein hohes Maß an Skalierbarkeit, Verfügbarkeit und Agilität – was ganz eigene Herausforderungen mit sich bringt.
In dieser technischen Fallstudie führen wir Sie durch die Installation und Einrichtung eines MySQL InnoDB Clusters und verbinden einen MySQL Router im Kontext einer Big-Data-Anwendung für Solarenergieanlagenüberwachung und -managementsysteme.
Der Kontext – Big Data PV-Energieüberwachungs- und Managementlösung
Unser Kunde ist ein Pionier und führendes Unternehmen in der PV (Photovoltaik) Überwachung sowie intelligentem Energie- und Einspeisemanagement für erneuerbare Energien und Erwärmung. Das Unternehmen bietet professionelle Überwachungs- und Managementlösungen für PV-Anlagen auf der ganzen Welt an, die ein individuelles Anlagenmanagement in Flotten und für ganz spezifische Anforderungen ermöglichen.
Eine detaillierte Fehleranalyse und schnelle Problemlösung schützen gegen Ertragsverluste und sichern somit die Investition. Benutzer profitieren von Zeit- und Budgeteffizienz.
Die nahtlose Kommunikation zwischen WEB, Datenloggern und den einzelnen Komponenten gewährleistet eine zeitnahe Identifizierung von Problemen, sodass das Ertragsniveau stets aufrechterhalten werden kann. Ein intuitives Benutzer- und Systemmanagement liefern umfangreiche Filter-, Gruppierungs- und Ansichtsoptionen, die genau nach den Bedürfnissen und Wünschen des jeweiligen Nutzers umgesetzt werden können, sei es nach Region, Systemtyp, Dienstleistungsvertrag oder sonstigen Spezifikationen.
Die strukturierte Präsentation von Daten bedeutet, dass der Benutzer niemals den Überblick verliert. Die intelligente Echtzeit-Kompilierung einzelner Systeminformationen ermöglicht eine schnelle Fehleranalyse und -behebung und führt zu verbesserten Arbeitsabläufen sowie einer Ertragsoptimierung.
Datenbankzuverlässigkeit ist unerlässlich
Das PV-Anlagenüberwachungs- und -managementsystem unseres Kunden setzt einen sicheren und zuverlässigen Datenfluss voraus. Ein Teil unserer Aufgabe bestand darin, bei der Entscheidung und Verwendung eines MySQL InnoDB Clusters mitzuwirken.
Die Lösung? MySQL InnoDB Cluster
Ein MySQL InnoDB Cluster ist eine Oracle-High-Availability-Lösung, die über MySQL mit mehreren Master-Funktionen und automatischem Failover für eine hohe Verfügbarkeit installiert wird. Es ermöglicht Datenbank-Replikationen, die die Fehlertoleranz erhöhen, indem das Versagen eines Teils der Infrastruktur keine größeren Auswirkungen hat, da Datensicherungen von einem anderen Teil der Infrastruktur genutzt werden können.
Datenvervielfältigung erhöht die Fehlertoleranz einer verteilten MySQL-Datenbank
Beim Aufbau von zugänglichen und fehlertoleranten Systemen erstellen wir Bereiche in der Infrastruktur, in denen Daten dupliziert werden. Die Vervielfältigung von Daten erhöht die Verfügbarkeit und beschleunigt das Schreiben oder Lesen von Daten.
Datenduplikation findet am häufigsten in den folgenden Infrastrukturabschnitten statt:
- Load Balancers
- Speicherserver
- Datenbankserver
- Backup-Server
Diese technische Fallstudie stellt die Frage, wie eine verteilte MySQL-Datenbank für die Fehlertoleranz am besten organisiert werden kann, indem die Anzahl der verfügbaren Datenbankreplikationen erhöht wird.
Unser Ziel besteht darin, dies alleine durch MySQL zu erreichen, ohne hierfür auf Software von Drittanbietern zurückzugreifen.
Das Ergebnis war ein Cluster von 4 Servern, 1 Einstiegspunkt (mysql-Router) und 3 Datenspeicherserver (1 Master- und 2 Sekundärserver).
MySQL InnoDB Cluster Diagram
Bei der Installation haben wir 3 Server für MySQL direkt und 1 Server zur Verbindung mit unserem Cluster – MySQL-Router verwendet.
MySQL Server:
Shell 10.10.10.1 10.10.10.2 10.10.10.3
Router Server:
Shell 10.10.10.10
OS Centos 7 c deaktiviert selinux und firewalld. MySQL verwendet Version 5.7
Verbinden Sie das Repository:
Shell rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
Deaktivieren Sie Version 8 und aktivieren Sie 5.7:
Shell 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 Rules /etc/my.cnf Shell [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 = 10.10.10.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 10.10.10.1
Wir verbinden MySQL mit Port 3301, wo Daten zwischen den Clusterservern ausgetauscht werden.Wir bringen anschließend die Datei /etc/my.cnf zu diesem Format auf allen drei Servern des Clusters, ändern die IP in den Variablen lose-group_replication_local_address und report_host und ändern auch die server_id – diese ist für jeden Server eindeutig.Starten Sie MySQL für die anfängliche Einrichtung:
Shell systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation
Wir beginnen jetzt mit der Erstellung eines Clusters. Zuerst erstellen wir einen Cladmin-Nutzer auf allen 3 Servern; hierzu verwenden wir eine mysqlsh-Konsole:
Shell [[email protected] ~] mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "StrongPassword!#1"}) > \c [email protected]:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '10.10.10.1,10.10.10.2,10.10.10.3'}) > dba.configureLocalInstance() > cl.status()
Die Ausgabe von cl.status () sollte ungefähr wie folgt aussehen:
Shell
MySQL 10.10.10.1:3301 ssl JS > cluster.status()
{
"clusterName": "TestCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "10.10.10.1:3301",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",
"topology": {
"10.10.10.1:3301": {
"address": "10.10.10.1:3301",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "mysql://[email protected]:3301"
}
Wenn wir Änderungen in der Cluster-Konfiguration vornehmen, sollte der Command ausgeführt werden:
Shell > dba.configureLocalInstance()
Wir führen ähnliche Aktionen auf allen 3 Servern durch. Vergessen Sie hierbei nicht, die richtige IP- und ID in /etc/my.cnf (server_id, lose-group_replication_local_address, report_host) einzugeben.
Nachdem die vorherigen Schritte in den Nodes ausgeführt wurden, die wir verbinden (den 2. und 3. Server in unserem Beispiel), geht es weiter mit:
Shell [[email protected] ~] mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON; Shell [[email protected] ~] mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "StrongPassword!#1"}) > \c [email protected]:3301 > dba.checkInstanceConfiguration()
Nach dem Verfahren auf dem zweiten Server kehren wir anschließend zum ersten Server zurück:
Shell [[email protected] ~] mysqlsh --uri [email protected]:3301 --cluster > cluster.addInstance('[email protected]:3301', {ipWhitelist: '10.10.10.1,10.10.10.2,10.10.10.3'}) > cluster.status() > dba.configureLocalInstance()
Wir führen auch dba.configureLocalInstance () auf dem zweiten Server aus !!!
Die Ausgabe von cluster.status () sollte in etwa wie folgt aussehen:
Shell
{
"clusterName": "TestCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "10.10.10.1:3301",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",
"topology": {
"10.10.10.1:3301": {
"address": "10.10.10.1:3301",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
},
"1.1.1.2:3301": {
"address": "10.10.10.2:3301",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "mysql://[email protected]:3301"
}
In gleicher Weise fügen wir den dritten Server hinzu.Wenn wir in Zukunft das Cluster auf 5 oder mehr Server erweitern möchten, müssen wir hierzu die Whitelist bearbeiten. Dies kann über mysqlsh durchgeführt werden, indem Sie auf sql mode oder direkt auf /etc/my.cnf gehen (vergessen Sie nicht, mysql daemons neu zu starten).Ein Beispiel zur Verwendung der mysqlsh-Konsole (abwechselnd auf jedem der RW-Nodes):
Shell [[email protected] ~] mysqlsh --uri [email protected]:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="10.10.10.1,10.10.10.2,10.10.10.3,10.10.10.4,10.10.10.5"; > START GROUP_REPLICATION;
Nachdem alle 3 Server hinzugefügt wurden, wird sich cluster.status () wie folgt verändern:
Shell [[email protected] ~] mysqlsh --uri [email protected]:3301 --cluster MySQL 10.10.10.1:3301 ssl JS > cluster.status() { "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "10.10.10.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "10.10.10.1:3301": { "address": "10.10.10.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "10.10.10.2:3301": { "address": "10.10.10.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "10.10.10.3:3301": { "address": "10.10.10.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } }, "topologyMode": "Single-Primary" }, "groupInformationSourceMember": "10.10.10.1:3301" }
Wenn das Cluster durch den Status eines Servers zusammenfällt, muss es wie folgt gestartet werden: loose-group_replication_bootstrap_group = ON
parameter in /etc/my.cnf Nach dem Start muss der Parameter wieder ausgeschaltet werden, andernfalls trennt sich dieser Server vom Cluster und arbeitet unabhängig.
Mysql-Router-Konfiguration
Turnip hinzufügen und ein Paket erstellen:
Shell [root@mysql-router ~] rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm [root@mysql-router ~] yum install mysql-router
Erstellen Sie ein Verzeichnis für unsere Cluster-Konfigurationsdateien:
Shell [root@mysql-router ~] mkdir /etc/mysqlrouter/mysql-router
Wir werden die Konfiguration mit Bootstrap durchführen. Wenn Sie die IP-Adresse angeben, müssen Sie hierzu die Adresse des aktuellen RW-Servers angeben:
Shell [root@mysql-router ~] mysqlrouter --bootstrap [email protected]:3301 --directory /etc/mysqlrouter/mysql-router --user=root
Das Resultat einer erfolgreichen Konfiguration, Output:
Shell Reconfiguring MySQL Router instance at '/etc/mysqlrouter/mysql-router'... Checking for old Router accounts Creating account mysql_router1_yxkccoosbuoc@'%' MySQL Router has now been configured for the InnoDB cluster 'TestCluster'.
The following connection information can be used to connect to the cluster after MySQL Router has been started with generated configuration..
Classic MySQL protocol connections to cluster ‚TestCluster‘: – Read/Write Connections: localhost:6446 – Read/Only Connections: localhost:6447 X protocol connections to cluster ‚TestCluster‘: – Read/Write Connections: localhost:64460 – Read/Only Connections: localhost:64470
Port 6446 – für RW Verbindungen.
Port 6447 – für RO Verbindungen.
Erstellen Sie eine systemd Service-Datei, um den mysql-Router mit unseren generierten Konfigurationsdateien zu starten:
Shell [root@mysql-router ~] nano /etc/systemd/system/mysqlrouter-cluster.service Shell [Unit] Description=MySQL Router After=syslog.target After=network.target [Service] Type=simple User=root Group=root PIDFile=/etc/mysqlrouter/mysql-router/mysqlrouter.pid ExecStart=/bin/bash -c "/usr/bin/mysqlrouter -c /etc/mysqlrouter/mysql-router/mysqlrouter.conf" Restart=on-failure RestartPreventExitStatus=1 PrivateTmp=true [Install] WantedBy=multi-user.target
Schalten Sie es beim Start ein und führen Sie Ihren Router aus:
Shell systemctl daemon-reload systemctl start mysqlrouter-cluster systemctl status mysqlrouter-cluster
Prüfung
Schlussfolgerung – High Availability & Fehlertoleranz der Datenbank
Die Wahl eines MySQL InnoDB Clusters hat sich als äußerst robust und effektiv erwiesen, um das Niveau der Verfügbarkeit und der Fehlertoleranz zu erreichen, das für eine effektive Überwachung und den gewünschten Ertrag absolut notwendig ist. Wir hoffen, dass die Kombination zwischen Business Case und Schritt-für-Schritt-Anleitung verdeutlicht, wann und wo ein MySQL InnoDB Cluster die richtige Wahl für eine Datenbank-zentrische Softwarelösung sein kann, um Herausforderungen bzgl. High Availability und Fehlertoleranz bestmöglich zu lösen.
