Wie Du Deine NETWAYS Managed Database startest

Wie Du Deine NETWAYS Managed Database startest

von | Jun 27, 2022 | Datenbank, Tutorial

Im ersten Tutorial hat Sebastian bereits erklärt, was es mit Vitess auf sich hat und welche Möglichkeiten es Dir beim Betrieb Deiner Anwendung, im Vergleich zu einer gewöhnlichen Datenbank, bietet.

Im folgenden Text möchte ich nun darauf eingehen, wie Du Dir in unserem Vitess Cluster ganz einfach Deine Datenbank(en) innerhalb von wenigen Minuten starten kannst.

 

Was Deine Datenbank Besonders Macht

Grundsätzlich gilt es vorab zu erwähnen, dass Dein Setup immer hochverfügbar aufgebaut ist. Wir betreiben Vitess in einem Kubernetes Cluster, welcher zu gleichen Teilen auf unsere beiden Rechenzentren verteilt ist.

Dabei replizieren wir die Daten immer von links nach rechts. Eine Managed Database besteht also mindestens aus zwei Replicas – ein Primary und mindestens ein Replica. Liegt der Primary in dem einen Rechenzentrum (links), so kommt das Replika automatisch in das andere (rechts). Fällt also ein Rechenzentrum aus, schwenkt Vitess über und betreibt die Datenbank ohne Beeinträchtigung Deiner Anwendung auf dem zweiten Datencenter weiter.

Weiterhin ist auch ein Disaster Recovery von Haus aus mit dabei. Sobald die Datenbank erstellt wird, wird auch ein initiales Backup angefertigt und in der Folge wird täglich ein Backup (MySQL Dump) erzeugt. Die Daten werden im Xtrabackup-Format in S3 kopiert und aus diesem Storage werden die Daten im Notfall wieder hergestellt.

 

Wie Du Deine Erste Datenbank Startest

Genug zur Theorie – wie läuft denn nun der Start einer Managed DB in der Praxis ab?  Zunächst einmal musst Du Dich auf unserer NETWAYS Web Services (NWS) – Plattform registrieren.

Sobald Du Deinen Account angelegt und Deine Zahlungsart hinterlegt hast, kann es auch schon losgehen!

Als erstes startest Du Dir nun Deinen Vitess Cluster, wie oben im Video zu sehen. Innerhalb eines Vitess Clusters kannst Du dann beliebig viele Datenbanken starten. Unter „Managed Contract“ kannst Du Deinen Cluster auch umbenennen.

 

 

Nun gilt es, die erste Datenbank zu starten. Klicke hierfür einfach auf „1. Create a new database“.

Im Folgenden kannst Du Deine DB benennen und aussuchen, in welchem Vitess-Cluster die Datenbank gestartet werden soll (sofern Du denn mehrere Cluster hast).

Nun musst Du Dich für einen unserer vier Pläne entscheiden. Diese unterscheiden sich in der Replika-Größe, der inkludierten Backup-Größe und dem inkludiertem Traffic. Zusätzlich werden jedem nächst höheren Plan mehr Ressourcen (in Form von CPU u. Arbeitsspeicher) zugeordnet. Wenn Du also viel Load hast, empfiehlt es sich, einen höheren Plan zu wählen, da dieser mehr Queries/Sekunde verarbeiten kann.

Danach kannst Du entscheiden, wie viele Replicas angelegt werden sollen. Der kleinste Wert ist hier immer zwei (bestehend aus einem Primary und einem Replica). Sollte Deine Anwendung sehr leseintensiv sein, kannst du die Zahl der Replicas beliebig erhöhen und somit die Last effizient verteilen.

Auch die Vorhaltedauer der täglichen Backups kann frei bestimmt werden. Das Backup des letzten Tages liefern wir standardmäßig. Sollen die Backups über mehrere Tage aufgehoben werden, kannst Du das aber einfach einstellen, indem Du die Tage auf die gewünschte Dauer erhöhst.

Zu guter Letzt kannst Du auch noch den Replication Mode auswählen. Hier wird eingestellt, wie Deine Daten repliziert werden sollen.

Beim Asyn-Verfahren wird der Primary mit Transaktionen „befeuert“ und die Replicas versuchen einfach, so gut es geht ohne Zeitverzögerung an der Primary dranzubleiben – diese Zeitverzögerungen (Seconds behind Master) können /dürfen aber auftreten. Im Falle eines Failovers kann es hier passieren, dass auf ein Replica umgeschwenkt wird, welches nicht die neuesten Transaktionen mitbekommen hat, da es zeitlich ein paar Sekunden hinterher war.

Dies kann im Semi-Sync-Modus nicht passieren. Im Semi-Sync Modus erwartet MySQL immer mindestens von einem Replica, dass er die letzte Transaktion auch mit erfüllt hat. So wird gewährleistet, dass mindestens ein Replica immer auf dem exakt gleichen Stand wie Dein Primary ist. Geht der Primary kaputt, schwenkt Vitess automatisch auf das aktuellste Replica um und ernennt dieses zum neuen Primary – es geht also ohne Datenverlust weiter.

Hier ein kleiner Tipp: Idealerweise besteht ein Datenbank-Setup im Semi-Sync Modus aus drei Replicas – einem Primary und zwei Replicas. Einer der beiden Replicas ist dabei immer up to date mit dem Primary. Kommt es dann zu einem Failover, kann das zum Primary ernannte Replica weiterhin arbeiten, da es ja noch ein zusätzliches Replica hat, welches neue Transaktionen bestätigt.

Wäre das nicht der Fall (und Du hättest nur ein Replica), dann würde dem zum Primary ernannten Replica nun eine Gegenstelle für das Commitment neuer Transaktionen fehlen. Er müsste also warten, bis ein neues Replica hochgefahren ist, um die Transaktionen zu bestätigen (das betrifft nur writes oder deletes; Lesequeries sind hiervon nicht betroffen).

Nun klickst du auf „Create“ und schon wird Deine Datenbank gestartet! Et voilà – nach einem kurzen Moment sind Deine Daten verfügbar und Du kannst loslegen. Bei Deiner Datenbank hast Du nun die Optionen „Connect“, „Edit“ und „Destroy“.

 

 

Über „Connect“ wird Dir angezeigt, wie Du Dich auf die Datenbank verbindest – ganz wie gewohnt mit mySQL mit Host, User, Passwort und SSL-Optionen (Nicht-SSL-Verbindungen lehnen wir ab).

Es gibt hier noch eine Besonderheit: bei Deiner SQL-Verbindung wird der Datenbank-Name mit angegeben!

Wenn man den DB-Namen um @replica ergänzt, dann verbindest Du Dich auf das Replica (welches nur Read-only ist).

Wenn es Deine Anwendung also unterstützt (z.B. Ruby on Rails), kannst Du Deine Primary-Datenbank- und Deine Replica-Datenbankverbindung angeben und in der Folge gehen alle Select-Statements auf Replicas und alle Data-Manipulation-Statements auf den Primary. So lässt sich Dein Setup super skalieren, da Deine Anwendung die Load der lesenden Queries auf die Replicas leiten kann.

 

 

Über „Edit“ kannst Du Deine Datenbank konfigurieren.

Wenn Dir also der Storage ausgeht, kannst Du hier einfach in den nächstgrößeren Plan wechseln. Oder Du erhöhst die Anzahl der Replica und Backups oder passt den Replication-Modus noch einmal an.

Reicht der größte Plan nicht mehr aus, greift unsere Skalierung über das Sharding. Hierzu folgt aber noch ein ausführliches Tutorial.

 

 

Wie oben zu sehen, löschst Du über „Destroy“ Deine Datenbank wieder.

 

 

Unter dem Punkt „User“ findest Du alle Credentials zum automatisch angelegten User. Darüber hinaus kannst Du hier auch weitere User erstellen (u. wieder löschen) und Passwörter frei vergeben.

 

 

Unter dem Punkt „Backups“ findest Du immer die von Haus aus einmal täglich automatisch erstellte Sicherung.

Du kannst jederzeit auch selbst manuell ein Backup erstellen (für den Fall, dass Du z.B. an Deiner Datenbank arbeitest und vorher noch mal eine letzte Datenbank-Sicherung machen möchtest), indem Du auf „Create Backup“ klickst und hier die zu sichernde Datenbank (sofern Du mehrere in Deinem Cluster gestartet hast) auswählst.

Je nachdem, welchen Rentention-Zyklus Du bei deiner Datenbank eingestellt hast, werden Deine Zwischenspeicherungen dann am Abend wieder weggelöscht.

 

 

Sofern hier mehrere Backups liegen, können diese auch wieder gelöscht werden – lediglich das letzte (höchste) Backup ist nicht löschbar, da mit diesem im Bedarfsfall die Replicas wieder hergestellt werden.

Unter dem Punkt „Graphs“ visualisieren wir die Auslastung Deines Setups (Queries/Sekunde), die Storage-Belegung und das Slave-Lag für alle Replicas.

Unter dem Punkt „Manage contract“ kannst Du Deinen Vitess Cluster umbenennen oder kündigen.

 

Das ist die ganze Magie, die hinter dem Start Deiner ersten NETWAYS Managed Database mit Vitess steckt!

Was ist Vitess?

Was ist Vitess?

von | Jun 24, 2022 | Datenbank, Tutorial

Im Jahr 2010 wurde eine Lösung entwickelt, um die massiven Skalierbarkeitsprobleme von MySQL bei YouTube zu lösen – und somit war Vitess geboren. Später – im Jahr 2018 – wurde das Projekt Teil der Cloud Native Computing Foundation und ist seit 2019 als eines der graduierten Projekte gelistet: Damit befindet es sich in guter Gesellschaft mit anderen prominenten CNCF-Projekten wie Kubernetes, Prometheus und einigen mehr.

Vitess ist ein Open-Source-MySQL-kompatibles Datenbank-Clustering-System für horizontale Skalierung – man könnte auch sagen, es ist eine Sharding Zwischenanwendung für MySQL. Es kombiniert und erweitert viele wichtige SQL-Features mit der Skalierbarkeit einer NoSQL-Datenbank und löst zahlreiche Herausforderungen beim Betrieb gewöhnlicher MySQL-Setups. Mit Vitess wird MySQL massiv skalierbar und hochverfügbar. Vitess ist von Natur aus Cloud-nativ, kann aber auch auf Bare-Metal-Umgebungen betrieben werden.

Architektur

Die Architektur besteht aus mehreren zusätzlichen Komponenten wie VTGate, VTTablet, VTctld und einem Topology Service, der von etcd oder zookeeper unterstützt wird. Die Anwendung verbindet sich entweder über die nativen Datenbanktreiber von Vitess oder über das MySQL-Protokoll: Das bedeutet, dass alle MySQL-Clients und Bibliotheken kompatibel sind.
Die Anwendung verbindet sich mit dem so genannten VTGate – einer Art leichtgewichtigem Proxy -, der den Zustand der MySQL-Instanzen (VTTablets) kennt und weiß, wo welche Daten im Falle von Sharded-Datenbanken gespeichert sind. Diese Informationen werden im Topology Service gespeichert. Das VTGate leitet die Abfragen entsprechend an die zugehörigen VTTablets weiter.
Ein Tablet wiederum ist die Kombination aus einem VTTablet-Prozess und der MySQL-Instanz selbst. Es läuft entweder im primären, im Replikations- oder im Nur-Lese-Modus, wenn es gesund ist. Es gibt eine Replikation zwischen einem primären und mehreren Replikas pro Datenbank. Wenn eine Primärinstanz ausfällt, wird eine Replika hochgestuft und Vitess hilft bei der Wiederherstellung. Dies alles kann vollständig automatisiert werden. Neue, zusätzliche oder ausgefallene Replikas werden von Grund auf neu instanziiert. Sie erhalten die Daten des letzten verfügbaren Backups und werden an die Replikation angeschlossen. Sobald die Daten verfügbar sind, sind sie Teil des Clusters und VTGate leitet Queries an sie weiter.

Philosophie der Skalierbarkeit

Vitess versucht, kleine Instanzen zu betreiben, die nicht mehr als 250 GB an Daten enthalten. Wenn Ihre Datenbank größer wird, muss sie in mehrere Instanzen aufgeteilt werden. Dieser Ansatz hat mehrere gute betriebliche Vorteile. Im Falle des Ausfalls einer Instanz, kann diese mit weniger Daten viel schneller wiederhergestellt werden. Die Wiederherstellungszeit wird durch die schnellere Übertragung von Sicherungskopien verkürzt. Auch die Replikation verläuft in der Regel reibungsloser und mit weniger Verzögerung. Das Verschieben von Instanzen und deren Platzierung auf verschiedenen Nodes für eine bessere Ressourcennutzung, ist ebenfalls ein Vorteil.

Durch die Replikation wird die Haltbarkeit der Daten gewährleistet. Ausfälle von bestimmten Fehlerdomains bzw. Ausfälle generell, sind ganz normal. In Cloud-nativen Umgebungen ist es noch normaler, dass Nodes und Pods entleert oder neu erstellt werden und man versucht, so flexibel wie möglich auf solche Ereignisse zu reagieren. Vitess ist genau dafür konzipiert und passt mit seinen vollautomatisierten Wiederherstellungs- und Reparenting-Fähigkeiten perfekt zu einer Cloud-nativen Umgebung wie Kubernetes.

Darüber hinaus ist Vitess dafür gedacht, über Rechenzentren, Regionen oder Verfügbarkeitszonen hinweg betrieben zu werden. Jede Domain hat ihr eigenes VTGate und einen eigenen Pool von Tablets. Dieses Konzept wird als „Cells in Vitess“ bezeichnet. Wir bei NETWAYS Web Services verteilen die Replikas gleichmäßig über unsere Verfügbarkeitszonen, um einen kompletten Ausfall einer Zone zu überstehen. Es wäre auch möglich, Replikas in geografischen Regionen zu betreiben, um die Latenzzeit und die Erfahrung für Kunden im Ausland zu verbessern.

Zusätzliche Features

Neben der Cloud-nativen Natur und den Möglichkeiten der endlosen Skalierbarkeit, gibt es noch weitere praktische und clevere Funktionen.

  • Connection pooling und Deduplication
    Normalerweise muss MySQL für jede Verbindung etwas (~ 256KB – 3MB) Speicher zuweisen. Dieser Speicher ist nur für die Verbindungen und nicht für die Beschleunigung von Queries gedacht. Vitess erstellt stattdessen sehr leichtgewichtige Verbindungen, indem es den Concurrency Support von Go nutzt. Diese Frontend-Verbindungen werden dann auf weniger Verbindungen zu den MySQL-Instanzen gepooled, so dass es möglich ist, Tausende von Verbindungen reibungslos und effizient zu verarbeiten. Außerdem werden identische Queries in-flight registriert und zurückgehalten, sodass nur eine Anfrage auf die Datenbank trifft.
  • Query- und Transaction Protection
    Hattest Du schon mal das Bedürfnis, lang laufende Queries zu beenden, die Deine Datenbank lahmgelegt haben? Vitess begrenzt die Anzahl der gleichzeitigen Transaktionen und setzt angemessene Timeouts für jede. Queries, die zu lange dauern, werden abgebrochen. Auch schlecht geschriebene Queries ohne LIMITS werden umgeschrieben und begrenzt, bevor sie dem System schaden können.
  • Sharding
    Die integrierten Sharding-Funktionen ermöglichen das Wachstum der Datenbank in Form von Sharding, ohne dass zusätzliche Application Logic hinzugefügt werden muss.
  • Performance Monitoring
    Mit den Tools zur Leistungsanalyse kannst Du die Leistung Deiner Datenbank überwachen, diagnostizieren und analysieren.
  • VReplikation und Workflows
    VReplikation ist ein Schlüsselmechanismus von Vitess. Bei der VReplikation werden Ereignisse des Binlogs vom Sender zu einem Empfänger gestreamt. Workflows sind – wie der Name schon sagt – Abläufe zur Erledigung bestimmter Queries: So kann zum Beispiel eine laufende Production Table nahezu ohne Ausfallzeit auf eine andere Datenbankinstanz verschoben werden („MoveTable„). Auch das Streaming einer Teilmenge von Daten in eine andere Instanz kann mit diesem Konzept durchgeführt werden. Eine „materialisierte Ansicht“ ist praktisch, wenn Du Daten zusammenführen musst, die Tabellen aber auf verschiedenen Instanzen verteilt sind.

 

Fazit

Vitess ist ein sehr leistungsfähiges und cleveres Stück Software! Um genau zu sagen, ist es eine Software, die von Hyperscalern verwendet wird, aber nun für die breite Masse zugänglich gemacht wurde und somit für alle verfügbar. Wenn Du mehr darüber erfahren möchtest, werden wir zukünftig regelmäßig weitere Tutorials veröffentlichen, die fortgeschrittene Themen abdecken werden. Die Dokumentation von vitess.io ist auch eine gute Quelle, um mehr zu erfahren. Wenn Du es selbst mal ausprobieren willst, gibt es mehrere Möglichkeiten: Der bequemste Weg ist, unser Managed Database Produkt zu verwenden und auf unsere Erfahrung zu vertrauen.