Open-source database 26.7 startet calendar versioning
the open-source database 26.7 markiert eine bedeutende Änderung für Teams, die die von vielen Webanwendungen in der Produktion genutzte relationale Datenbank betreiben: Die Datenbank ist von der vertrauten Nummerierungslinie 8.x und 9.x zu einem kalenderbasierten Release-Schema gewechselt. Percona berichtet, dass der Anbieter das neue Innovation release als 26.7.0 statt als 9.8 ausgeliefert hat und dabei ein Year.Month.Patch-Muster verwendet, das das Release-Datum in der Versionsnummer selbst sichtbar macht.
Die Änderung folgt auf mehrere frühere Phasen in der Versionierung des Datenbankservers. Version 8.0, die von 2018 bis 2026 genutzt wurde, folgte einem traditionellen Single-Track-Modell, bei dem neue Funktionen und Bugfixes in derselben 8.0-Linie erschienen. Mitte 2023 führte der Anbieter ein Dual-Track-Modell mit Innovation releases und Long Term Stable releases ein. Ein Innovation release ist der sich schneller bewegende Branch für neue Funktionen und Änderungen, während ein LTS release der stabilere Branch ist, der für längeren Produktionseinsatz gedacht ist. Percona beschreibt den LTS-Supportzyklus als 5 Jahre Premier Support, gefolgt von 3 Jahren Extended Support, mit einem typischen neuen LTS etwa alle 2 Jahre.
Unter diesem Modell erschienen die Innovation releases 8.1, 8.2 und 8.3 zwischen 2023 und 2024 und führten zum ersten LTS release, 8.4, im April 2024. Die Innovation-Nummerierung wechselte später in die 9.x-Serie, wobei die Versionen 9.0 bis 9.6 zwischen 2024 und 2026 veröffentlicht wurden. Das zweite LTS release, 9.7, erschien im April 2026, erneut mit dem 5-jährigen Premier-Support-Zeitraum, gefolgt von 3 Jahren Extended Support.
Das neue Nummerierungsschema wird als YY.M.P geschrieben. In 26.7.0 steht 26 für 2026, 7 für Juli und 0 ist die Patch-Nummer, also ein kleineres korrigierendes Update innerhalb dieses Releases. Percona sagt, dass der vierteljährliche Innovation release-Zyklus unter dem neuen Format fortgesetzt wird. Als vorläufiges nächstes Innovation release für Oktober 2026 nennt Percona 26.10.0 und sagt, dass das nächste LTS release nach dem neuen Schema im April 2028 als 28.4.0 erwartet wird.
Für Datenbankadministratoren liegt der Hauptwert in klarerer Planung. Eine Version wie 26.7.0 zeigt unmittelbar, wann das Release ausgeliefert wurde, während Bezeichnungen wie 8.4 oder 9.7 diese Zeitinformation nicht auf den ersten Blick enthalten. Percona erklärt außerdem, dass die Änderung bestehende LTS releases 8.4 und 9.7 nicht betrifft. Diese Branches erhalten weiterhin normale vierteljährliche Wartungsupdates, einschließlich Bugfixes und Sicherheits-Patches, während neue Innovation-Funktionen in die kalendernummerierte Serie einfließen.
Der Upgrade-Pfad ist wichtig. Percona sagt, dass der Datenbankserver 9.7.x LTS der einzige Einstiegspunkt in die erste kalenderbasierte Versionslinie, 26.7.0, ist. In der Praxis muss ein System zuerst auf 9.7 LTS aktualisiert werden, bevor es auf 26.7.0 wechseln kann. Version 8.4.x LTS oder frühere Versionen können nicht direkt in die neue Linie springen. Ein Single-Hop-Upgrade von 9.7.x LTS auf 26.7.0 oder auf spätere Releases derselben Linie wie 26.10.0, 27.1.0 oder 27.4.0 bleibt bis zum nächsten LTS, 28.4.0, gültig. Percona nennt als Beispielpfad 8.4.x LTS zu 9.7.x LTS zu 26.7.0 und weist darauf hin, dass ältere End-of-Life-Versionen wie 5.7 oder 8.0 zuerst auf 8.4 LTS wechseln müssen, bevor sie diesem Weg folgen können.
the open-source database 26.7 fügt außerdem einen Change Stream Applier hinzu, eine replication-Komponente, die ändert, wie Replica-Server Datenbankänderungen anwenden. Replication bedeutet, Datenänderungen von einem Datenbankserver auf einen anderen zu kopieren, damit ein Standby- oder Sekundärsystem mit dem Primärsystem abgeglichen bleibt. Der frühere Multi-threaded Applier nutzte einen Coordinator, um Transaktionen sequenziell aus Relay-Dateien zu lesen und sie dann zur parallelen Ausführung an Worker Threads zu übergeben. Dieses Modell kann an Effizienz verlieren, wenn ein Worker im Leerlauf ist, während er auf das Commit wartet, weil zuerst eine frühere oder abhängige Transaktion abgeschlossen werden muss.
Der Change Stream Applier trennt das Anwenden einer Transaktion vom Commit in der erforderlichen Reihenfolge. Wenn ein Worker das Anwenden einer Transaktion abgeschlossen hat, aber vor dem Commit warten muss, kann er stattdessen mit einer anderen abhängigkeitstauglichen Transaktion fortfahren. Percona listet drei replication-Einstellungen im Zusammenhang mit dieser Änderung auf: die Applier-Versionseinstellung, bei der 1 den älteren Multi-threaded Applier und 2 den Change Stream Applier bedeutet; die Einstellung für die Applier-Worker-Anzahl, die die Worker-Anzahl pro replication channel festlegt; und die Einstellung für das Applier-Event-Speicherlimit, die Speicherlimits pro Channel für zwischengespeicherte binary log events festlegt. Ein binary log ist ein record von Datenbankänderungen, der für recovery und replication verwendet wird.
Percona nennt außerdem zwei betriebliche Verbesserungen. Change Stream Applier-Worker können Transaktionsereignisse gleichzeitig aus dem relay log lesen und Event-Speicher freigeben, nachdem Events verbraucht wurden. Relay log-Dateien können für gleichzeitiges Purging markiert werden, sobald alle Transaktionen erfolgreich angewendet wurden und aus diesen Dateien nichts mehr zu lesen bleibt. Um die Funktion zu nutzen, sagt Percona, ist row-based replication erforderlich, wobei binary logging auf row mode gesetzt sein muss, und Global Transaction Identifier enforcement muss eingeschaltet sein. Ein Global Transaction Identifier ist ein eindeutiges Label für eine Datenbanktransaktion, das Servern hilft, nachzuverfolgen, was bereits verarbeitet wurde.
Eine weitere bemerkenswerte Änderung ist, dass das Thread Pool Plugin in Community releases verfügbar wird. Der Datenbankserver hat traditionell ein One-thread-per-connection-Modell verwendet, was bedeutet, dass jede Client-Verbindung ihren eigenen Server-Thread erstellt. Das kann teuer werden, wenn eine Anwendung viele gleichzeitige Verbindungen öffnet, besonders wenn viele davon idle sind oder schlafen, während sie auf Arbeit warten. Ein thread pool verarbeitet viele Client-Verbindungen über eine kleinere, kontrollierte Anzahl von Worker Threads und reduziert so die Notwendigkeit, für jede Verbindung einen separaten Thread zu erstellen. Percona sagt, dass dies nützlich ist, wenn Anwendungen sehr hohe Zahlen gleichzeitiger Datenbankverbindungen erzeugen und das Erhöhen der maximalen Verbindungseinstellung zu übermäßiger Thread-Erstellung und Ressourcennutzung führen würde.
Percona beschreibt das Aktivieren des Plugins durch Laden des thread pool shared module in der Konfiguration des Datenbankservers, Neustart des Datenbankdienstes und Überprüfung, dass das Thread Pool Plugin über die Plugin-Informationsansicht des Servers aktiv ist. Außerdem werden thread pool-Konfigurationsvariablen wie thread pool size, query threads per group, maximum unused threads und stall limit-Einstellungen aufgeführt. Monitoring ist über Performance Schema-Tabellen für Verbindungen, thread group state, thread group statistics und thread state sowie über Statusvariablen für thread pool query threads verfügbar. Performance Schema ist der integrierte Tabellensatz des Datenbankservers zur Beobachtung der Serveraktivität.
the open-source database 26.7 ändert außerdem die undo log truncation in InnoDB, der storage engine, die verwaltet, wie Daten im Datenbankserver gespeichert und wiederhergestellt werden. Ein undo log zeichnet frühere Versionen geänderter Daten auf, damit Transaktionen zurückgerollt und konsistente Lesevorgänge bedient werden können. Zuvor verwendete InnoDB eine separate undo truncation log-Datei, um undo tablespace truncation zu verfolgen, einschließlich während recovery.