Detaillierte Erklärung der MySQL5.6-Grundkonfiguration

In diesem Artikel wird hauptsächlich die grundlegende Optimierungskonfiguration von MySQL5.6 vorgestellt, die Konfigurationselemente, die in MySQL5.6 optimiert werden müssen, detailliert beschrieben und schließlich ein Optimierungsfall vorgestellt.

Folgen: Mit einer Vielzahl von Verbesserungen an den Standardoptionen erfordert MySQL 5.6 deutlich weniger Optimierungsoptionen als frühere Versionen. In diesem Artikel beschreibe ich die Konfigurationselemente, die optimiert werden müssen.

InnoDB-Einstellungen

1.innodb_buffer_pool_size – Der Standardwert ist 128M, da er angibt, wie viel Speicher InnoDB zum Laden verwendet Daten und Indizes (Daten+Indizes) wird empfohlen, den Bereich von 50-80 % des physischen Speichers anzugeben. Bei einer Maschine mit 64 GB physischem Speicher sollte der Cache-Pool beispielsweise angegeben werden Wenn dieser Wert festgelegt ist, bestehen möglicherweise größere Risiken, z. B. dass nicht genügend freier Speicher für das Betriebssystem und bestimmte MySQL-Subsysteme (Subsysteme) übrig ist, die auf dem
Dateisystem basieren Cache, einschließlich Binärprotokolle, InnoDB-Transaktionsprotokolle (TransAktionsprotokolle) usw.

2.innodb_log_file_size

– Der Standardwert ist 48 MB. Systeme mit hohem Schreibdurchsatz Dieser Wert muss erhöht werden, um eine Hintergrundaktivität zu ermöglichen. Die Checkpoint-Aktivität verbessert die Leistung, indem Schreibvorgänge über einen längeren Zeitraum hinweg geglättet werden. Es ist sicher, diesen Wert unter 4G festzulegen. Die Praxis hat gezeigt, dass große Protokolldateien von Nachteil sind Die Reparaturzeit bei einem Absturz ist erhöht, dies wurde jedoch in 5.5 und 5.6 erheblich verbessert.

3.innodb_flush_method

- Bei Verwendung von Hardware-RAID-FestplattenController , muss möglicherweise auf O_DIRECT eingestellt werden. Dies verhindert den „doppelten Puffer“-Effekt beim Lesen aus dem InnoDB-Pufferpool, der andernfalls 2 Kopien zwischen dem Dateisystem-Cache und dem InnoDB-Cache erstellen würde wird nicht verwendet, oder bei Verwendung von SAN-Speicher kann O_DIRECT zu Leistungseinbußen führen. Das MySQL-Benutzerhandbuch und Bug #54306 erläutern dies ausführlich.
4.innodb_flush_neighbors

– Standard ist 1. Sollte auf SSD-Speicher auf 0 (deaktiviert) gesetzt werden, da es keinen Leistungsgewinn durch die Verwendung sequenzieller E/A gibt. Diese Einstellung sollte auch auf mancher Hardware, die RAID verwendet, deaktiviert werden, da logisch zusammenhängende Blöcke nicht garantiert zusammenhängend auf der physischen Festplatte sind.

5.innodb_io_capacity und innodb_io_capacity_max

– Diese Einstellungen wirken sich darauf aus, wie viele Vorgänge InnoDB pro Sekunde im Hintergrund ausführt. Wenn Sie ein tiefes Verständnis der Hardwareleistung haben (z. B. wie viele E/A-Vorgänge pro Sekunde ausgeführt werden können). Zweitens) ist es äußerst wünschenswert, diese Funktionen zu nutzen, anstatt sie ungenutzt zu lassen.

Es gibt ein gutes Analogiebeispiel: Wenn für einen bestimmten Flug kein einziges Ticket verkauft wurde – also kann es sein, dass ein Eine gute Strategie ist es, einige Leute auf späteren Flügen diesen Flug nehmen zu lassen, falls es später schlechtes Wetter gibt. Das heißt, wenn es eine Gelegenheit gibt, wird der Hintergrundbetrieb nebenbei abgewickelt, um die Konkurrenz zu möglichen Echtzeitoperationen zu reduzieren später.

Es gibt eine sehr einfache Rechnung: Wenn jede Festplatte 200 Mal pro Sekunde (IOPS) lesen und schreiben kann, dann ist ein RAID10-Festplattenarray mit 10 Festplatten IOPS theoretisch = (10/2) * 200 = 1000 . Ich sage, es ist „sehr einfach“, weil RAID-Controller normalerweise in der Lage sind, zusätzliche Zusammenführung zu ermöglichen und die IOPS-Fähigkeiten effektiv zu erhöhen. Bei SSD-Festplatten können IOPS leicht mehrere Tausend erreichen.

Diese Einstellung kann einige Risiken bergen Zwei Werte zu groß. Sie möchten auf keinen Fall, dass Hintergrundoperationen die Leistung von E/A-Vorgängen im Vordergrund beeinträchtigen führt zu Leistungseinbußen (nach den Informationen, die ich erfahren habe, wurde dies in MySQL5.6 erheblich verbessert).


innodb_lru_scan_ Depth

– Der Standardwert ist 1024. Dies ist eine neue Option, die in eingeführt wurde MySQL 5.6. Mark Callaghan hat einige Konfigurationsvorschläge gemacht: Wenn Sie den innodb_io_capacity-Wert erhöhen, sollten Sie auch innodb_lru_scan_ Depth erhöhen.

Replikation

Wenn die Der Server möchte die Master-Slave-Replikation oder Point-in-Time-Wiederherstellung unterstützen. In diesem Fall benötigen wir:

1.log -bin

– Binäre Protokollierung ist nicht aktiviert Standardmäßig absturzsicher, aber wie in meinem vorherigen Artikel gesagt, empfehle ich den meisten Benutzern, auf Stabilität zu achten. In diesem Fall müssen Sie außerdem Folgendes aktivieren: sync_binlog=1, sync_relay_log=1, Relay-log-info-repository=TABLE und master-info-repository=TABLE.

2.expire-logs-days

– Ich empfehle die Einstellung auf 1-10 Tage Es nützt nicht viel, es länger zu speichern, da die Wiederherstellung aus dem Backup viel schneller geht.

3.server-id

– Alle Server in einem Master-Slave-Replikationssystem (Replikationstopologie) müssen es sein mit einer eindeutigen Server-ID festgelegt.

4.binlog_format=ROW – geändert zur zeilenbasierten Replikation. Ich habe kürzlich eine weitere zeilenbasierte Replikation geschrieben, die beschreibt, warum sie mir wirklich gefällt, weil sie die Leistung durch Reduzierung der Ressourcensperre verbessert Zusätzliche Einstellungen müssen ebenfalls aktiviert werden: transaction-isolation=READ-COMMITTED und innodb_autoinc_lock_mode = 2.

Andere Konfigurationen (Verschiedenes)

1. timezone=GMT Stellen Sie die ein Immer mehr Systemadministratoren empfehlen, alle Server auf die Greenwich-Zeit (GMT) einzustellen, da die Einstellung auf die lokale Zeitzone mittlerweile für fast alle Unternehmen etwas willkürlich erscheint 🎜>

2.character-set-server=utf8mb4 und collation-server=utf8mb4_general_ci Wie im vorherigen Artikel erwähnt, ist die utf8-Kodierung eine bessere Standardoption für neue Anwendungen. Sie können auch Skip- festlegen. Zeichensatz-Client-Handshake, um andere Zeichensätze zu ignorieren, die die Anwendung festlegen möchte 3.sql-mode

– MySQL ist standardmäßig sehr tolerant gegenüber nicht standardmäßigen Daten wird die Daten stillschweigend abschneiden. In einem meiner vorherigen Artikel habe ich erwähnt, dass die neue Anwendung am besten auf Folgendes eingestellt ist:

4.skip-name-resolve

STRICT_TRANS_TABLES,ERROR_FOR_pISION_BY_ZERO,
 NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,
 NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,
 NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY.

– deaktivieren Die umgekehrte Domänennamenauflösung kann auf einigen Systemen etwas langsam/instabil sein. Wenn also keine Hostnamen-basierte Autorisierung erforderlich ist, empfehle ich, diese Analyse zu vermeiden

5.max_connect_errors

- Todd Farmer schrieb: „[Diese Funktion] bietet einen strittigen Schutz vor Brute-Force-Zugriffsangriffen.“ Tatsächlich funktioniert max_connect_errors nicht einmal (siehe vorheriger Absatz). ist eine geeignetere Lösung, normalerweise blockiere ich Port 3306. Unabhängig davon, ob es sich um einen öffentlichen oder privaten Port handelt, können nur bestimmte Anwendungen auf MySQL zugreifen und eine Verbindung zu MySQL herstellen.

Normalerweise setze ich max_connect_errors=100000, damit ich ein „Doppel“ vermeiden kann Konfiguration“ und stellen Sie sicher, dass es nicht im Weg ist.

6.max-connections

– Der Standardwert ist 151. Ich habe viele Benutzer gesehen, die ihn auf einen größeren Wert eingestellt haben. meist zwischen 300 und 1000.
ist normalerweise unvermeidlich. Dieser Wert würde höher eingestellt werden, aber was mich etwas nervös macht, ist, dass die 16-Kern-Maschine im Falle einer E/A-Blockierung nur über etwa 2x~10x Verbindungsausführungskapazität verfügt 🎜> Sie können hoffen, dass viele offene Verbindungen alle inaktiv und ruhend sind. Wenn sie jedoch alle aktiv sind, kann eine große Anzahl neuer Threads (Thread-Thrash) erstellt werden.

Wenn die Bedingungen dies zulassen, können Sie sie konfigurieren und optimieren Der Datenbankverbindungspool (Verbindungspools) für die Anwendung Um dieses Problem zu lösen, werden Anwendungen, die kein Verbindungspooling (nicht gepoolt) verwenden, schnell geöffnet, anstatt eine große Anzahl von Verbindungen zu öffnen und aufrechtzuerhalten. und das Schließen von Verbindungen nach der Ausführung von Aufgaben ist ebenfalls möglich

Eine andere Lösung ab 5.5 (mit einigen Unterschieden zwischen MySQL Community Edition und Enterprise Edition) ist die Verwendung des Thread-Pool-Plugins.
Fazit


Angenommen, die Konfiguration des MySQL-Servers ist:
1,64 GB physischer Speicher

2. (Angenommen, IO kann 2000 IOPS pro Sekunde erreichen)

3 . Erfordert Master-Slave-Replikation (Replikation) 4 . Neue Anwendungen (z. B. Nicht-Legacy-Systeme) 5. Firewall-Schutz

6. Es ist keine Autorisierung basierend auf Domänennamen (Hostnamen, Hostnamen) erforderlich

7. Globale Anwendungen möchten nicht an einem bestimmten Ort fixiert werden. Eine Zeitzone.
8. Wenn Sie möchten, dass das Programm zuverlässig und stabil (langlebig) ist.

Die Konfiguration kann sein wie folgt:

Das obige ist der detaillierte Inhalt vonDetaillierte Erklärung der MySQL5.6-Grundkonfiguration. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!