Wie eine Funktionsinkompatibilität das MySQL-Caching in Cloudflare Hyperdrive beeinträchtigte

Cloudflare hat die allgemeine Verfügbarkeit (General Availability) der MySQL-Unterstützung für Hyperdrive angekündigt, den Datenbankverbindungspooler für Workers. Die Veröffentlichung folgt auf eine Beta-Phase, in der Ingenieure einen subtilen Caching-Fehler identifizierten und behoben, der gelegentlich zu leeren Abfrageantworten führte. Diese Korrektur stellt sicher, dass der Dienst sein Verfügbarkeitsziel von 99,99 % für MySQL-Workloads erreicht.

Was passiert ist

Hyperdrive wurde zunächst mit Unterstützung für Postgres eingeführt, sodass serverlose Workers warme Datenbankverbindungen teilen und Abfrageergebnisse global cachen konnten. Als die MySQL-Unterstützung letztes Jahr in die Beta ging, zielte das Team darauf ab, die Zuverlässigkeit ihrer Postgres-Implementierung zu erreichen. Während dieser Testphase meldeten Kunden mit hohem Datenvolumen eine konsistente, aber seltene Fehlerrate, bei der Abfragen leere Ergebnisse statt der erwarteten Daten zurückgaben. Dieses Problem trat bei etwa 0,001 % der Anfragen auf, was es schwierig machte, es zu reproduzieren und nachzuverfolgen.

Die Untersuchung ergab, dass das Problem spezifisch für Hyperdrive-Instanzen mit aktiviertem Caching war. Ingenieure führten das Problem auf die Art zurück, wie Hyperdrive das MySQL-Client/Server-Protokoll behandelt, insbesondere im Hinblick auf die Aushandlung der Fähigkeiten (Capability Negotiation). Im Gegensatz zu Postgres verwendet MySQL Capability-Flags, um festzulegen, wie Ergebnisdatensätze formatiert und beendet werden. Eine Diskrepanz zwischen dem, was der Treiber des Workers erwartete, und dem, was Hyperdrive cachede, führte zu beschädigten oder unlesbaren Antworten, wenn Knoten einen Cache teilten.

Um die allgemeine Verfügbarkeit zu erreichen, implementierte das Team zwanzig Fehlerbehebungen, einschließlich Korrekturen für die Zeichensatzkodierung und das Verhalten beim Zurücksetzen von Verbindungen. Die wichtigste Korrektur betraf die Caching-Logik, um sicherzustellen, dass alle gespeicherten Abfrageergebnisse ein kanonisches Format verwenden. Mit diesen Änderungen verschwanden die Fehlermeldungen für leere Antworten, und der Dienst erreichte seine Zuverlässigkeitsziele.

Wie es funktioniert

Hyperdrive nutzt eine Split-Architektur, die aus einem Client-Knoten und einem Endpoint-Knoten besteht. Der Client läuft in der Nähe des Workers, bearbeitet lokale Anfragen und führt das Caching durch, während der Endpoint näher an der Ursprungsdatenbank sitzt und den Verbindungspool verwaltet. Beide Knoten nutzen den lokalen Cloudflare-CDN-Cache. Wenn sich Client und Endpoint im selben Rechenzentrum befinden, teilen sie diesen Cache, um die Leistung zu verbessern, indem wiederholte Abfragen bedient werden, ohne die Datenbank zu kontaktieren.

Das MySQL-Protokoll verlässt sich auf die Aushandlung von Fähigkeiten während der Verbindungsphase. Eine wichtige Fähigkeit ist CLIENT_DEPRECATE_EOF, die ändert, wie Ergebnisdatensätze beendet werden. Moderne Server lassen ein EOF-Paket nach Spaltendefinitionen weg und ersetzen das letzte EOF durch ein OK-Paket, wenn diese Fähigkeit ausgehandelt wird. Einige Client-Bibliotheken, wie mysql2 für Node.js, unterstützen dieses Flag jedoch nicht. Hyperdrive muss Antworten zwischen dem Format des Ursprungsservers und dem vom Worker erwarteten Format übersetzen.

Der Fehler entstand, weil die Caching-Schicht davon ausging, dass sie die exakten Bytes speichern könnte, die an den Worker gesendet wurden. Wenn der Endpoint eine Antwort unter Verwendung der internen Fähigkeiten von Hyperdrive cachede, der Client diese abrufte und die Rohbytes an einen Worker sendete, der ein anderes Format erwartete, würde der Worker die Daten falsch interpretieren. Umgekehrt konnte es passieren, dass der Client übersetzte Bytes cachede, der Endpoint diese abrufte und sie nicht korrekt verarbeiten konnte. Die Korrektur stellt sicher, dass nur eine kanonische Version der Antwort, kodiert mit den Fähigkeiten von Hyperdrive, jemals in den gemeinsamen Cache geschrieben wird.

Wichtige Details

• Hyperdrive für MySQL ist nun allgemein verfügbar und hat die Beta-Phase verlassen.
• Der Dienst zielt auf eine Verfügbarkeit von 99,99 % für Client-Verbindungen von Workers ab.
• Ein seltener Fehler führte dazu, dass 0,001 % der gecachten Abfragen leere Ergebnisse zurückgaben oder hingen.
• Das Problem resultierte aus einer inkonsistenten Behandlung der CLIENT_DEPRECATE_EOF-Fähigkeit.
• Die Behebung des Fehlers erforderte die Sicherstellung einer kanonischen Byte-Kodierung im gemeinsamen CDN-Cache.
• Zusätzliche Korrekturen behandelten die utf8mb4-Kodierung und Zustandsrücksetzungen bei COM_RESET_CONNECTION.

Warum das wichtig ist

Für Entwickler, die auf serverlosen Plattformen bauen, ist das Management von Datenbankverbindungen eine dauerhafte Herausforderung. Das Herstellen neuer Verbindungen für jede Anfrage erhöht die Latenz erheblich und verbraucht Ressourcen. Verbindungspooler wie Hyperdrive mildern dies, indem sie Verbindungen warm halten, führen jedoch Komplexität in der Protokollübersetzung ein. Das Verständnis, wie diese Tools Wire-Protokolle behandeln, hilft Ingenieuren dabei, obskure Probleme zu debuggen, die auftreten, wenn verschiedene Client-Bibliotheken und Datenbankversionen gemischt werden.

Dieser Vorfall verdeutlicht die Risiken, die entstehen, wenn man von einer Protokolluniformität über verschiedene Datenbanksysteme hinweg ausgeht. Obwohl sowohl Postgres als auch MySQL SQL verwenden, unterscheiden sich ihre zugrunde liegenden Netzwerkprotokolle erheblich. Ingenieure, die Multi-Protokoll-Infrastrukturen integrieren, müssen sich bewusst sein, dass Caching-Schichten Datenformate möglicherweise normalisieren müssen, um Desynchronisationen zu verhindern. Das Ignorieren dieser Nuancen kann zu intermittierenden Ausfällen führen, die in lokalen Entwicklungsumgebungen schwer zu reproduzieren sind.

Darüber hinaus erfordert die Abhängigkeit von gemeinsamen Caches in verteilten Systemen strenge Konsistenzgarantien. Wenn mehrere Komponenten denselben Cache lesen und beschreiben, müssen sie sich auf das Datenschema einigen. In diesem Fall führte das Fehlen eines kanonischen Formats dazu, dass der Cache zu einer Quelle der Beschädigung wurde, anstatt die Leistung zu steigern. Diese Lektion gilt breit für jedes System, das intermediäres Caching zur Protokollübersetzung nutzt.

Was Sie tun können

• Aktualisieren Sie auf die allgemein verfügbare Version von Hyperdrive für MySQL, um von den Stabilitätskorrekturen zu profitieren.
• Stellen Sie sicher, dass Ihre MySQL-Client-Bibliothek utf8mb4 unterstützt, um Zeichenkodierungsprobleme mit Emojis oder Sonderzeichen zu vermeiden.
• Prüfen Sie, ob Ihr Client-Treiber CLIENT_DEPRECATE_EOF unterstützt, um zu verstehen, wie Ergebnisdatensätze in Ihrer Anwendung beendet werden.
• Überwachen Sie Ihre Anwendung auf intermittierende leere Abfrageergebnisse, wenn Sie einen benutzerdefinierten oder älteren MySQL-Treiber verwenden.
• Verwenden Sie die wrangler-CLI, um neue Hyperdrive-Instanzen für MySQL-kompatible Datenbanken wie PlanetScale zu erstellen.
• Überprüfen Sie Ihre Logik zum Zurücksetzen von Verbindungen, um sicherzustellen, dass der Sitzungszustand in gepoolten Umgebungen nicht zwischen Anfragen durchsickert.