Cloud-native: DB-Cluster-System Vitess 13 stellt sich besser auf MySQL ein

Das Cloud-native Cluster-System Vitess liegt ab sofort in Version 13 vor. Mit dem Update des bei der Cloud Native Computing Foundation (CNCF) gehosteten Projekts liefert das Entwicklerteam einige Verbesserungen rund um das Cluster-Management sowie die Abfragedienste. Da Vitess unter anderem auch zur horizontalen Skalierung von MySQL-Datenbankanwendungen ausgelegt ist, sind in das neue Release auch verschiedene Anpassungen insbesondere an MySQL eingeflossen.

Query Planner Gen4 löst Gen3 ab

Nachdem in der vorangegangenen Version des Cluster-Systems Feature-Parität zwischen dem Query Planner der dritten Generation und dem neuen Abfrage-Planer Gen4 erreicht war, hatte das Entwicklerteam letzteren als zunächst noch experimentelle Funktion in Vitess 12 eingeführt. Im neuen Major Release gilt der Query Planner Gen4 als gereift und für den Produktiveinsatz offiziell freigegebenes Feature. Entwicklerinnen und Entwickler erhalten durch den neuen Abfrage-Planer künftig Zugriff auf weitere native Funktionen von MySQL – darunter beispielsweise die Sortierungen (Collations).

So lassen sich nun in den VTGates auch Vergleiche von Zeichenketten unter Berücksichtigung der Sortierung durchführen. Bisher waren Abfragen auf die Debugging-SQL-API in MySQL angewiesen, um solche Vergleiche remote auszuführen. String-Vergleichsabfragen sollen damit nun performanter und zuverlässiger werden. Eine Übersicht der nutzbaren Sortierungen findet sich in der Dokumentation.

Enger an das MySQL-typische Verhalten angepasst wurde auch die in den VTGates laufende SQL Evaluation Engine. Dazu hat das Entwicklerteam das SQL-Auswertungsmodul laut Release Notes weitgehend neu geschrieben. Vitess ist damit nun in der Lage, eine größere Zahl von Abfragen lokal auszuführen. Für Shard-übergreifende Queries sollen Entwicklerinnen und Entwicklern zudem eine erweiterte Semantik und komplexere SQL-Ausdrücke zur Verfügung stehen.

Zuverlässigeres Failover-Management

Beim Cluster-Management in Failover-Szenarien soll der neue, noch experimentelle Orchestrator vtorc durch verbesserte GTID-(Global Transaction Identifier)-Erkennung helfen, die mit dem Einsatz von InitShardPrimary verbundenen Probleme abzustellen. Beim Einleiten eines Notfall-Failover mussten Anwenderinnen und Anwender für das Einrichten des Clusters und die erstmalige Wahl des übergeordneten (Primary) auf InitShardPrimary zurückgreifen.Die Funktion kopiert dabei jedoch automatisch den ausgeführten GTID-Satz vom neuen Primärsystem auf alle anderen Replicas. Das konnte unter Umständen zu nicht korrekt eingerichteten Replicas führen und spätere Probleme bei der Replikation und dem Wiederherstellen nach sich ziehen. In Vitess 13 steht mit PlannedReparentShard eine sicherere Alternative bereit.

Weitergehende Informationen zum neuen Major Release finden sich im CNCF-Blogbeitrag zur Ankündigung von Vitess 13. Einen vollständigen Überblick aller Neuerungen bieten die Release Notes auf GitHub.

(map)