oli's blog

Vor 10 Tagen hat ein Artikel von einer Naomi Cannon (auf deutsch Naomi Kanone) auf Reddit mit Verweis auf den vollständigen Artikel auf Medium meine Aufmerksamkeit erregt.

Endlich mal wieder gute Nachrichten!

Was bisher geschah

Nachdem MariaDB Corp. im Mai 2025 Codership OY und somit Galera Cluster für MySQL erworben [ 1 ], anschliessend die Einstellung des Supports für Galera Cluster für MySQL 8.4 für Ende September 2026 angekündigt hatte [ 2 ] und anschliessend verkündete, Galera Cluster (für MariaDB!) nicht mehr weiter in der Community Edition unterstützten zu wollen [ 3 ], gab es in der Community einen lauten Aufschrei. MariaDB Corp. machte hierauf einen halben Rückzug ("We’ve thoroughly considered your feedback and decided that now is not the time for a major change,"). Ein klares Bekenntnis zur weiteren Unterstützung von Galera Cluster in der Community Edition klingt anders.

Was Kunden über FromDual sagen

Wir sind mit der Funktionalität und der Einführung sehr zufrieden. Das gesamte Cluster läuft absolut stabil. Dies ist ein erheblicher Vorteil für unseren Kunden denn wir können unsere Dienstleistungen unterbrechungsfrei anbieten. Wir werden Galera bei weiteren Projekten einsetzen und bestehende Master/Slave-Anwendungen umstellen.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Bei unseren Arbeiten zum Thema “PostgreSQL für Delfine und Seelöwen” lese ich gerne auch auf den PostgreSQL Mailing-Listen mit, um zu sehen, welche Probleme so auftreten und wie sie gelöst werden.

Bei unseren Arbeiten zum Thema “PostgreSQL für Delfine und Seelöwen” habe ich die PostgreSQL Dokumentation zum Thema Replikation durchgeackert.

Bei unseren Arbeiten zum Thema “PostgreSQL für Delfine und Seelöwen” habe ich die PostgreSQL Dokumentation zum Thema Replikation durchgeackert. Was mir dabei aufgefallen ist, ist das PostgreSQL KEINE künstlich verzögerte Replikation kennt, zumindest was diese Doku anbelangt.

Kürzlich haben wir das PostgreSQL Backup-Tool pg_basebackup getestet und dort grossen Gefallen an der remote-Backup Funktionalität gefunden, welche sowohl ein physisches lokales als auch ein physisches remote Backup erlaubt.

Bei unseren Arbeiten zum Thema “PostgreSQL für Delfine und Seelöwen” bin ich darauf gestossen, dass im PostgreSQL Universum um das Thema Point-in-Time-Recovery auf ein spezifisches Statement/eine spezifische Transaktion ein Bogen gemacht wird. Und wenn man Beispiele findet, werden vor allem DDL und nicht DML Statements betrachtet.

Kürzlich hat mich ein Kunde gefragt, ob das “aufwändige” Index-Prüfen nicht einem Index-Optimierer überlassen werden könnte. Klar geht das…

Wie der Screenshot von GitHub zeigt, scheint diese Entscheidung bereits im Juni 2026 gefallen zu sein:

Irgendwie ist die Meldung an mir vorbei gegangen: MariaDB hat den Wartungszeitraum für die Long-Term Releases des MariaDB Community Servers von 5 auf 3 Jahre verkürzt. OK, ist ja nicht weiter verwunderlich, ich war ja gut einen Monat offline…

Beim letzten Kunden hatten wir wirklich ein paar spannende Fragen zu lösen! Insbesondere auch, weil die Datenbank nicht ganz klein war.

Problembeschreibung

MySQL hat mit 5.7.5 im September 2014 den dynamisch konfigurierbaren InnoDB Buffer Pool eingeführt (hier und hier):

Beim letzten Beratungseinsatz beim Kunden, kam dieser freudestrahlend auf mich zu mit der Bemerkung: Er habe meinen Rat befolgt und sämtiche Primary Key Spalten von BIGINT (8 byte) auf INT (4 byte) geändert und das habe viel gebracht! Seine MySQL 8.4er Datenbank sei jetzt um 750 Gbyte kleiner geworden (von 5.5 Tbyte). Schön!

Wenn wir mit PostgreSQL unter unserem myEnv arbeiten, kriegen wir regelmässig Shared Memory Segment Fehler. Beispiel:

Kürzlich wollte ich für eine persönliche kleine Spielerei die Wohnorte der Vereinsmitlieder meines Vereins auf einer Karte darstellen (IGOC Mitglieder). Die Adressen der Vereinsmitglieder waren mir bekannt. Nicht aber die Koordinaten der Wohnorte.

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…