Im ersten Teil der Serie haben wir Ihnen gezeigt, wie Sie ein MySQL-Replikations-Setup mit ProxySQL mit WHM und cPanel bereitstellen. In diesem Teil zeigen wir einige Vorgänge nach der Bereitstellung für Wartung, Verwaltung, Failover sowie Vorteile gegenüber der eigenständigen Einrichtung.
MySQL-Benutzerverwaltung
Wenn diese Integration aktiviert ist, muss die MySQL-Benutzerverwaltung über WHM oder cPanel erfolgen. Andernfalls würde die ProxySQL-Tabelle mysql_users nicht mit dem synchronisiert werden, was für unseren Replikationsmaster konfiguriert ist. Angenommen, wir haben bereits einen Benutzer namens multiplen_user1 erstellt (dem MySQL-Benutzernamen wird automatisch das Präfix cPanel vorangestellt, um die MySQL-Beschränkung einzuhalten), und wir möchten der Datenbank multiplen_db1 wie unten zuweisen:
Das Obige führt zu der folgenden mysql_users-Tabellenausgabe in ProxySQL:
Wenn Sie MySQL-Ressourcen außerhalb von cPanel erstellen möchten, können Sie ClusterControl -> Manage -> Schemas and Users verwenden und importieren Sie dann den Datenbankbenutzer in ProxySQL, indem Sie zu ClusterControl -> Knoten -> ProxySQL-Knoten auswählen -> Benutzer -> Benutzer importieren gehen .
Das Proxysqlhook-Modul, das wir zum Synchronisieren von ProxySQL-Benutzern verwenden, sendet die Debugging-Protokolle an /usr/local/cpanel/logs/error_log. Verwenden Sie diese Datei, um zu untersuchen und zu verstehen, was hinter den Kulissen passiert. Die folgenden Zeilen würden in der cPanel-Protokolldatei erscheinen, wenn wir eine Webanwendung namens Zikula mit Softaculous installiert hätten:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Sie würden einige wiederholte Zeilen wie „Überprüfen, ob {DB-Benutzer} existiert“ sehen, da WHM mehrere MySQL-Benutzer/-Hosts für jede Anforderung zum Erstellen einer Datenbankbenutzer erstellt. In unserem Beispiel würde WHM diese 3 Benutzer erstellen:
ProxySQL benötigt beim Hinzufügen eines Benutzers nur den Benutzernamen, das Kennwort und die Standard-Hostgruppeninformationen. Daher sind die Prüfzeilen dazu da, mehrfache Einfügungen des exakt gleichen Benutzers zu vermeiden.
Wenn Sie das Modul ändern und einige Verbesserungen daran vornehmen möchten, vergessen Sie nicht, das Modul erneut zu registrieren, indem Sie den folgenden Befehl auf dem WHM-Server ausführen:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookÜberwachung und Zwischenspeicherung von Abfragen
Mit ProxySQL können Sie alle Abfragen überwachen, die von der Anwendung stammen und die sie durchlaufen haben oder durchlaufen. Das standardmäßige WHM bietet diese Detailgenauigkeit bei der Überwachung von MySQL-Abfragen nicht. Das Folgende zeigt alle MySQL-Abfragen, die von ProxySQL erfasst wurden:
Mit ClusterControl können Sie ganz einfach die am häufigsten wiederholten Abfragen nachschlagen und sie über die ProxySQL-Abfrage-Cache-Funktion zwischenspeichern. Verwenden Sie das Dropdown-Menü „Sortieren nach“, um die Abfragen nach „Anzahl Sterne“ zu sortieren, fahren Sie mit der Maus zu der Abfrage, die Sie zwischenspeichern möchten, und klicken Sie darunter auf die Schaltfläche „Abfrage zwischenspeichern“. Der folgende Dialog erscheint:
Die Ergebnismenge zwischengespeicherter Abfragen wird von ProxySQL selbst gespeichert und bereitgestellt, wodurch die Anzahl der Zugriffe auf das Backend reduziert wird, wodurch Ihr MySQL-Replikationscluster als Ganzes entlastet wird. Die Implementierung des ProxySQL-Abfrage-Cache unterscheidet sich grundlegend vom MySQL-Abfrage-Cache. Es handelt sich um einen zeitbasierten Cache, der nach einem Timeout namens „Cache TTL“ abläuft. In dieser Konfiguration möchten wir die obige Abfrage für 5 Sekunden (5000 ms) zwischenspeichern, bevor sie die Reader-Gruppe erreicht, bei der die Ziel-Hostgruppe 20 ist.
Lese-/Schreibaufteilung und -ausgleich
Durch das Abhören des MySQL-Standardports 3306 verhält sich ProxySQL wie der MySQL-Server selbst. Es spricht MySQL-Protokolle sowohl im Frontend als auch im Backend. Die von ClusterControl beim Einrichten von ProxySQL definierten Abfrageregeln teilen automatisch alle Lesevorgänge (^SELECT .* in der Regex-Sprache) auf Hostgruppe 20 auf, die die Lesergruppe ist, und der Rest wird an die Writer-Hostgruppe 10 weitergeleitet, wie in gezeigt folgenden Abfrageregelabschnitt:
Bei dieser Architektur müssen Sie sich keine Gedanken über die Aufteilung von Lese-/Schreibabfragen machen, da ProxySQL die Arbeit für Sie erledigt. Die Benutzer haben minimale bis gar keine Änderungen am Code, was es den Hosting-Benutzern ermöglicht, alle Anwendungen und Funktionen, die von WHM und cPanel bereitgestellt werden, nativ zu verwenden, ähnlich wie eine Verbindung zu einem eigenständigen MySQL-Setup.
Wenn Sie in Bezug auf den Verbindungsausgleich mehr als einen aktiven Knoten in einer bestimmten Hostgruppe haben (wie in diesem Beispiel Reader-Hostgruppe 20), verteilt ProxySQL die Last automatisch zwischen ihnen, basierend auf einer Reihe von Kriterien – Gewichtungen, Replikationsverzögerung, verwendete Verbindungen , Gesamtlast und Latenz. ProxySQL ist dafür bekannt, dass es in Umgebungen mit hoher Parallelität sehr gut ist, indem es einen erweiterten Verbindungspooling-Mechanismus implementiert. Zitiert aus dem ProxySQL-Blogpost, ProxySQL implementiert nicht nur Persistent Connection, sondern auch Connection Multiplexing. Tatsächlich kann ProxySQL Hunderttausende von Clients verarbeiten und dennoch ihren gesamten Datenverkehr an wenige Verbindungen zum Backend weiterleiten. ProxySQL kann also N Client-Verbindungen und M Backend-Verbindungen verarbeiten, wobei N> M (sogar N tausendmal größer als M).
MySQL-Failover und Wiederherstellung
Wenn ClusterControl den Replikationscluster verwaltet, wird ein Failover automatisch durchgeführt, wenn die automatische Wiederherstellung aktiviert ist. Im Fall eines Master-Ausfalls:
- ClusterControl erkennt und verifiziert den Ausfall des Masters über den MySQL-Client, SSH und Ping.
- ClusterControl wartet 3 Sekunden, bevor ein Failover-Vorgang gestartet wird.
- ClusterControl befördert den aktuellsten Slave zum nächsten Master.
- Wenn der alte Master wieder online geht, wird er schreibgeschützt gestartet, ohne an der aktiven Replikation teilzunehmen.
- Es liegt an den Benutzern zu entscheiden, was mit dem alten Master passiert. Es könnte wieder in die Replikationskette eingeführt werden, indem die "Rebuild Replication Slave"-Funktionalität in ClusterControl verwendet wird.
- ClusterControl versucht nur einmal, das Master-Failover durchzuführen. Wenn dies fehlschlägt, ist ein Eingreifen des Benutzers erforderlich.
Sie können den gesamten Failover-Prozess unter ClusterControl -> Activity -> Jobs -> Failover to a new master überwachen wie unten gezeigt:
Während des Failovers werden alle Verbindungen zu den Datenbankservern in ProxySQL in die Warteschlange gestellt. Sie werden bis zum Timeout nicht beendet, gesteuert durch mysql-default_query_timeout Variable, die 86400000 Millisekunden oder 24 Stunden beträgt. Die Anwendungen würden zu diesem Zeitpunkt höchstwahrscheinlich keine Fehler oder Ausfälle in der Datenbank sehen, aber der Kompromiss besteht in einer erhöhten Latenz innerhalb eines konfigurierbaren Schwellenwerts.
An diesem Punkt präsentiert ClusterControl die Topologie wie folgt:
Wenn wir zulassen möchten, dass der alte Master wieder in die Replikation aufgenommen wird, nachdem er hochgefahren und verfügbar ist, müssen wir ihn als Slave neu erstellen, indem wir zu ClusterControl -> Nodes -> pick the old master -> Rebuild Replication gehen Slave -> neuen Master auswählen -> Fortfahren . Sobald der Neuaufbau abgeschlossen ist, sollten Sie die folgende Topologie erhalten (beachten Sie, dass 192.168.0.32 jetzt der Master ist):
Serverkonsolidierung und Datenbankskalierung
Mit dieser Architektur können wir viele MySQL-Server, die sich auf jedem WHM-Server befinden, in einem einzigen Replikations-Setup konsolidieren. Sie können mehr Datenbankknoten skalieren, wenn Sie wachsen, oder mehrere Replikationscluster haben, um alle zu unterstützen und von einem einzigen ClusterControl-Server verwaltet zu werden. Das folgende Architekturdiagramm zeigt, ob wir zwei WHM-Server haben, die über eine ProxySQL-Socket-Datei mit einem einzigen MySQL-Replikationscluster verbunden sind:
Das Obige ermöglicht es uns, die zwei wichtigsten Ebenen in unserem Hosting-System zu trennen – Anwendung (Front-End) und Datenbank (Back-End). Wie Sie vielleicht wissen, führt die gemeinsame Unterbringung von MySQL auf dem WHM-Server häufig zu einer Erschöpfung der Ressourcen, da MySQL eine enorme RAM-Zuweisung im Voraus benötigt, um zu starten und eine gute Leistung zu erbringen (hauptsächlich abhängig von der innodb_buffer_pool_size Variable). In Anbetracht dessen, dass der Speicherplatz ausreichend ist, können Sie mit dem obigen Setup mehr Hosting-Konten pro Server hosten, wobei alle Serverressourcen von den Front-End-Tier-Anwendungen genutzt werden können.
Das Hochskalieren des MySQL-Replikationsclusters wird mit einer separaten Tier-Architektur viel einfacher. Nehmen wir an, der Master muss gewartet werden (Upgrade von RAM, Festplatte, RAID, NIC), wir können die Master-Rolle auf einen anderen Slave übertragen (ClusterControl -> Nodes -> pick a slave -> Promote Slave<). /em> ) und führen Sie dann die Wartungsaufgabe aus, ohne den MySQL-Dienst als Ganzes zu beeinträchtigen. Beim Scale-out-Vorgang (Hinzufügen weiterer Slaves) können Sie dies durchführen, ohne den Master zu beeinträchtigen, indem Sie das Staging direkt von jedem aktiven Slave aus durchführen. Mit ClusterControl können Sie sogar einen neuen Slave aus einem bestehenden MySQL-Backup bereitstellen (nur PITR-kompatibel):
Der Wiederaufbau eines Slaves aus einem Backup bringt keine zusätzliche Belastung für den Master mit sich. ClusterControl kopiert die ausgewählte Sicherungsdatei vom ClusterControl-Server auf den Zielknoten und führt dort die Wiederherstellung durch. Sobald dies erledigt ist, verbindet sich der Knoten mit dem Master und beginnt, alle fehlenden Transaktionen seit der Wiederherstellungszeit abzurufen und den Master einzuholen. Wenn es verzögert wird, schließt ProxySQL den Knoten nicht in den Lastausgleichssatz ein, bis die Replikationsverzögerung weniger als 10 Sekunden beträgt (konfigurierbar, wenn eine mysql_servers-Tabelle über die ProxySQL-Verwaltungsschnittstelle hinzugefügt wird).
Abschließende Gedanken
ProxySQL erweitert die Möglichkeiten von WHM cPanel bei der Verwaltung der MySQL-Replikation. Mit ClusterControl, das Ihren Replikationscluster verwaltet, sind alle komplexen Aufgaben, die mit der Verwaltung des Replikationsclusters verbunden sind, jetzt einfacher als je zuvor.
