oli's blog

In der MariaDB Master/Slave Replikation gibt es ein Feature welches sich Attribute Promotion/Demotion nennt.

Bei unseren MariaDB für Fortgeschrittene Schulungen, welche wir in etwa alle zwei Monate halten, verwenden wir Maschinen, welche mit einer öffentlichen IP-Adresse direkt dem Internet ausgesetzt sind. Achtung: Man sollte NIE eine Datenbank ungeschützt direkt dem Internet aussetzen! Typischerweise dauert es keine 72 Stunden (3 Tage) bis wir ersten Zugriffsversuchen von aussen ausgesetzt sind.

Kürzlich hatte ich die Gelegenheit ganz viele Linux Systeme (VMs mit Rocky Linux 9) aus einer unserer regelmässig stattfindenden Galera Cluster Schulungen eine Woche lang ganz für mich alleine zur freien Verfügung zu haben. Und auf den Maschinen war auch schon ein MariaDB 11.4.4 mit Galera Cluster installiert.

Künstliche Intelligenz (KI) und Vektor-Datenbanken sind heute in aller Munde. Da MariaDB demnächst auch mit Vektor-Datenbank-Funktionalität auf den Markt kommt, habe ich es als Datenbank-Berater für an der Zeit befunden mich etwas mit dem Thema zu beschäftigen, damit ich wenigstens einen Hauch Ahnung davon habe um was es geht…

Um was geht es?

Bei der Beschreibung von Backup- und /Restore-Szenarien wird in der Regel immer von einem vollständigen Backup (full backup) und einem vollständigen Restore (full restore) der Datenbankinstanz (mariadbd/mysqld) ausgegangen. Das bedeutet, dass die gesamte Datenbankinstanz inklusive aller Datenbanken (Schemata) gesichert und wiederhergestellt wird.

Ein Feature, das mich im neuen MariaDB 11.4 LTS Release wirklich begeistert hat, ist das Verkleinern bzw. Schrumpfen des System-Tablespaces (ibdata1). Auf dieses Feature habe ich seit ca. 2006 sehnsüchtig gewartet und nun ist es mit MariaDB 11.4 endlich gekommen. Eigentlich gibt es dieses Feature schon seit dem MariaDB 11.2 IR (Juni 2023).

Inhaltsverzeichnis

• Rückblick
• Einen Monat später
• Grösse der Tabellen
• Prozessliste
• Globale Variablen
• Metadata Lock und InnoDB Transaction Lock
• Globaler Status

Rückblick

Nachdem wir vor gut 5 Wochen dbstat für MariaDB (und MySQL) vorgestellt haben, haben wir es natürlich auch auf unseren Systemen ausgerollt um das Verhalten im täglichen Einsatz zu testen (eat your own dog food).

Aufgrund eines applikatorischen Fehlers ist unsere Replikation während 5 Tagen stehen geblieben (über Ostern). Nachdem das Problem gelöst war, sollte die Replikation aufholen, was sich als sehr zäh herausstellte. All die üblichen Tricks (innodb_flush_log_at_trx_commit, sync_binlog, etc.) wurden bereits ausgereizt. Also haben wir uns an der parallelen Replikation des MariaDB Servers versucht.

Kürzlich musste ich ein neues MariaDB Feature testen, welches auf unseren Wunsch entwickelt wurde (MDEV-33782). Um dieses Feature zu testen musste ich aber den MariaDB Server selber aus den Quellen bauen, was ich schon seit längerem nicht mehr gemacht habe. Also eine neue Herausforderung, insbesondere mit CMake…

Inhaltsverzeichnis

• Übersicht
• Vorbereitungen
• MaxScale Konfigurations-Synchronisation aktivieren
• MaxScale Parameter ändern
• Neuer Slave hinzufügen und MaxScale bekannt machen
• Alter Slave entfernen und MaxScale bekannt machen
• Wie wird die Konfiguration synchronisiert?
• Was passiert im Konfliktfall?
• Tests
• MaxScale Konfigurations-Synchronisation wieder deaktivieren
• Literatur/Quellen

Übersicht

Ein Feature, welches ich beim Stöbern kürzlich entdecke habe, ist die MaxScale Konfigurations-Synchronisation Funktionalität.

Inhaltsverzeichnis

• Übersicht
• Vorbereitung der Shards (MariaDB Datenbank Instanzen)
  • Testdaten erstellen
  • Rollen und User erstellen
  • MaxScale Monitor User
  • MaxScale Admin User
  • Applikationsrolle und Accounts erstellen
  • Proxy Protokoll
• MaxScale SchemaRouter Konfiguration
• Starten und Stoppen des MaxScale Load Balancers
• Applikations-Tests
  • Einfache Applikations-Tests
  • Neuer Befehl show shards
  • Allgemeinere Test
  • Weniger einfache Test
  • Komplexere Applikations-Tests
  • Cross-Shard-Tests
• Betrieb eines MaxScale Sharding-Systems
  • Do-on-all-shards
  • Invalidieren des Database Map Caches
  • Wie ändert man SchemaRouter Variablen dynamisch?
  • Hinzufügen und Entfernen eines Mandanten
  • Umziehen eines Mandanten
  • Hinzufügen oder entfernen eines Shards
  • Anpassen der Konfigurationsdateien
  • Wartungsarbeiten am Shard
• Beobachtung / Observierung eines MariaDB MaxScale Sharding-Systems
• Literatur / Quellen

Übersicht

Dieses Feature sollte mehr oder weniger mit MariaDB MaxScale 6.x.y, 22.08.x, 23.02.x, 23.08.x und 24.02.x funktionieren. Wir haben es mit der neusten MaxScale Version 23.08.05 getestet, da wir mit einer älteren Version auf Problem gestossen sind (MXS-5026).

Inhaltsverzeichnis

• Funktionalität
• Wie funktioniert dbstat
• Installation
• Abfrage
  • table_size
  • processlist
  • trx_and_lck
  • metadata_lock
  • global_variables
  • global_status
• Testen
• Quellen

Eine Idee, die ich schon lange ins Auge gefasst und jetzt endlich, dank eines Kunden, in Angriff genommen habe, ist dbstat für MariaDB/MySQL. Die Idee ist angelehnt an sar/sysstat von Sebastien Godard:

Das Design eines Data Warehouses unterscheidet sich vom relationalen Design. Data Warehouses designt man oft nach dem Konzept des Star Schemas.

Einleitung

Kurz vorab zwei Punkte:

1. Ein Deadlock ist eine Zustand, in welchem 2 unterschiedliche Transaktionen nicht mehr in der Lage sind weiter zu arbeiten, weil jede Transaktion jeweils einen Lock hält, welche die andere Transaktion gerade bräuchte. Weil jetzt beide Transaktionen jeweils darauf warten, bis die andere Transaktion ihren Lock wieder frei gibt, wird keine von beiden Transaktionen ihre jeweiligen Locks wieder frei geben. Und das würde bis zum Sankt-Nimmerleins-Tag andauern. Um das zu vermeiden schreitet die MariaDB Instanz ein und killt kurzerhand diejenige Transaktion, die weniger Arbeit geleistet hat. Die Applikation kriegt darauf hin eine Deadlock Fehlermeldung vom Typ:

Auch im Jahr 2023 haben Sie wieder die Möglichkeit, sich bei unseren 3 Schulungspartnern in Essen, Köln und Berlin MariaDB und MySQL seitig fit zu machen.

Aufgrund der grossen Nachfrage bieten wir vom 19. bis 22. Dezember 2022 ein zusätzliches Galera Cluster Seminar an. Dies in Zusammenarbeit mit unserem Schulungspartner, der GfU Cyrus AG in Köln.

Das FromDual Seminarprogramm für 2022 steht. Mit unseren Schulungspartnern Linuxhotel in Essen, GfU Cyrus in Köln sowie der Heinlein Akademie in Berlin bieten wir auch 2022 wieder zahlreiche MariaDB und MySQL Schulungen an:

Das FromDual MariaDB und MySQL Schulungsprogramm 2021 steht jetzt zur Verfügung.

Ausschreibungszeitraum: Q4 2020 bis Q2 2021. Später bitte nicht mehr melden.

Das diesjährige Programm des Vorarlberger LinuxDay 2020 wurde veröffentlicht!