Die größten Online-Shopping-Tage des Jahres stehen vor der Tür. Ist Ihre Datenbank bereit? Indem Sie 20 wichtige MariaDB-Systemvariablen optimieren, steigern Sie die Leistung Ihrer Datenbank , Skalierbarkeit und Verfügbarkeit , um sicherzustellen, dass jeder potenzielle Kunde eine reibungslose Benutzererfahrung hat. Die folgenden Systemvariablen tauchen wiederholt bei der Konfiguration einer optimalen MariaDB-Serverumgebung auf. Setzen Sie unsere Empfehlungen für die besten Werte um und machen Sie den diesjährigen Zeitraum zwischen Black Friday und Cyber Monday zu Ihrem besten aller Zeiten.
Ein paar wichtige Hinweise:
- Akzeptieren Sie diese Vorschläge nicht blind. Jede MariaDB-Umgebung ist einzigartig und erfordert zusätzliche Überlegungen, bevor Sie Änderungen vornehmen. Sie müssen diese Einstellungen höchstwahrscheinlich für Ihren speziellen Anwendungsfall und Ihre Umgebung anpassen.
- MariaDB-Konfigurationsdatei befindet sich in /etc/my.cnf. Jedes Mal, wenn Sie diese Datei ändern, müssen Sie den MySQL-Dienst neu starten, damit die neuen Änderungen wirksam werden.
20 Tuning-Empfehlungen für Black Friday und Cyber Monday
1. Größe des InnoDB-Pufferpools
Die Größe des InnoDB-Pufferpools dies ist die wichtigste Einstellung, die Sie bei jeder Installation mit InnoDB beachten sollten. Im Pufferpool werden Daten und Indizes zwischengespeichert; Wenn Sie es so groß wie möglich halten, verwenden Sie für die meisten Lesevorgänge Arbeitsspeicher und nicht Festplatten.
2. Größe der InnoDB-Protokolldatei
innodb_log-file-size ist die Größe der Redo-Protokolle, die verwendet werden, um sicherzustellen, dass Schreibvorgänge schnell und dauerhaft sind. Es gibt zwei allgemeine Vorschläge für die Größe von InnoDB-Protokolldateien:
- Setzen Sie die kombinierte Gesamtgröße der InnoDB-Protokolldateien auf mehr als 25–50 % der Größe des InnoDB-Pufferpools
oder
- Stellen Sie die kombinierte Protokollgröße der InnoDB-Protokolldatei auf die Protokolleinträge einer Stunde während der Spitzenlast ein
Größere Protokolldateien können bei einem Serverabsturz zu einer langsameren Wiederherstellung führen. Sie verringern jedoch auch die Anzahl der erforderlichen Prüfpunkte und die Festplatten-E/A.
Bewerten Sie die Größe der Binärprotokolle einer Stunde unter Betriebslast und entscheiden Sie dann, ob Sie die Größe der InnoDB-Protokolldateien erhöhen möchten.
Die richtige Größe der innodb-Protokolldateien ist wichtig, um eine gute Systemleistung zu erzielen. Die InnoDB-Speicher-Engine von MariaDB verwendet einen (zirkulären) Redo-Log-Speicherplatz mit fester Größe. Die Größe wird durch innodb_log_file_size und innodb_log_files_in_group (Standard 2) gesteuert. Multiplizieren Sie diese Werte, um den Redo-Log-Speicherplatz zu erhalten, der zur Verwendung verfügbar ist. Während es technisch gesehen keine Rolle spielen sollte, ob Sie die Variable innodb_log_file_size oder innodb_log_files_in_group verwenden, um die Redo-Space-Größe zu steuern, arbeiten die meisten Leute einfach mit der innodb_log_file_size und lassen innodb_log_files_in_group in Ruhe.
Die Redo-Space-Größe von InnoDB ist eine der wichtigsten Konfigurationsoptionen für schreibintensive Workloads. Es kommt jedoch mit Kompromissen. Je mehr Redo Space konfiguriert ist, desto besser kann InnoDB die Schreib-I/O optimieren. Das Erhöhen des Redo-Speicherplatzes bedeutet jedoch auch längere Wiederherstellungszeiten, wenn das System die Stromversorgung verliert oder aus anderen Gründen abstürzt.
3. Größe des InnoDB-Protokollpuffers
Eine größere InnoDB-Protokollpuffergröße bedeutet weniger Platten-I/O für größere Transaktionen. Es wird empfohlen, dies auf allen Servern auf 64 MB einzustellen.
4. InnoDB Log Flush-Intervall
Die Variable innodb_flush_log_at_trx_commit steuert, wann der Protokollpuffer auf die Festplatte geleert wird. innodb_flush_log_at_trx_commit =1 (Standard) leert den Protokollpuffer bei jedem Transaktions-Commit auf die Festplatte. Dies ist die sicherste, aber auch die leistungsschwächste Option.
innodb_flush_log_at_trx_commit =0 leert den Protokollpuffer jede Sekunde auf die Festplatte, aber nichts bei Transaktionscommit. Bis zu einer Sekunde (möglicherweise mehr aufgrund der Prozessplanung) könnte verloren gehen. Bei einem Absturz können MySQL oder der Server Daten verlieren. Dies ist die schnellste, aber am wenigsten sichere Option.
innodb_flush_log_at_trx_commit =2 schreibt den Protokollpuffer bei jedem Commit in eine Datei, aber er wird jede Sekunde auf die Festplatte geleert. Wenn der Festplatten-Cache über eine Batteriesicherung verfügt (z. B. einen batteriegestützten Cache-Raid-Controller), ist dies im Allgemeinen das beste Gleichgewicht zwischen Leistung und Sicherheit. Ein Absturz von MySQL sollte keine Daten verlieren. Durch einen Serverabsturz oder Stromausfall kann bis zu einer Sekunde verloren gehen (möglicherweise mehr aufgrund der Prozessplanung). Ein batteriegepufferter Cache reduziert diese Möglichkeit.
Wir empfehlen aus Sicherheitsgründen die erste Option.
5. InnoDB-IO-Kapazität
innodb_io_capacity sollte ungefähr auf die maximale Anzahl von IOPS eingestellt werden, die der zugrunde liegende Speicher verarbeiten kann.
Standardmäßig ist dieser Wert auf 1000 eingestellt. Wir empfehlen, den Speicher einem Benchmarking zu unterziehen, um festzustellen, ob Sie diesen Wert weiter erhöhen können.
6. Thread-Cache-Größe
Überwachen Sie den Wert von Threads_created. Wenn es weiterhin mit mehr als ein paar Threads pro Minute zunimmt, erhöhen Sie den Wert von thread_cache_size.
Die Thread-Cache-Größe ist in der aktuellen Standardkonfiguration auf 200 eingestellt.
7. Tabellen-Cache und Tabellendefinitions-Cache
Die Variablen table_open_cache und table_defintion_cache steuern die Anzahl der Tabellen und Definitionen, die für alle Threads geöffnet bleiben sollen.
Überwachen Sie Open_tables, Open_table_definitions, Opened_tables und Opened_table_definitions, um den besten Wert zu ermitteln. Der allgemeine Vorschlag lautet, table_open_cache (und anschließend table_definition_cache) nur hoch genug festzulegen, um die Anstiegsrate des Statuswerts "Opened_tables" (und "Opened_table_definitions") zu verringern.
Sowohl table_open_cache als auch table_defintion_cache sind in der Standardkonfiguration auf 2048 gesetzt.
8. Abfrage-Cache
Der Abfrage-Cache ist ein bekannter Engpass, der auch bei mäßiger Parallelität zu erkennen ist. Die beste Option ist, es vom ersten Tag an zu deaktivieren, indem Sie query_cache_size =0 (die Standardeinstellung in MariaDB 10) festlegen und andere Möglichkeiten verwenden, um Leseabfragen zu beschleunigen:eine gute Indizierung, das Hinzufügen von Replikaten zum Verteilen der Leselast oder die Verwendung eines externen Caches ( memcache oder redis). Wenn Sie Ihre MariaDB-Anwendung bereits mit aktiviertem Abfrage-Cache erstellt haben und nie ein Problem bemerkt haben, kann der Abfrage-Cache für Sie von Vorteil sein. Seien Sie in diesem Fall vorsichtig, wenn Sie sich entscheiden, es zu deaktivieren.
9. Temporäre Tabellen, tmp_table_size und max_heap_table_size
MySQL verwendet den niedrigeren Wert von max_heap_table_size und tmp_table_size, um die Größe temporärer Tabellen im Speicher zu begrenzen. Dies sind Client-Variablen. Ein großer Wert kann zwar dazu beitragen, die Anzahl der auf der Festplatte erstellten temporären Tabellen zu reduzieren, erhöht aber auch das Risiko, dass die Speicherkapazität des Servers erreicht wird, da dies pro Client gilt. Im Allgemeinen sind 32 Millionen bis 64 Millionen der empfohlene Wert, mit dem Sie für beide Variablen beginnen und nach Bedarf abstimmen können.
Temporäre Tabellen werden oft für GROUP BY, ORDER BY, DISTINCT, UNION, Unterabfragen usw. verwendet. Idealerweise sollte MySQL diese im Arbeitsspeicher erstellen, mit so wenig wie möglich auf der Festplatte.
Es ist wichtig zu beachten, dass Abfragen, die Joins nicht angemessen verwenden, und das Erstellen großer temporärer Tabellen ein Grund für eine höhere Anzahl temporärer Tabellen auf der Festplatte sein können. Ein weiterer Grund ist, dass die Arbeitsspeicher-Engine Spalten mit fester Länge verwendet und vom Worst-Case-Szenario ausgeht. Wenn Spalten nicht die richtige Größe haben (z. B. VARCHAR(255) für eine kurze Zeichenfolge), wirkt sich dies auf die Größe der Tabelle im Arbeitsspeicher aus und kann dazu führen, dass sie früher als vorgesehen auf die Festplatte verschoben wird. Außerdem werden temporäre Tabellen mit Blob- und Textspalten sofort auf die Festplatte verschoben, da die Speicher-Engine sie nicht unterstützt.
Beide sind derzeit standardmäßig auf 64 MB eingestellt.
10. Warnprotokollebene
Wir empfehlen, die Warnprotokollebene auf log_warnings =2 zu setzen. Dadurch werden Informationen über abgebrochene Verbindungen und Zugriffsverweigerungsfehler protokolliert.
11. Max. Verbindungen
Wenn Sie häufig mit dem Fehler „Zu viele Verbindungen“ konfrontiert werden, ist max_connections zu niedrig. Da die Anwendung Verbindungen zur Datenbank nicht korrekt schließt, benötigen Sie häufig viel mehr als die standardmäßigen 151 Verbindungen. Der Hauptnachteil hoher Werte für max_connections (z. B. 1.000 oder mehr) besteht darin, dass der Server nicht mehr reagiert, wenn er so viele aktive Transaktionen ausführen muss. Die Verwendung eines Verbindungspools auf Anwendungsebene oder eines Threadpools auf MariaDB-Ebene kann hier Abhilfe schaffen.
12. Transaktionsisolierung
Untersuchen Sie die verfügbaren Transaktionsisolationsstufen und ermitteln Sie die beste Transaktionsisolation für den Anwendungsfall Ihres Servers.
13. Binäres Protokollformat
Wir empfehlen die Verwendung des ROW-Binärprotokollformats für die Master-Master-Replikation.
14. Auto-Increment-Offsets
Um die Wahrscheinlichkeit einer Kollision zwischen zwei Mastern, auf die gleichzeitig geschrieben wird, zu verringern, müssen die Werte für die automatische Inkrementierung und den Offset für die automatische Inkrementierung entsprechend angepasst werden.
15. Binlog synchronisieren
Standardmäßig übernimmt das Betriebssystem das Leeren des Binlog auf die Festplatte. Im Falle eines Serverabsturzes können Transaktionen aus dem Binärlog verloren gehen, was dazu führt, dass die Replikation nicht synchron ist. Das Setzen von sync_binlog =1 bewirkt, dass die binlog-Datei bei jedem Commit geleert wird.
Das ist langsamer, aber die sicherste Option.
16. Crash Safe(r) Slaves
Um Replikationsfehler nach einem Slave-Absturz zu vermeiden, aktivieren Sie die Wiederherstellung des Relaisprotokolls und die Synchronisierung des Relaisprotokolls und der Informationsdateien des Relaisprotokolls auf der Festplatte.
17. Slave-Updates protokollieren
Für eine verkettete Replikation (Master -> Slave -> Slave) muss log_slave_updates aktiviert sein. Dies weist einen Slave an, replizierte Transaktionen in sein eigenes Binärlog zu schreiben, damit sie dann an Slaves davon repliziert werden können.
18. Nur-Lese-Slaves
Slaves sollten schreibgeschützt sein, um zu vermeiden, dass Daten versehentlich auf sie geschrieben werden.
Hinweis :Benutzer mit Super-Privilegien können immer noch schreiben, wenn der Server schreibgeschützt ist.
19. Slave-Netzzeitüberschreitung
Die Variable slave_net_timeout ist die Anzahl der Sekunden, die der Slave auf ein Paket vom Master wartet, bevor er versucht, sich wieder zu verbinden. Der Standardwert ist 3600 (1 Stunde). Das bedeutet, wenn die Verbindung unterbrochen und nicht erkannt wird, kann es bis zu einer Stunde dauern, bis der Slave die Verbindung wieder herstellt. Dies könnte dazu führen, dass der Slave plötzlich bis zu einer Stunde hinter dem Master zurückbleibt.
Wir empfehlen, slave_net_timeout auf einen sinnvolleren Wert zu setzen, z. B. 30 oder 60.
20. Sehen Sie sich unser Webinar zur Vorbereitung auf Black Friday und Cyber Monday an
Sehen Sie sich unser On-Demand-Webinar – Vorbereitung auf Black Friday und Cyber Monday – an, um die vier grundlegenden Prinzipien der Datenbankvorbereitung kennenzulernen: Sicherheitsmaßnahmen um Ihre Datenbank vor böswilligen Angriffen zu schützen, Leistungsoptimierung um sicherzustellen, dass Sie eine reibungslose Benutzererfahrung bieten, Strategien für hohe Verfügbarkeit um sicherzustellen, dass Sie keinen einzigen Verkauf und Skalierbarkeit verpassen um sich sowohl auf erwartetes Wachstum als auch auf unerwartete Spitzen vorzubereiten.
