MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Vorbereiten eines MySQL- oder MariaDB-Servers für die Produktion – Teil Zwei

Im vorherigen Blog haben wir einige Tipps und Tricks zur Vorbereitung eines MySQL-Servers für den Produktionseinsatz aus Sicht eines Systemadministrators behandelt. Dieser Blogpost ist die Fortsetzung... 

Verwenden Sie ein Datenbank-Backup-Tool

Jedes Backup-Tool hat seine eigenen Vor- und Nachteile. Beispielsweise kann Percona Xtrabackup (oder MariaDB Backup for MariaDB) ein physisches Hot-Backup durchführen, ohne die Datenbanken zu sperren, aber es kann nur auf einer anderen Instanz auf dieselbe Version wiederhergestellt werden. Während mysqldump mit anderen MySQL-Hauptversionen kreuzkompatibel und für Teilsicherungen viel einfacher ist, ist es bei der Wiederherstellung im Vergleich zu Percona Xtrabackup bei großen Datenbanken relativ langsamer. MySQL 5.7 führt auch mysqlpump ein, ähnlich wie mysqldump mit parallelen Verarbeitungsfunktionen, um den Dump-Prozess zu beschleunigen.

Versäumen Sie nicht, alle diese Backup-Tools auf Ihrem MySQL-Server zu konfigurieren, da sie frei verfügbar und für die Datenwiederherstellung sehr wichtig sind. Da mysqldump und mysqlpump bereits in MySQL 5.7 und höher enthalten sind, müssen wir nur Percona Xtrabackup (oder MariaDB Backup for MariaDB) installieren, aber es erfordert einige Vorbereitungen, wie in den folgenden Schritten gezeigt:

Schritt Eins

Stellen Sie sicher, dass das Backup-Tool und seine Abhängigkeiten installiert sind:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

Verwenden Sie für MariaDB-Server stattdessen MariaDB Backup:

$ yum install -y socat pv MariaDB-Backup

Schritt Zwei

Erstellen Sie den Benutzer „xtrabackup“ auf dem Master, falls er nicht existiert:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Schritt drei

Erstellen Sie einen weiteren Benutzer namens „mysqldump“ auf dem Master, falls er nicht existiert. Dieser Benutzer wird für „mysqldump“ und „mysqlpump“ verwendet:

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

Schritt Vier

Fügen Sie die Anmeldeinformationen der Backup-Benutzer in der MySQL-Konfigurationsdatei unter den Direktiven [xtrabackup], [mysqldump] und [mysqlpump] hinzu:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

Durch die Angabe der obigen Zeilen müssen wir den Benutzernamen und das Passwort nicht im Backup-Befehl angeben, da das Backup-Tool diese Konfigurationsoptionen automatisch aus der Hauptkonfigurationsdatei lädt.

Stellen Sie sicher, dass die Backup-Tools vorher ordnungsgemäß getestet wurden. Für Xtrabackup, das Backup-Streaming über das Netzwerk unterstützt, muss dies zuerst getestet werden, um sicherzustellen, dass die Kommunikationsverbindung zwischen Quell- und Zielserver korrekt hergestellt werden kann. Führen Sie auf dem Zielserver den folgenden Befehl aus, damit socat auf Port 9999 lauscht und bereit ist, eingehendes Streaming zu akzeptieren:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Erstellen Sie dann ein Backup auf dem Quellserver und streamen Sie es auf Port 9999 auf dem Zielserver:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Sie sollten einen kontinuierlichen Ausgabestrom erhalten, nachdem Sie den Sicherungsbefehl ausgeführt haben. Warten Sie, bis die Zeile „Completed OK“ angezeigt wird, die eine erfolgreiche Sicherung anzeigt.

Mit pv können wir die Bandbreitennutzung drosseln oder den Fortschritt als einen Prozess sehen, der durch sie geleitet wird. Normalerweise wird der Streaming-Prozess das Netzwerk sättigen, wenn keine Drosselung aktiviert ist, und dies könnte zu Problemen mit anderen Servern führen, die mit einem anderen im selben Segment interagieren. Mit pv können wir den Streaming-Prozess drosseln, bevor wir ihn an das Streaming-Tool wie socat oder netcat übergeben. Das folgende Beispiel zeigt, dass das Backup-Streaming sowohl für eingehende als auch für ausgehende Verbindungen auf etwa 80 MB/s gedrosselt wird:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

Das Streamen eines Backups wird üblicherweise verwendet, um einen Slave bereitzustellen oder das Backup remote auf einem anderen Server zu speichern.

Für mysqldump und mysqlpump können wir mit den folgenden Befehlen testen:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Stellen Sie sicher, dass in der Ausgabe Nicht-Fehlerzeilen erscheinen.

Stresstest den Server

Belastungstests des Datenbankservers sind wichtig, um die maximale Kapazität zu verstehen, die wir für den jeweiligen Server erwarten können. Dies ist nützlich, wenn Sie sich zu einem späteren Zeitpunkt Schwellen oder Engpässen nähern. Sie können viele auf dem Markt erhältliche Benchmarking-Tools wie mysqlslap, DBT2 und sysbench verwenden.

In diesem Beispiel verwenden wir sysbench, um die Spitzenleistung des Servers, den Sättigungsgrad und auch die Temperatur der Komponenten zu messen, während er in einer Umgebung mit hoher Datenbankauslastung ausgeführt wird. Dadurch erhalten Sie ein grundlegendes Verständnis dafür, wie gut der Server ist, und können die Arbeitslast antizipieren, die der Server für unsere Anwendung in der Produktion verarbeiten kann.

Um Sysbench zu installieren und zu konfigurieren, können Sie es aus der Quelle kompilieren oder das Paket aus dem Percona-Repository installieren:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Erstellen Sie das Datenbankschema und den Benutzer auf dem MySQL-Server:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Generiere die Testdaten:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Führen Sie dann den Benchmark für 1 Stunde (3600 Sekunden) aus:

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

Während der Test läuft, verwenden Sie iostat (verfügbar im sysstat-Paket) in einem anderen Terminal, um die Festplattennutzung, Bandbreite, IOPS und E/A-Wartezeit zu überwachen:

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

Das obige Ergebnis wird alle 60 Sekunden gedruckt. Warten Sie, bis der Test beendet ist, und nehmen Sie den Durchschnitt von r/s (Lesevorgänge/Sekunde), w/s (Schreibvorgänge/Sekunde), %iowait, %util, rkB/s und wkB/s (Bandbreite). Wenn Sie eine relativ geringe Auslastung von Festplatte, CPU, RAM oder Netzwerk sehen, müssen Sie wahrscheinlich den Wert von „--threads“ auf eine noch höhere Zahl erhöhen, damit alle Ressourcen bis zum Limit genutzt werden.

Berücksichtigen Sie die folgenden zu messenden Aspekte:

  • Abfragen pro Sekunde =Sysbench-Zusammenfassung nach Abschluss des Tests unter SQL-Statistiken -> Abfragen -> Pro Sek.
  • Abfragelatenz =Sysbench-Zusammenfassung nach Abschluss des Tests unter Latenz (ms) -> 95. Perzentil.
  • Festplatten-IOPS =Durchschnitt von r/s + w/s
  • Festplattennutzung =Durchschnitt von %util
  • Plattenbandbreite R/W =Durchschnitt von rkB/s / Durchschnitt von wkB/s
  • Festplatten-E/A-Wartezeit =Durchschnitt von %iowait
  • Durchschnittliche Serverlast =Durchschnittliche durchschnittliche Auslastung, wie vom obersten Befehl gemeldet.
  • MySQL-CPU-Auslastung =Durchschnittliche CPU-Auslastung, wie vom obersten Befehl gemeldet.

Mit ClusterControl können Sie die oben genannten Informationen ganz einfach über das Nodes Overview Panel beobachten und abrufen, wie im folgenden Screenshot gezeigt:

Darüber hinaus können die während des Belastungstests gesammelten Informationen zur Optimierung von MySQL verwendet werden und InnoDB-Variablen entsprechend wie innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads und auch max_connections.

Um mehr über MySQL-Leistungs-Benchmarks mit SysBench zu erfahren, lesen Sie diesen Blog-Beitrag:Benchmarking der Leistung von MySQL und MariaDB mit SysBench.

Verwenden Sie ein Online-Schemaänderungstool

Schemaänderungen sind in relationalen Datenbanken unvermeidlich. Wenn die Anwendung wächst und im Laufe der Zeit anspruchsvoller wird, erfordert dies sicherlich einige Strukturänderungen an der Datenbank. Es gibt einige DDL-Vorgänge, die die Tabelle neu erstellen und somit die Ausführung anderer DML-Anweisungen blockieren, und dies könnte sich auf Ihre Datenbankverfügbarkeit auswirken, wenn Sie strukturelle Änderungen an einer großen Tabelle vornehmen. Um die Liste der blockierenden DDL-Operationen zu sehen, sehen Sie sich diese MySQL-Dokumentationsseite an und suchen Sie nach Operationen, die "Permits Concurrent DML" =No.

haben

Wenn Sie sich keine Ausfallzeit auf den Produktionsservern leisten können, wenn Sie eine Schemaänderung durchführen, ist es wahrscheinlich eine gute Idee, das Online-Schemaänderungstool in einem frühen Stadium zu konfigurieren. In diesem Beispiel installieren und konfigurieren wir gh-ost, eine von Github erstellte Online-Schemaänderung. Ghost verwendet den Binärlog-Stream, um Tabellenänderungen zu erfassen, und wendet sie asynchron auf die Ghost-Tabelle an.

Führen Sie einfach die folgenden Schritte aus, um gh-ost auf einer CentOS-Box zu installieren: 

Schritt Eins

 Laden Sie den neuesten Ghost von hier herunter: 

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Schritt Zwei

Paket installieren:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm

Schritt Drei

Erstellen Sie einen Datenbankbenutzer für gh-ost, wenn er nicht existiert, und gewähren Sie ihm die richtigen Berechtigungen:

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** Ersetzen Sie {host} und {db_name} durch die entsprechenden Werte. Idealerweise ist {host} einer der Slave-Hosts, der die Online-Schemaänderung durchführt. Einzelheiten finden Sie in der Ghost-Dokumentation.

Schritt Vier

Ghost-Konfigurationsdatei erstellen, um den Benutzernamen und das Passwort unter /root/.gh-ost.cnf zu speichern:

[client]
user=gh-ost
password=ghostP455

In ähnlicher Weise können Sie Percona Toolkit Online Schema Change (pt-osc) auf dem Datenbankserver konfigurieren lassen. Die Idee ist, sicherzustellen, dass Sie mit diesem Tool zuerst auf dem Datenbankserver vorbereitet sind, auf dem diese Operation wahrscheinlich in Zukunft ausgeführt wird.

Verwenden Sie das Percona-Toolkit

Das Percona Toolkit ist eine Sammlung fortschrittlicher Open-Source-Befehlszeilentools, die von Percona entwickelt wurden und für die Ausführung einer Vielzahl von MySQL-, MongoDB- und PostgreSQL-Server- und Systemaufgaben entwickelt wurden, die zu schwierig oder komplex sind manuell durchführen. Diese Tools sind zum ultimativen Retter geworden und werden von DBAs auf der ganzen Welt verwendet, um technische Probleme anzugehen oder zu lösen, die in MySQL- und MariaDB-Servern gefunden wurden.

Um Percona Toolkit zu installieren, führen Sie einfach den folgenden Befehl aus:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

In diesem Paket sind über 30 Tools verfügbar. Einige von ihnen sind speziell für MongoDB und PostgreSQL konzipiert. Einige der beliebtesten Tools für MySQL-Fehlerbehebung und Leistungsoptimierung sind pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync und pt-archiver. Dieses Toolkit kann DBAs helfen, die Integrität der MySQL-Replikation zu überprüfen, indem es die Konsistenz von Master- und Replikatdaten überprüft, Zeilen effizient archiviert, doppelte Indizes findet, MySQL-Abfragen aus Protokollen und tcpdump analysiert und vieles mehr.

Das folgende Beispiel zeigt die Ausgabe eines der Tools (pt-table-checksum), wo es eine Online-Konsistenzprüfung der Replikation durchführen kann, indem Prüfsummenabfragen auf dem Master ausgeführt werden, was zu unterschiedlichen Ergebnissen auf Replikaten führt, die nicht mit dem Master übereinstimmen:

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

Die obige Ausgabe zeigt, dass es 3 Tabellen auf dem Slave (mysql2.local) gibt, die nicht mit dem Master übereinstimmen. Wir können dann das pt-table-sync-Tool verwenden, um die fehlenden Daten vom Master auszubessern oder den Slave einfach noch einmal neu zu synchronisieren.

Server sperren

Schließlich, nachdem die Konfigurations- und Vorbereitungsphase abgeschlossen ist, können wir den Datenbankknoten vom öffentlichen Netzwerk isolieren und den Serverzugriff auf bekannte Hosts und Netzwerke beschränken. Sie können eine Firewall (iptables, firewalld, ufw), Sicherheitsgruppen, hosts.allow und/oder hosts.deny verwenden oder einfach die Netzwerkschnittstelle deaktivieren, die dem Internet zugewandt ist, wenn Sie mehrere Netzwerkschnittstellen haben.

Für iptables ist es wichtig, einen Kommentar für jede Regel mit dem Flag '-m comment --comment' anzugeben:

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

Ähnlich für die Firewall von Ubuntu (ufw) müssen wir zuerst die Standardregel definieren und können dann eine ähnliche Regel für MySQL/MariaDB ähnlich wie diese erstellen:

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

Firewall aktivieren:

$ ufw enable

Überprüfen Sie dann, ob die Regeln korrekt geladen wurden:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

Auch hier ist es sehr wichtig, Kommentare zu jeder Regel anzugeben, damit wir die Regel besser verstehen.

Für die Einschränkung des Remote-Datenbankzugriffs können wir auch einen VPN-Server verwenden, wie in diesem Blog-Beitrag „Using OpenVPN to Secure Access to Your Database Cluster in the Cloud“ gezeigt.

Fazit

Die Vorbereitung eines Produktionsservers ist offensichtlich keine leichte Aufgabe, was wir in dieser Blogserie gezeigt haben. Wenn Sie befürchten, dass Sie es vermasseln könnten, warum verwenden Sie dann nicht ClusterControl, um Ihren Datenbank-Cluster bereitzustellen? ClusterControl hat eine sehr gute Erfolgsbilanz bei der Datenbankbereitstellung und hat bis heute mehr als 70.000 MySQL- und MariaDB-Bereitstellungen für alle Umgebungen ermöglicht.