Best Practices für nichtflüchtige 16-KB-Speicher und MySQL

In diesem Dokument wird beschrieben, wie der nichtflüchtige Speicher mit einer physischen Blockgröße von 16 KB zur Leistungsverbesserung einer MySQL-Datenbank verwendet wird.

Schreiblastige MySQL-Arbeitslasten profitieren in der Regel von der Deaktivierung des InnoDB doublewrite-Zwischenspeichers. InnoDB von MySQL führt während des Dirty Page Flush-Prozesses ein Doublewrite durch, damit möglicherweise abgerissene Seiten wiederhergestellt werden können.

Ist jedoch ein durchgängiger 16-KB-Atomschreibpfad vorhanden, um sicherzustellen, dass eine 16-KB-Datenseite nicht teilweise auf das Laufwerk festgeschrieben oder zerrissen wird, müssen keine Doublewrites ausgeführt werden. Wenn Doublewrite deaktiviert ist, wird die Dirty Page Flush-Funktion der Datenbank verdoppelt und verringert so die Häufigkeit, in der die Datenbank in einen Sync Flush Zustand gerät. Dies ermöglicht eine stabilere und verbesserte Leistung.

Vorbereitung

16-KB-Atomschreibpfad von der Datenbank zum Blockgerät erstellen

Sie können einen durchgängigen 16-KB-Atomschreibpfad von der Datenbank zum Blockgerät erstellen, wenn Sie einen nichtflüchtigen 16-KB-Speicher verwenden. Dadurch kann die Doublewrite-Funktion in MySQL/InnoDB sicher deaktiviert und eine stabilere und bessere Leistung für hohe Schreiblasten gewährleistet werden.

Für das Erstellen und Anhängen eines nichtflüchtigen Speichers können Sie die Google Cloud Console, das gcloud-Tool oder die API verwenden.

  1. Erstellen Sie einen nichtflüchtigen Speicher mit einer Blockgröße von 16 KB und hängen Sie ihn an Ihre VM an. Der nichtflüchtige 16-KB-Speicher bietet 16-KB-Schreibatomarität auf physischer Blockebene.

    Wir empfehlen Ihnen, Ihre MySQL-Instanz so zu konfigurieren, dass Datendateien ausschließlich auf dem nichtflüchtigen 16-KB-Speicher gespeichert werden. Speichern Sie Logdateien, insbesondere Redo-Logs und Bin-Logs, auf einem nichtflüchtigen 4-KB-Speicher, der mit derselben VM verbunden ist. Dadurch wird sichergestellt, dass Logdateischreibvorgänge weiterhin mit hoher Leistung arbeiten, da kleine Logschreibvorgänge auf einem nichtflüchtigen 16-KB-Speicher möglicherweise viele Lese-Änderungs-Schreibvorgänge auslösen, die langsamer sind.

  2. Formatieren Sie das 16-KB-Laufwerk mithilfe des Dateisystems ext4 und der BigAlloc-Option und legen Sie die Clustergröße auf 16 KB fest. Hier ist ein Beispiel für einen mkfs-Befehl mit der angegebenen BigAlloc-Option:

    mkfs.ext4 -O bigalloc -C 16384 [...other options…]
    

    Durch die Verwendung von BigAlloc mit einer Clustergröße von 16 KB wird sichergestellt, dass das Dateisystem Dateien zuordnet, die mit der 16-KB-Grenze des Laufwerks übereinstimmen.

  3. Wählen Sie beim Erstellen der VM-Instanz ein Betriebssystem-Image aus den Google Container-optimierten Betriebssystem-Image-Familien im cos-cloud-Projekt aus.

    Verwenden Sie den Befehl gcloud, um eine Liste aller verfügbaren cos-Images anzuzeigen:

    gcloud compute images list --project cos-cloud --no-standard-images
    

    Wählen Sie Version 67 oder höher. Wählen Sie für bessere Ergebnisse ein Image aus der cos-stable-Familie.

    Durch die Auswahl eines cos-Images wird sichergestellt, dass Schreibvorgänge nicht durch Layer zwischen dem Dateisystem und der physischen Blockeinheitsebene über die 16-KB-Grenze verteilt werden. Der cos-Image-Qualifizierungsprozess verfügt über integrierte Tests, um dieses Ergebnis sicherzustellen.

  4. Prüfen Sie, ob max_segments und max_sectors_kb ordnungsgemäß im Betriebssystem konfiguriert sind:

    max_segments >= max_sectors_kb/4
    

    Diese beiden Variablen sind bereits in allen VMs der Google Compute Engine konfiguriert. Wenn Sie kein Skript haben, das diese beiden Variablen nach der VM-Erstellung ändert, müssen Sie hier nichts tun.

    Sie können diese beiden Konstanten im Betriebssystem unter diesem Pfad abfragen:

    /sys/block/sd<drive letter>/queue/
    
  5. Konfigurieren Sie noop oder none als E/A-Planer für den nichtflüchtigen 16-KB-Speicher.

    echo "none" > /sys/block/sd<drive_letter>/queue/scheduler
    
  6. Deaktivieren Sie das Zusammenführen von E/A-Anfragen im Kernel für den nichtflüchtigen 16-KB-Speicher.

    echo 2 > /sys/block/sd<drive_letter>/queue/nomerges
    
  7. Konfigurieren Sie InnoDB für die Verwendung von O_DIRECT. Legen Sie O_DIRECT auf die Datenbankkonfiguration innodb_flush_method fest oder fügen Sie sie hinzu.

Jetzt können Sie die innodb_doublewrite-Option sicher ausschalten.

Diese Methode ist nicht der einzige Ansatz, mit dem Sie durchgängige atomare 16-KB-Schreibvorgänge mit einem 16-KB-Blockgerät sicherstellen können. Wenn Sie beispielsweise Ihre Datenbank so konfigurieren, dass das Blockgerät direkt als unformatiertes Gerät verwendet wird, ohne ein Dateisystem zu verwenden, können Sie die obigen Schritte zur Konfiguration des Dateisystems überspringen.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation