Es gibt mehrere Möglichkeiten, eine Datenbank bereitzustellen. Sie können es von Hand installieren, Sie können sich auf die weit verbreiteten Infrastruktur-Orchestrierungstools wie Ansible, Chef, Puppet oder Salt verlassen. Diese Tools sind sehr beliebt und es ist ziemlich einfach, Skripte, Rezepte, Playbooks usw. zu finden, die Ihnen helfen, die Installation eines Datenbankclusters zu automatisieren. Es gibt auch spezialisiertere Datenbankautomatisierungsplattformen wie ClusterControl, die auch für die automatisierte Bereitstellung verwendet werden können. Was wäre die beste Methode zur Bereitstellung Ihres Clusters? Wie viel Zeit benötigen Sie tatsächlich für die Bereitstellung?
Lassen Sie uns zunächst klären, was wir tun wollen. Nehmen wir an, wir werden Percona XtraDB Cluster 5.7 bereitstellen. Es wird aus drei Knoten bestehen und dafür werden wir drei virtuelle Vagrant-Maschinen verwenden, auf denen Ubuntu 16.04 (bento/ubuntu-16.04-Image) ausgeführt wird. Wir werden versuchen, einen Cluster manuell bereitzustellen und dann Ansible und ClusterControl verwenden. Mal sehen, wie die Ergebnisse aussehen werden.
Manuelle Bereitstellung
Repository-Setup - 1 Minute, 45 Sekunden.
Zunächst müssen wir Percona-Repositorys auf allen Ubuntu-Knoten konfigurieren. Eine schnelle Google-Suche, eine SSH-Verbindung zu den virtuellen Maschinen und das Ausführen der erforderlichen Befehle dauert 1 45 Minuten
Wir haben die folgende Seite mit Anweisungen gefunden:
https://www.percona.com/doc/percona-repo-config/percona-release.html
und wir haben die im Abschnitt „DEB-BASIERTE GNU/LINUX-DISTRIBUTIONEN“ beschriebenen Schritte ausgeführt. Wir haben auch apt update ausgeführt, um den Cache von apt zu aktualisieren.
Installieren von PXC-Knoten - 2 Minuten 45 Sekunden
Dieser Schritt besteht im Wesentlichen aus der Ausführung von:
[email protected]:~# apt install percona-xtradb-cluster-5.7Der Rest hängt hauptsächlich von der Geschwindigkeit Ihrer Internetverbindung ab, während Pakete heruntergeladen werden. Ihre Eingabe wird ebenfalls benötigt (Sie übergeben ein Passwort für den Superuser), sodass es sich nicht um eine unbeaufsichtigte Installation handelt. Wenn alles erledigt ist, haben Sie am Ende drei laufende Percona XtraDB-Cluster-Knoten:
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Konfigurieren von PXC-Knoten - 3 Minuten, 25 Sekunden
Hier beginnt der heikle Teil. Es ist wirklich schwer, die Erfahrung zu quantifizieren und wie viel Zeit man brauchen würde, um tatsächlich zu verstehen, was getan werden muss. Was gut ist, die Google-Suche „how to install percona xtrabdb cluster“ verweist auf die Dokumentation von Percona, die beschreibt, wie der Prozess aussehen sollte. Es kann immer noch mehr oder weniger Zeit in Anspruch nehmen, je nachdem, wie vertraut Sie mit PXC und Galera im Allgemeinen sind. Im schlimmsten Fall bemerken Sie keine zusätzlichen erforderlichen Aktionen und Sie verbinden sich mit Ihrem PXC und beginnen damit zu arbeiten, ohne zu bemerken, dass Sie tatsächlich drei Knoten haben, von denen jeder einen eigenen Cluster bildet.
Nehmen wir an, wir folgen der Empfehlung von Percona und planen genau diese auszuführenden Schritte. Kurz gesagt, wir haben die Konfigurationsdateien gemäß den Anweisungen auf der Percona-Website geändert, wir haben auch versucht, den ersten Knoten zu booten:
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CDas sah nicht richtig aus. Leider war die Anleitung nicht glasklar. Auch hier gilt:Wenn Sie nicht wissen, was vor sich geht, verbringen Sie mehr Zeit damit, zu verstehen, was passiert ist. Glücklicherweise ist stackoverflow.com sehr hilfreich (obwohl nicht die erste Antwort auf der Liste, die wir erhalten haben), und Sie sollten feststellen, dass Sie die Kopfzeile des [mysqld]-Abschnitts in Ihrer /etc/mysql/my.cnf-Datei vermissen. Das Hinzufügen auf allen Knoten und das Wiederholen des Bootstrap-Prozesses lösten das Problem. Insgesamt haben wir 3 Minuten und 25 Sekunden damit verbracht (ohne das Googeln nach dem Fehler, da uns sofort aufgefallen ist, was das Problem war).
Konfigurieren für SST, Einbringen anderer Knoten in den Cluster – von 8 Minuten bis unendlich
Die Anweisungen auf der Percona-Website sind recht klar. Sobald Sie einen Knoten betriebsbereit haben, starten Sie einfach die verbleibenden Knoten und es wird Ihnen gut gehen. Wir haben das versucht und konnten keine weiteren Knoten sehen, die dem Cluster beitreten. Hier ist es praktisch unmöglich zu sagen, wie lange es dauern wird, das Problem zu diagnostizieren. Wir haben 6-7 Minuten gebraucht, aber um es schnell machen zu können, müssen Sie:
- Machen Sie sich mit der Struktur der PXC-Konfiguration vertraut:
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Wissen, wie die Direktiven !include und !includedir in MySQL-Konfigurationsdateien funktionieren
- Wissen, wie MySQL mit denselben Variablen umgeht, die in mehreren Dateien enthalten sind
- Wissen Sie, wonach Sie suchen müssen, und achten Sie auf Konfigurationen, die dazu führen würden, dass sich ein Knoten selbst bootet, um einen eigenen Cluster zu bilden
Das Problem hing damit zusammen, dass die Anweisungen keine Datei außer /etc/mysql/my.cnf erwähnten, wo wir eigentlich /etc/mysql/percona-xtradb-cluster.conf.d/wsrep hätten ändern sollen .cnf. Diese Datei enthielt eine leere Variable:
wsrep_cluster_address=gcomm://und eine solche Konfiguration zwingt den Knoten zum Bootstrap, da er keine Informationen über andere Knoten hat, denen er beitreten kann. Wir haben diese Variable in /etc/mysql/my.cnf gesetzt, aber später wurde die wsrep.cnf-Datei hinzugefügt, wodurch unser Setup überschrieben wurde.
Dieses Problem könnte ein ernsthaftes Hindernis für Leute sein, die nicht wirklich mit der Funktionsweise von MySQL und Galera vertraut sind, was sogar zu stundenlangem Debugging führen kann, wenn nicht sogar mehr.
Gesamtinstallationszeit - 16 Minuten (wenn Sie wie ich MySQL DBA sind)
Wir haben es geschafft, Percona XtraDB Cluster in 16 Minuten zu installieren. Man muss ein paar Dinge beachten - wir haben die Konfiguration nicht optimiert. Dies ist etwas, das mehr Zeit und Wissen erfordert. Der PXC-Knoten verfügt über einige einfache Konfigurationen, die sich hauptsächlich auf die binäre Protokollierung und die Galera-Writeset-Replikation beziehen. Es gibt kein InnoDB-Tuning. Wenn Sie mit MySQL-Interna nicht vertraut sind, müssen Sie Stunden, wenn nicht Tage lesen und sich mit internen Mechanismen vertraut machen. Ein weiterer wichtiger Punkt ist, dass dies ein Prozess ist, den Sie für jeden bereitgestellten Cluster erneut anwenden müssten. Schließlich gelang es uns, das Problem zu identifizieren und es aufgrund unserer Erfahrung mit Percona XtraDB Cluster und MySQL im Allgemeinen sehr schnell zu lösen. Gelegenheitsbenutzer werden höchstwahrscheinlich wesentlich mehr Zeit damit verbringen, zu verstehen, was vor sich geht und warum.
Ansible-Playbook
Nun zur Automatisierung mit Ansible. Versuchen wir, ein ansibles Playbook zu finden und zu verwenden, das wir für alle weiteren Bereitstellungen wiederverwenden könnten. Mal sehen, wie lange das dauern wird.
SSH-Konnektivität konfigurieren - 1 Minute
Ansible erfordert SSH-Konnektivität über alle Knoten hinweg, um sie zu verbinden und zu konfigurieren. Wir haben einen SSH-Schlüssel generiert und manuell auf die Knoten verteilt.
Ansible Playbook finden – 2 Minuten 15 Sekunden
Das Hauptproblem hier ist, dass es so viele Playbooks gibt, dass es unmöglich ist, zu entscheiden, was das Beste ist. Daher haben wir uns entschieden, die Top 3 der Google-Ergebnisse zu verwenden und zu versuchen, eines auszuwählen. Wir haben uns für https://github.com/cdelgehier/ansible-role-XtraDB-Cluster entschieden, da es konfigurierbarer zu sein scheint als die anderen.
Repository klonen und Ansible installieren - 30 Sekunden
Das geht schnell, alles, was wir brauchten, war
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitInventardatei vorbereiten - 1 Minute 10 Sekunden
Dieser Schritt war auch sehr einfach, wir haben eine Inventardatei anhand eines Beispiels aus der Dokumentation erstellt. Wir haben einfach die IP-Adressen der Knoten durch das ersetzt, was wir in unserer Umgebung konfiguriert haben.
Vorbereiten eines Playbooks – 1 Minute 45 Sekunden
Wir haben uns für das umfangreichste Beispiel aus der Dokumentation entschieden, das auch ein wenig Konfigurationstuning beinhaltet. Wir haben eine korrekte Struktur für das Ansible vorbereitet (es gab keine solche Information in der Dokumentation):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterDann haben wir es ausgeführt, aber sofort bekamen wir einen Fehler:
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Dies dauerte 1 Minute und 45 Sekunden.
Behebung des Playbook-Syntaxproblems - 3 Minuten 25 Sekunden
Der Fehler war irreführend, aber die allgemeine Faustregel lautet, eine neuere Ansible-Version auszuprobieren, was wir auch getan haben. Wir haben gegoogelt und gute Anleitungen auf der Ansible-Website gefunden. Der nächste Versuch, das Playbook auszuführen, ist ebenfalls fehlgeschlagen:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}Das Einrichten einer neuen Ansible-Version und das Ausführen des Playbooks bis zu diesem Fehler dauerte 3 Minuten und 25 Sekunden.
Das fehlende Python-Modul reparieren - 3 Minuten 20 Sekunden
Anscheinend hat die von uns verwendete Rolle ihre Voraussetzungen nicht berücksichtigt und es fehlte ein Python-Modul, um sich mit dem Galera-Cluster zu verbinden und es abzusichern. Wir haben zuerst versucht, MySQL-python über pip zu installieren, aber es hat sich herausgestellt, dass es länger dauern wird, da mysql_config:
erforderlich ist[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Das wird von MySQL-Entwicklungsbibliotheken bereitgestellt, also müssten wir sie manuell installieren, was ziemlich sinnlos war. Wir entschieden uns für PyMySQL, für das keine anderen Pakete installiert werden mussten. Dies brachte uns zu einem anderen Problem:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryBis zu diesem Punkt haben wir 3 Minuten und 20 Sekunden gebraucht.
Behebung des Fehlers „Zugriff verweigert“ – 18 Minuten 55 Sekunden
Gemäß Fehler haben wir sichergestellt, dass die MySQL-Konfiguration korrekt vorbereitet ist und dass sie den richtigen Benutzer und das richtige Passwort für die Verbindung zur Datenbank enthält. Dies hat leider nicht wie erwartet funktioniert. Wir haben weiter nachgeforscht und festgestellt, dass die Rolle den Root-Benutzer nicht ordnungsgemäß erstellt hat, obwohl sie den Schritt als abgeschlossen markiert hat. Wir haben eine kurze Untersuchung durchgeführt, uns aber entschieden, die manuelle Korrektur vorzunehmen, anstatt zu versuchen, das Playbook zu debuggen, was viel mehr Zeit in Anspruch nehmen würde als die von uns durchgeführten Schritte. Wir haben gerade manuell die Benutzer [email protected] und [email protected] mit korrekten Passwörtern erstellt. Dadurch konnten wir diesen Schritt übergehen und zu einem anderen Fehler kommen:
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryFür diesen Abschnitt haben wir 18 Minuten und 55 Sekunden aufgewendet.
Behebung des Problems „Start the Slave Nodes“ (Teil 1) – 7 Minuten 40 Sekunden
Wir haben ein paar Dinge versucht, um dieses Problem zu lösen. Wir haben versucht, den Knoten mit seinem Namen anzugeben, wir haben versucht, Gruppennamen zu wechseln, nichts hat das Problem gelöst. Wir haben uns entschieden, die Umgebung mit dem in der Dokumentation bereitgestellten Skript zu bereinigen und von vorne zu beginnen. Es hat es nicht gereinigt, sondern nur noch schlimmer gemacht. Nach 7 Minuten und 40 Sekunden entschieden wir uns, die virtuellen Maschinen zu löschen, die Umgebung neu zu erstellen und von vorne anzufangen, in der Hoffnung, dass das Hinzufügen der Python-Abhängigkeiten unser Problem lösen wird.
Behebung des Problems „Start the Slave Nodes“ (Teil 2) – 13 Minuten 15 Sekunden
Leider hat das Einrichten von Python-Voraussetzungen überhaupt nicht geholfen. Wir haben uns entschieden, den Prozess manuell zu beenden, den ersten Knoten zu booten und dann den SST-Benutzer zu konfigurieren und die verbleibenden Slaves zu starten. Damit war die „automatisierte“ Einrichtung abgeschlossen und wir brauchten 13 Minuten und 15 Sekunden, um Fehler zu beheben und schließlich zu akzeptieren, dass es nicht so funktionieren wird, wie der Playbook-Designer es erwartet hatte.
Weiteres Debugging - 10 Minuten 45 Sekunden
Wir haben hier nicht aufgehört und entschieden, dass wir noch etwas versuchen werden. Anstatt sich auf Ansible-Variablen zu verlassen, setzen wir einfach die IP eines der Knoten als Master-Knoten. Dies löste diesen Teil des Problems und wir endeten mit:
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}Dies war das Ende unserer Versuche - wir haben versucht, diesen Benutzer hinzuzufügen, aber es funktionierte nicht richtig durch das ansible Playbook, während wir die lokale IPv6-Hostadresse verwenden konnten, um eine Verbindung herzustellen, wenn wir den MySQL-Client verwenden.
Gesamtinstallationszeit - Unbekannt (automatische Installation fehlgeschlagen)
Insgesamt haben wir 64 Minuten gebraucht und es immer noch nicht geschafft, die Dinge automatisch zum Laufen zu bringen. Die verbleibenden Probleme sind die Root-Passwort-Erstellung, die nicht zu funktionieren scheint, und das Starten des Galera-Clusters (SST-Benutzerproblem). Es ist schwer zu sagen, wie lange es dauern wird, es weiter zu debuggen. Es ist sicher möglich - es ist nur schwer zu quantifizieren, da es wirklich von der Erfahrung mit Ansible und MySQL abhängt. Es ist definitiv nicht etwas, das jeder einfach herunterladen, konfigurieren und ausführen kann. Nun, vielleicht hätte ein anderes Playbook anders funktioniert? Es ist möglich, aber es kann auch zu anderen Problemen führen. Ok, es gibt also eine Lernkurve zu erklimmen und Debugging zu machen, aber dann, wenn Sie fertig sind, werden Sie einfach ein Skript ausführen. Nun, das stimmt irgendwie. Solange vom Betreuer eingeführte Änderungen nicht etwas kaputt machen, von dem Sie abhängig sind, oder die neue Ansible-Version das Playbook kaputt macht, oder der Betreuer das Projekt einfach vergisst und die Entwicklung einstellt (für die Rolle, die wir verwendet haben, wartet eine ziemlich nützliche Pull-Anfrage bereits seit fast einem Jahr, was möglicherweise das Python-Abhängigkeitsproblem lösen kann - es wurde nicht zusammengeführt). Wenn Sie nicht akzeptieren, dass Sie diesen Code pflegen müssen, können Sie sich nicht wirklich darauf verlassen, dass er zu 100 % korrekt ist und in Ihrer Umgebung funktioniert, insbesondere angesichts der Tatsache, dass der ursprüngliche Entwickler keinen Anreiz hat, den Code auf dem neuesten Stand zu halten. Und was ist mit anderen Versionen? Sie können dieses spezielle Playbook nicht verwenden, um PXC 5.6 oder eine andere MariaDB-Version zu installieren. Sicher, es gibt andere Playbooks, die Sie finden können. Werden sie besser funktionieren oder verbringen Sie vielleicht noch ein paar Stunden damit, sie zum Laufen zu bringen?
ClusterControlEine Konsole für Ihre gesamte DatenbankinfrastrukturErfahren Sie, was es sonst noch Neues in ClusterControl gibt. Installieren Sie ClusterControl KOSTENLOSClusterControl
Lassen Sie uns abschließend einen Blick darauf werfen, wie ClusterControl zum Bereitstellen von Percona XtraDB Cluster verwendet werden kann.
SSH-Konnektivität konfigurieren - 1 Minute
ClusterControl erfordert eine SSH-Konnektivität über alle Knoten hinweg, um sie zu verbinden und zu konfigurieren. Wir haben einen SSH-Schlüssel generiert und manuell auf die Knoten verteilt.
ClusterControl einrichten - 3 Minuten 15 Sekunden
Die Schnellsuche „ClusterControl install“ verwies uns auf die relevante ClusterControl-Dokumentationsseite. Wir suchten nach einer „einfacheren Möglichkeit, ClusterControl zu installieren“, daher folgten wir dem Link und fanden die folgende Anleitung.
Das Herunterladen und Ausführen des Skripts dauerte 3 Minuten und 15 Sekunden. Wir mussten einige Maßnahmen ergreifen, während die Installation fortschritt, damit es sich nicht um eine unbeaufsichtigte Installation handelt.
Anmelden bei der Benutzeroberfläche und Start der Bereitstellung – 1 Minute 10 Sekunden
Wir haben unseren Browser auf die IP des ClusterControl-Knotens verwiesen.
Wir haben die erforderlichen Kontaktinformationen übergeben und der Willkommensbildschirm wurde angezeigt:
Nächster Schritt – wir haben die Bereitstellungsoption ausgewählt.
Wir mussten SSH-Konnektivitätsdetails weitergeben.
Wir haben uns auch für den zu verwendenden Anbieter, die Version, das Passwort und die zu verwendenden Hosts entschieden. Dieser ganze Vorgang dauerte 1 Minute und 10 Sekunden.
Percona XtraDB-Cluster-Bereitstellung - 12 Minuten 5 Sekunden
Es blieb nur noch zu warten, bis ClusterControl die Bereitstellung abgeschlossen hatte. Nach 12 Minuten und 5 Sekunden war der Cluster fertig:
Gesamtinstallationszeit - 17 Minuten 30 Sekunden
Verwandte Ressourcen ClusterControl für MySQL ClusterControl für MariaDB ClusterControl für Galera-ClusterWir haben es geschafft, ClusterControl und dann PXC-Cluster mit ClusterControl in 17 Minuten und 30 Sekunden bereitzustellen. Die PXC-Bereitstellung selbst dauerte 12 Minuten und 5 Sekunden . Am Ende haben wir einen funktionierenden Cluster, der gemäß den Best Practices eingesetzt wird. ClusterControl sorgt auch dafür, dass die Konfiguration des Clusters sinnvoll ist. Kurz gesagt, selbst wenn Sie nicht wirklich etwas über MySQL oder Galera Cluster wissen, können Sie in wenigen Minuten einen produktionsbereiten Cluster bereitstellen. ClusterControl ist nicht nur ein Deployment-Tool, es ist auch eine Verwaltungsplattform – macht es für Personen, die keine Erfahrung mit MySQL und Galera haben, noch einfacher, Leistungsprobleme zu identifizieren (durch Berater) und Verwaltungsaktionen durchzuführen (den Cluster hoch- und herunterzuskalieren, Sicherungen auszuführen, asynchrone Slaves zu Galera). Was wichtig ist, ClusterControl wird immer gepflegt und kann verwendet werden, um alle MySQL-Varianten bereitzustellen (und nicht nur MySQL/MariaDB, es unterstützt auch TimeScaleDB, PostgreSQL und MongoDB). Es funktionierte auch sofort, was man von anderen Methoden, die wir getestet haben, nicht behaupten kann.
Wenn Sie dasselbe erleben möchten, können Sie ClusterControl kostenlos herunterladen. Lassen Sie uns wissen, wie es Ihnen gefallen hat.
