FromDual: FromDual TechFeed (de)

Percona gibt Galera Cluster für Version 9.7 frei

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 11 Sep 2026 12:08:00 +0200

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.

Kurz darauf hat MariaDB Foundation angekündigt, Galera Cluster nicht forken zu wollen ("Thus the Foundation does not see a need for forking Galera and does not support or encourage such action.") [ 4 ].

Die Zukunft von Galera Cluster für MySQL war also bis gestern sehr ungewiss!

Perconas Ankündigung von gestern

Aber zum Glück gibt es da ja noch Percona mit ihrem Percona XtraDB Cluster (PXC), welcher ein verbesserter Branch/Fork sowohl von MySQL als auch von Galera Cluster ist.

Und diese Firma Percona hat gestern (10. September 2026), endlich den Release von Percona XtraDB Cluster 9.7 angekündigt [ 5 ]. Das war für uns das lange erwartete und erhoffte Signal von Percona!

Schön wäre noch, wenn Percona ein klareres Statement zu Galera Cluster geben könnte, damit man sich zeitlich besser darauf einstellen kann…

Installation

Wir konnten natürlich nicht widerstehen und haben sofort den neusten Release heruntergeladen [ 6 ] und einen Percona XtraDB Testcluster aufgebaut.

Bedingt durch unseren Standard-Galera-Installationsmechanismus mussten wir am einen oder anderen Ort noch etwas nachhelfen, damit der Percona XtraDB Cluster auch sauber zum laufen kam.

Die Details haben wir hier beschrieben: Migration from MySQL Galera Cluster 8.4 to Percona XtraDB Cluster 9.7

Weitere Tests werden in den nächsten Tagen und Wochen folgen…

Jetzt wäre eigentlich ein guter Augenblick, als kommerziell orientierter Galera Cluster Nutzer, Percona zu sponsern…? Für ein vitales und gesundes MySQL Open Source Ökosystem: The Future of the MySQL Ecosystem.

Quellen

Percona XtraDB Cluster 9.7 Documentation

PostgreSQL Daten retten bei korrupten Blocks

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 01 Sep 2026 07:50:00 +0200

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.

Ein Mail hat mich besonders interessiert:

I’m unable to access one of the tables. Even a simple SELECT statement fails with the error below.
prod=# SELECT count(*) FROM schema.tablename;

WARNING: page verification failed, calculated checksum 26618 but expected 52580
ERROR: invalid page in block 43197 of relation base/24576/24578
CONTEXT: parallel worker

Interpretation der Informationen

Wie ist diese Information zu interpretieren?

“parallel worker” ➜ PostgreSQL hat das Query parallel abgearbeitet. Wahrscheinlich irrelevant in diesem Fall?
“invalid page in block 43197” ➜ “page” und “block” sind im PostgreSQL Universum Synonyme, wenn man den zahlreichen Quellen im Internet glauben darf? Also ist die Fehlermeldung eigentlich widersinnig!?! Also: Page/Block Nummer 43197 ist kaputt!
“relation base/24576/24578” ➜ Welches Datenbank-Objekt (Tabelle, Index, etc.) davon betroffen ist. Mehr dazu weiter unten…
“calculated checksum” ➜ PostgreSQL versieht jede Page beim Schreiben auf Platte mit einer Checksumme, welche beim Lesen überprüft wird. [ 1 ]. In diesem Fall scheint die Prüfung fehlgeschlagen zu sein.
Das geht natürlich nur, wenn das Checksummen-Bilden aktiviert ist (default ab v18).
```
 postgres=> SHOW data_checksums;
 data_checksums 
 ----------------
 on
```

Zur “relation”

Tabellen werden in PostgreSQL “relations” genannt:

Relation is essentially a mathematical term for table. [ 2 ]

Wenn wir uns das Ganze zuerst mal auf Platte anschauen sieht das wie folgt aus:

$ cd ${PGDATA}

$ ll -d base/*
drwx------ 2 dba dba 4096 Jul 20 17:53 base/1
drwx------ 2 dba dba 12288 Aug 5 21:33 base/24576
drwx------ 2 dba dba 4096 Jul 16 09:04 base/4
drwx------ 2 dba dba 12288 Aug 5 21:33 base/49204
drwx------ 2 dba dba 12288 Aug 5 21:33 base/5
drwx------ 2 dba dba 4096 Aug 5 21:33 base/57405
drwx------ 2 dba dba 4096 Aug 5 21:33 base/57406
drwx------ 2 dba dba 4096 Aug 5 21:33 base/57408
drwx------ 2 dba dba 36864 Aug 5 21:33 base/77107
drwx------ 2 dba dba 4096 Jul 20 18:05 base/pgsql_tmp

Hier haben wir zuerst mal alle Datenbanken gelistet. Wenn wir die Zuordnung zu den Namen erfahren wollen, müssen wir IN der Datenbank-Instanz schauen:

postgres=# SELECT oid, datname AS database FROM pg_database;
 oid | datname 
-------+-----------
 5 | postgres
 1 | template1
 4 | template0
 49204 | dba
 24576 | test
 57405 | osm_ch
 57406 | osm_chx
 57408 | osm
 77107 | enswitch

Wir wissen also jetzt schon mal, dass der Schaden in der Datenbank test entstanden ist. Also schauen wir auf dem Dateisystem mal eine Ebene tiefer:

$ cd base/24576

$ ls -lrS
...
-rw------- 1 dba dba 835584 Mar 18 17:30 1255
-rw------- 1 dba dba 1294336 Jun 10 12:15 24578_fsm
-rw------- 1 dba dba 890937344 Jul 23 17:50 24578.4
-rw------- 1 dba dba 1062330368 Jun 10 12:15 24588.1
-rw------- 1 dba dba 1073741824 Jul 23 17:50 24588
-rw------- 1 dba dba 1073741824 Mar 18 18:08 24578.3
-rw------- 1 dba dba 1073741824 Mar 18 18:07 24578.2
-rw------- 1 dba dba 1073741824 Mar 18 17:36 24578.1
-rw------- 1 dba dba 1073741824 Jul 23 12:39 24578

Hier liegen alle Datenbank-Objekte rum. Um welche Tabelle es sich handelt erfahren wir wiederum IN der Datenbank-Instanz:

postgres=# \connect test

test=# SELECT c.oid AS file, c.relname AS name, ns.nspname AS schema
 , CASE c.relkind
 WHEN 'r' THEN 'Ordinary Table'
 WHEN 'i' THEN 'Index'
 WHEN 'S' THEN 'Sequence'
 WHEN 'v' THEN 'View'
 WHEN 'm' THEN 'Materialized View'
 WHEN 'c' THEN 'Composite Type'
 WHEN 't' THEN 'TOAST Table'
 WHEN 'f' THEN 'Foreign Table'
 WHEN 'p' THEN 'Partitioned Table'
 WHEN 'I' THEN 'Partitioned Index'
 ELSE CONCAT('Unknown (', c.relkind, ')')
 END AS object_type
 , am.amname, c.relfilenode, c.reltablespace
 FROM pg_class AS c
 JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
 LEFT JOIN pg_am AS am ON am.oid = c.relam
WHERE ns.nspname NOT IN ('pg_catalog', 'pg_toast', 'information_schema')
 AND c.oid IN (24578, 24588, 1255)
;
 file | name | schema | object_type | amname | relfilenode | reltablespace 
-------+-----------+------------+----------------+--------+-------------+---------------
 24578 | test | public | Ordinary Table | heap | 24578 | 0
 24588 | test_pkey | public | Index | btree | 24588 | 0
 1255 | pg_proc | pg_catalog | Ordinary Table | heap | 0 | 0

Es handelt sich also beim betroffenen Objekt um die “gewöhnliche” Tabelle (Ordinary Table) test im Schema public in der Datenbank test.

Kaputt machen

Wie haben wir jetzt das Ganze simuliert, sprich, kaputt gemacht? Hierzu eignet sich der Befehl dd ausgezeichnet:

$ dd if=/dev/urandom of=24578 bs=1 seek=353874683 count=128 conv=notrunc

Wenn man das dann auf die Fehlermeldung am Anfang zurück rechnet sieht man, dass es passt:

Block Nr. 43197 x 8 k/block ➜ 353'869'824 Anfangsadresse, das Ende liegt bei: 353'878'015 und überschrieben haben wir ab Adresse 353'874'683 128 bytes.

Jetzt versuchen wir die Daten in der Datenbank noch/wieder zu lesen und erhalten genau die richtige Fehlermeldung:

test=# SELECT * FROM test;
ERROR: invalid page in block 43197 of relation "base/24576/24578"

Falls man mal noch einen Blick ins Error Log wirft, findet man dort ebenfalls dieselbe Fehlermeldung:

LOG: page verification failed, calculated checksum 26618 but expected 52580
CONTEXT: I/O worker executing I/O on behalf of process 595983
LOG: invalid page in block 43197 of relation "base/24576/24578"
CONTEXT: I/O worker executing I/O on behalf of process 595983
ERROR: invalid page in block 43197 of relation "base/24576/24578"
STATEMENT: SELECT * FROM test;

Eine weitere Möglichkeit, Checksummen-Fehler zu überprüfen besteht mit der folgenden Abfrage:

postgres=# SELECT datid, datname, conflicts, checksum_failures, checksum_last_failure
 FROM pg_stat_database;
 datid | datname | conflicts | checksum_failures | checksum_last_failure 
-------+-----------+-----------+-------------------+-------------------------------
 0 | | 0 | 0 | 
 5 | postgres | 0 | 0 | 
 1 | template1 | 0 | 0 | 
 4 | template0 | 0 | 0 | 
 49204 | dba | 0 | 0 | 
 24576 | test | 0 | 27 | 2026-08-06 18:47:58.777398+02
 57405 | osm_ch | 0 | 0 | 
 57406 | osm_chx | 0 | 0 | 
 57408 | osm | 0 | 0 | 
 77107 | enswitch | 0 | 0 |

Korruption eingrenzen

Gehen wir mal davon aus, dass wir KEINE Backups haben (muss man aktiv selber tun und prüfen bzw. testen) und/oder das WAL-Archiving nicht aktiviert ist (default off) und die Änderungen seit dem letzten Backup (von heute Morgen um 02:00) nicht verloren gehen sollen…

Wie kann ich also die aktuellen Daten noch retten? pg_dump wird ebenfalls fehlschlagen (macht das Selbe wie SELECT). pg_basebackup wird auch melden, dass die Checksumme nicht stimmt und ebenfalls fehlschlagen. Zudem komme ich so immer noch nicht wieder an meine Daten ran.

Wir müssen also technisch mehr oder weniger Zeile für Zeile bis vor die Korruption rausfieseln. Das Ende der Korruption finden. Und ab da ebenfalls Zeile für Zeile rausfieseln.

In der Praxis machen wir das, indem wir uns von oben und unten an die Korruption herantasten, indem wir immer jeweils bis zur Hälfte prüfen. [ 3 ]

Block Korruption in PostgreSQL Tabellen finden

Dazu müssen wir zuerst mal das obere und untere “Ende” unserer Tabelle finden. Hierzu eignet sich typischer Weise der Primary Key, welcher in unserem Fall die Spalte id vom Type serial ist und auf welchem damit eine SEQUENCE liegt:

test=# SELECT MIN(id), MAX(id) FROM test;
 min | max 
-----+----------
 11 | 75930859

Dann geht die Sucherei los:

test=# SELECT * FROM test WHERE id < 40000000 ORDER BY id;
ERROR: invalid page in block 43197 of relation "base/24576/24578"
test=# SELECT * FROM test WHERE id < 20000000 ORDER BY id;
ERROR: invalid page in block 43197 of relation "base/24576/24578"
test=# SELECT * FROM test WHERE id < 10000000 ORDER BY id;
ERROR: invalid page in block 43197 of relation "base/24576/24578"
test=# SELECT * FROM test WHERE id < 5000000 ORDER BY id;
ERROR: invalid page in block 43197 of relation "base/24576/24578"
test=# SELECT * FROM test WHERE id < 2500000 ORDER BY id;
 id | data | ts 
---------+-------------------------------+----------------------------
 11 | Some text | 2026-07-23 17:46:13.710454
 61 | Some data to blow table up... | 2026-03-18 17:29:49.408976
test=# SELECT * FROM test WHERE id BETWEEN 2500000 AND 5000000 ORDER BY id;
ERROR: invalid page in block 43197 of relation "base/24576/24578"
...

Der Anfang unserer Korruption liegt also irgendwo im Bereich zwischen Zeile 2'500'000 und 5'000'000.

Bereich von	Beriech bis	Resultat	Anzahl Zeilen
2500000	5000000	ERROR	2'500'000
2500000	3750000	OK	1'250'000
3750000	4250000	OK	500'000
4250000	4600000	OK	350'000
4600000	4800000	ERROR	200'000
4600000	4700000	ERROR	100'000
4600000	4650000	ERROR	50'000
4600000	4625000	ERROR	25'000
4600000	4612500	OK	12'500
4612500	4619000	OK	6'500
4619000	4622000	OK	3'000
4622000	4623500	ERROR	1'500
4622000	4622750	ERROR	750
4622350	4622750	OK	400
4622175	4622350	ERROR	175
4622265	4622350	OK	85
4622175	4622265	ERROR	90
4622220	4622265	OK	45
4622175	4622220	ERROR	45
4622175	4622188	ERROR	13
4622188	4622220	OK	32
4622181	4622188	ERROR	7
4622175	4622181	ERROR	6
4622170	4622175	ERROR	5
4622120	4622130	…	10

Dann gehen wir in den Fein-Suche-Bereich über:

test=# SELECT * FROM test WHERE id = 4622079;
 id | data | ts 
---------+-------------------------------+----------------------------
 4622079 | Some data to blow table up... | 2026-03-18 17:31:39.104354
(1 row)

Zeile	Resultat
…	OK
4622079	OK
4622080	ERROR
4622081	ERROR
…	ERROR
4622186	ERROR
4622187	OK
…	OK

Das selbe Spielchen machen wir jetzt noch von “oben” und gelangen zum Schluss an einen Wertebereich der Korruption von 4'622'080 bis 4'622'186. Es sind also erst mal 107 Rows innerhalb dieser Korruption.

Daten retten

Zum Retten der Daten erstellen wir zuerst einmal eine exakte Kopie unserer Tabelle (Achtung: Daran denken, genügend Diskplatz bereit zu stellen!):

test=# CREATE TABLE test_copy (LIKE test INCLUDING ALL);

Und bringen erst mal alle unsere Daten in Sicherheit:

test=# INSERT INTO test_copy SELECT * FROM test WHERE id < 4622080;

Den unteren Teil der Daten können wir noch mittels eines “sequential scans” retten:

test=# EXPLAIN SELECT * FROM test WHERE id < 4622080;
 QUERY PLAN 
------------------------------------------------------------------
 Seq Scan on test (cost=0.00..1581458.80 rows=71211823 width=36)
 Filter: (id < 4622080)

Beim oberen Teil der Daten geht das dann nicht mehr. Hier müssen wir den Planner zu einem “index scan” zwingen:

test=# SET enable_seqscan = off;
SET

test=# EXPLAIN SELECT * FROM test WHERE id > 4622186;
 QUERY PLAN 
------------------------------------------------------------------------------------
 Index Scan using test_pkey on test (cost=0.57..2819292.47 rows=71211823 width=36)
 Index Cond: (id > 4622186)

test=# INSERT INTO test_copy SELECT * FROM test WHERE id > 4622186;

test=# SET enable_seqscan = on;

Somit hätten wir erst mal alle Daten in Sicherheit gebracht, welche ausserhalb des korrupten Blocks liegen. Jetzt stellt sich natürlich die Frage, ob noch mehr geht?

Mehr Daten retten

Zu diesem Zweck erstellen wir eine zweite Tabelle und ignorieren die Checksummen-Fehler. Achtung: Ab diesem Punkt können die Checksummen-Fehler plötzlich “magisch” verschwinden die Korruptionen sind aber dadurch nicht weg sondern werden einfach nicht mehr festegestellt. [ 4 ]

test=# CREATE TABLE test_copy2 (LIKE test INCLUDING ALL);

test=# SET ignore_checksum_failure = on;

Dann kopieren wir unsere Rows häppchenweise von Zeile 4622080 bis 4622186 weg:

test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id >= 4622080 and id < 4622090;
test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id >= 4622090 and id < 4622100;
test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id >= 4622100 and id < 4622110;
test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id >= 4622110 and id < 4622120;
test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id >= 4622120 and id < 4622123;
test=# --> Here is the hole!
test=# INSERT INTO test_copy2 SELECT * FROM test WHERE id > 4622127 and id <= 4622186;

Dann überprüfen wir noch mal die Wertebereiche:

test=# SELECT * FROM test_copy WHERE id between 4622075 and 4622080;
 id | data | ts 
---------+-------------------------------+----------------------------
 4622075 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622076 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622077 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622078 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622079 | Some data to blow table up... | 2026-03-18 17:31:39.104354

test=# SELECT * FROM test_copy2 WHERE id between 4622075 and 4622085;
 id | data | ts 
---------+-------------------------------+----------------------------
 4622080 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622081 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622082 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622083 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622084 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622085 | Some data to blow table up... | 2026-03-18 17:31:39.104354

test=# SELECT * FROM test_copy2 WHERE id between 4622180 and 4622190;
 id | data | ts 
---------+-------------------------------+----------------------------
 4622180 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622181 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622182 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622183 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622184 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622185 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622186 | Some data to blow table up... | 2026-03-18 17:31:39.104354

test=# SELECT * FROM test_copy WHERE id between 4622180 and 4622190;
 id | data | ts 
---------+-------------------------------+----------------------------
 4622187 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622188 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622189 | Some data to blow table up... | 2026-03-18 17:31:39.104354
 4622190 | Some data to blow table up... | 2026-03-18 17:31:39.104354

Und fügen die beiden Datensets wieder zusammen:

test=# INSERT INTO test_copy SELECT * FROM test_copy2;
INSERT 0 104

test=# DROP TABLE test_copy2;
DROP TABLE

test=# DROP TABLE test CASCADE;
NOTICE: drop cascades to default value for column id of table test_copy
DROP TABLE

test=# ALTER TABLE test_copy RENAME TO test;
ALTER TABLE

test=# CREATE SEQUENCE public.test_id_seq
 AS integer
 RESTART WITH 75930860
 INCREMENT BY 1
 NO MINVALUE
 NO MAXVALUE
 CACHE 1;

test=# ALTER SEQUENCE public.test_id_seq OWNER TO dba;
test=# ALTER SEQUENCE public.test_id_seq OWNED BY public.test.id;
test=# ALTER TABLE ONLY public.test ALTER COLUMN id SET DEFAULT nextval('public.test_id_seq'::regclass);

Spätestens jetzt aber ist es allerhöchste Zeit, sich ernsthaft Gedanken um ein Backup zu machen…

Quellen

Christophe Pettus, PostgreSQL Experts, 2026-08-05: All Your GUCs in a Row: ignore_checksum_failure
Christophe Pettus, PostgreSQL Experts, 2026-08-06: All Your GUCs in a Row: ignore_invalid_pages
Ashutosh Sharma pg_surgery — perform low-level surgery on relation data
PostgreSQL Server Configuration: zero_damaged_pages
pageinspect — low-level inspection of database pages

PostgreSQL Dokumentation noch besser machen

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 10 Aug 2026 10:50:00 +0200

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

Da ich bei diesem Thema noch nicht ganz so fit bin, schaue ich bei einigen Stichworten (Parametern, Funktionen, etc.) immer mal wieder gerne nach, was diese genau bedeuten oder wie sie genau funktionieren (RTFM!). Genau dafür wurden ja ursprünglich mal die Links erfunden, welche zuerst Gopher und später das Internet/WWW (http) so populär gemacht haben.

Leider fehlen aber in besagter Dokumentation oft diese Links, was den Lesefluss behindert.

Zum Glück aber ist PostgreSQL ein Open Source Projekt und Mitarbeit soll ja hochwillkommen sein! Also könnte ich ja, statt nur dumm über die Dokumentation rumzumosern, die entsprechenden fehlenden Links selber hinzufügen. Aber wie geht das denn genau in einem für mich neuen und daher noch etwas ungewohnten Ökosystem? Dabei hat mir ein Artikel von Elizabeth Christensen von Crunchy Data mit dem Titel: Contributing to Postgres 101: A Beginner’s Experience beim Einstieg geholfen.

Da ich selber Null Ahnung vom Programmieren habe, sehe ich beim Dokumentation Verbessern eine gute Möglichkeit, mich aktiv ins Projekt einzubringen und mitzuhelfen…

PostgreSQL Dokumentation verbessern

Die PostgreSQL Dokumentation liegt direkt im Server-Repository. Also ziehen wir uns als erstes mal das Git-Repository vom PostgreSQL Server runter:

$ git clone http://git.postgresql.org/git/postgresql.git

Die nächste Herausforderung besteht darin, die richtige Datei zu finden:

$ cd postgresql/doc/src/sgml

Hierbei hilft mit der grep Befehl in all seinen Spielarten weiter:

$ grep -r 'Planning for High Availability' *.sgml
high-availability.sgml: <title>Planning for High Availability</title>

Das richtige Dokument scheint high-availability.sgml zu sein. Die PostgreSQL Dokumentation selbst ist in SGML verfasst, welche ähnlich wie HTML und nicht sonderlich schwer zu erlernen ist.

Diese SGML-Dateien lassen sich gut mit dem Editor der Wahl und entsprechendem Code-Highlighting lesen und ändern.

Dann geht es daran, die einzelnen Stichworte zu überprüfen, ob sie schon korrekt mit Markups versehen sind und wenn ja, diese mit Links zu versehen:

Stichwort	Markups	Links
synchronous_standby_names	<varname>synchronous_standby_names</varname>	<xref linkend="guc-synchronous-standby-names"/>
archive_command	<varname>archive_command</varname>	<xref linkend="guc-archive-command"/>
archive_library	<varname>archive_library</varname>	<xref linkend="guc-archive-library"/>
synchronous_commit	<varname>synchronous_commit</varname>	<xref linkend="guc-synchronous-commit"/>
pg_receivewal	<command>pg_receivewal</command>	<xref linkend="app-pgreceivewal"/>
pg_recvlogical	<command>pg_recvlogical</command>	<xref linkend="app-pgrecvlogical"/>
pg_backup_stop	<function>pg_backup_stop()</function>	<link linkend=“pg-backup-stop”><function>pg_backup_stop()</function></link>
pg_backup_start	<function>pg_backup_start()</function>	<link linkend=“pg-backup-start”><function>pg_backup_start()</function></link>
pg_switch_wal	<function>pg_switch_wal()</function>	<link linkend=“pg_switch_wal”><function>pg_switch_wal()</function></link>

Achtung: Hierbei ist zu beachten, dass die Stichworte mit “_” (Unterstrich) und die Links mit “-” (Bindestrich) geschrieben werden.

Beim Bauen der Dokumentation ist dann noch aufgefallen, dass einige Ziele von Links (id) gar nicht gesetzt waren, also mussten diese auch noch angepasst werden:

 <row>
- <entry role="func_table_entry"><para role="func_signature">
+ <entry id="pg-backup-start" role="func_table_entry"><para role="func_signature">
 <indexterm>
 <primary>pg_backup_start</primary>

Qualitätssicherung

Wenn alle Änderungen vorgenommen sind, geht es an die Qualitätskontrolle. Dazu baut man die Dokumentation lokal:

$ cd postgresql
$ ./configure
$ cd doc
$ make

Wie das im genau im Detail funktioniert, ist hier beschrieben.

Falls der Build noch Fehler findet, werden diese angezeigt und der Build wird abgebrochen. Falls alles sauber durch läuft, kann man mit dem Browser seiner Wahl, jetzt noch schauen, ob auch alles wirklich so funktioniert, wie man sich das vorstellt:

$ firefox src/sgml/html/warm-standby.html

Was ich später noch gefunden habe:

Building the documentation can take very long. But there is a method to just check the correct syntax of the documentation files, which only takes a few seconds: [ 5 ]

$ make check
make -C ../src/backend generated-headers
make[1]: Entering directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend'
make -C ../include/catalog generated-headers
make[2]: Entering directory '/home/oli/fromdual/postgresql/docu/postgresql/src/include/catalog'
make[2]: Nothing to be done for 'generated-headers'.
make[2]: Leaving directory '/home/oli/fromdual/postgresql/docu/postgresql/src/include/catalog'
make -C nodes generated-header-symlinks
make[2]: Entering directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/nodes'
make[2]: Nothing to be done for 'generated-header-symlinks'.
make[2]: Leaving directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/nodes'
make -C utils generated-header-symlinks
make[2]: Entering directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/utils'
make -C adt jsonpath_gram.h
make[3]: Entering directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/utils/adt'
make[3]: 'jsonpath_gram.h' is up to date.
make[3]: Leaving directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/utils/adt'
make[2]: Leaving directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend/utils'
make[1]: Leaving directory '/home/oli/fromdual/postgresql/docu/postgresql/src/backend'
rm -rf '/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install
/usr/bin/mkdir -p '/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/log
make -C '..' DESTDIR='/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install install >'/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/log/install.log 2>&1
make -j1 checkprep >>'/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/log/install.log 2>&1
PATH="/home/oli/fromdual/postgresql/docu/postgresql/tmp_install/usr/local/pgsql/bin:/home/oli/fromdual/postgresql/docu/postgresql/doc:$PATH" LD_LIBRARY_PATH="/home/oli/fromdual/postgresql/docu/postgresql/tmp_install/usr/local/pgsql/lib:$LD_LIBRARY_PATH" INITDB_TEMPLATE='/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/initdb-template initdb --auth trust --no-sync --no-instructions --lc-messages=C --no-clean '/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/initdb-template >>'/home/oli/fromdual/postgresql/docu/postgresql'/tmp_install/log/initdb-template.log 2>&1

Patch einreichen

Wenn alles wie vorgesehen und zur Zufriedenheit funktioniert, kann man dann daran gehen, den Patch zu erstellen um ihn einzureichen:

$ git commit -m 'some references on variables and functions added'
$ git format-patch -1 HEAD

Dabei wird eine Datei erstellt, die den Commit-Kommentar enhält: 0001-some-references-on-variables-and-functions-added.patch.

Jetzt ist es im PostgreSQL-Projekt anscheinend so, dass man keinen Merge-Request erstellt um den Patch in den Quellcode zurück gelangen zu lassen sondern so, dass der Patch an die entsprechende Mailingliste geschickt werden muss und anschliessend von einem Entwickler, der Merge/Commit-Rechte hat, in den Haupt-Baum eingepflegt wird. Ich habe mich jetzt mal mit “meinem” Commiter darauf geeinigt, dass wir die Diskussion über meinen Patch auf der pgsql-docs Mailingliste führen.

Mal schauen, wie es weiter geht und wie weit ich mit meinem Patch komme…

Künstlich verzögerte Replikation mit PostgreSQL

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 31 Jul 2026 11:59:00 +0200

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.

Nachdem ich mir bereits Gedanken darüber gemacht habe, wie man eventuell mit PostgreSQL Bordmitteln, eine künstlich verzögerte Replikation basteln könnte, habe ich doch noch mal die Suchmaschine meiner Wahl bemüht und, siehe da, beim zweiten Anlauf hat es dann doch noch geklappt: Ich wurde fündig! [ 2019: 1 ]

Die entsprechende Replikations-Konfiguration heisst: recovery_min_apply_delay [ 2 ]. Leider fehlt das in der Dokumentation zum Thema “Replikation”. Ich habe mal bei der PostgreSQL Community einen Verbesserungsvorschlag eingereicht. Mal schauen, wie weit ich da komme…

Anwendungsfälle

Aber warum will man überhaupt eine Replikation verzögern? Dazu sind mir bisher unterschiedliche Anwendungsfälle begegnet:

Am häufigsten wird dieses Setup gegen Ups!-Queries verwendet. Ein Fehler auf dem Primary würde bei einer normalen Replikation unmittelbar auf den Standby Servern einschlagen und auf diesen ebenfalls die Daten zerstören. Mit der verzögerten Replikation erhält man Zeit, den Fehler zu analysieren, allenfalls die Daten aus dem Standby zur Rettung herbeizuziehen oder den Stanby bis vor das Ups-Query aufholen zu lassen und dann auf den Standby zu schwenken. Siehe hierzu auch: PostgreSQL Point-in-Time-Recovery bei Ups-Queries.
Ein weiterer Anwendungsfall ist, einer bestimmten Nutzergruppe gezielt alte Daten zur Verfügung zu stellen, um sie bei entsprechender Bezahlung auf die aktuellen Daten zugreifen zu lassen (Freemium Geschäftsmodell) z. B. bei Börsenhandel, Computerwetten, Computerspielen, Sportresultaten, Job- oder sonstigen Angeboten oder Wetterdaten.
Ein dritter Anwendungsfall wäre, ein System zu testen, wie es sich bei Replikationsverzögerungen verhält. Bei einer asynchronen Replikation kann es potentiell immer zu Verzögerungen zwischen Primary und Standby kommen. Künstlich eine so hohe Last zu erzeugen, dass dieses Verhalten simuliert werden kann, ist oft schwierig. Mit der künstlich verzögerten Replikation kann man das Verhalten der Anwendung so gezielt testen und allenfalls die Anwendung robuster machen.
Der letzte Anwendungsfall wäre, schauen zu können, wie die Datenbank in der Vergangenheit ausgesehen hat, ohne ein Backup wieder einspielen zu müssen. Wenn man die Replikation zum Beispiel mit einer Verzögerung von einer Woche konfiguriert (bei PostgreSQL sind maximal knapp 40 Tage (2³² Sekunden) möglich), kann man in der Folgewoche noch schauen, ob die Daten nach dem Change am Wochenende noch korrekt sind.

Aufsetzen der Primary Instanz

Der Primary muss zusätzlich wie folgt konfiguriert werden (Datenbank-Neustart erforderlich!):

#
# postgresql.conf
#
cluster_name = 'pg18p'
listen_addresses = '*'
archive_mode = on
archive_command = 'test ! -f /mnt/backup/wal_archive/%f && cp %p /mnt/backup/wal_archive/%f && sync /mnt/backup/wal_archive/%f'

Damit alte WALs auf dem Primary nicht zu früh gelöscht werden, arbeiten wir hier mit einem “Replication Slot”. Dieser muss zuerst angelegt werden:

postgres=# SELECT * FROM pg_create_physical_replication_slot('slot_for_pg18s1');
 slot_name | lsn 
-----------------+-----
 slot_for_pg18s1 | 

postgres=# SELECT slot_name, slot_type, active, wal_status, failover, synced
 FROM pg_replication_slots
;
 slot_name | slot_type | active | wal_status | failover | synced 
-----------------+-----------+--------+------------+----------+--------
 slot_for_pg18s1 | physical | f | | f | f

Natürlich braucht es auch noch einen Replikations-User:

postgres=# CREATE ROLE replication WITH LOGIN PASSWORD 'secret' REPLICATION;

welcher natürlich auch von remote zugreifen können muss:

#
# pg_hba.conf
#
# TYPE DATABASE USER ADDRESS METHOD
host replication replication 10.223.125.0/24 scram-sha-256

und ein anschliessendes Aktivieren der Konfiguration:

postgres=# SELECT pg_reload_conf();

Aufsetzen der Standby Instanz

Dann bauen wir den verzögerten Standby wie folgt auf:

$ sudo systemctl stop postgresql
$ PGDATA='/var/lib/postgresql/18/main'
$ rm -rf ${PGDATA}/*
$ pg_basebackup --user=replication --host=10.223.125.65 --format=plain --pgdata=${PGDATA}/
$ touch ${PGDATA}/standby.signal

passen die PostgreSQL Konfiguration wie folgt an:

#
# postgresql.conf
#
cluster_name = 'pg18s1'
archive_cleanup_command = 'pg_archivecleanup /mnt/backup/wal_archive %r'

recovery_target_timeline = latest # default
primary_conninfo = 'host=10.223.125.65 port=5432 user=replication options=''-c wal_sender_timeout=5000'''
recovery_min_apply_delay = '5min'

Das Passwort kann in der Datei ~/.pgpass hinterlegt werden:

10.223.125.65:5432:replication:replication:secret

Dann starten wir die Standby Instanz und zum Schluss überprüfen wir, ob alles sauber funktioniert (ggf. recovery_min_apply_delay warten):

postgres=# SELECT pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t

postgres=# SELECT CURRENT_TIMESTAMP AS now, pg_last_xact_replay_timestamp() AS last_xact_timestamp
 , age(CURRENT_TIMESTAMP, pg_last_xact_replay_timestamp())
;
 now | last_xact_timestamp | age 
------------------------------+-------------------------------+-----------------
 2026-07-29 11:46:21.92429+00 | 2026-07-29 11:41:21.919321+00 | 00:00:00.004969

Das Ups-Query

Jetzt passiert auf dem Primary das Ups-Query:

test=# UPDATE test SET data = 'alles kaputt!';
UPDATE 673

Nach etwas Schreckensstarre ermitteln wir die Zeit (Achtung: UTC!):

test=# SELECT current_timestamp;
 current_timestamp 
-------------------------------
 2026-07-31 14:10:30.083692+00

Stoppen der Replikation

Sobald das Ups-Query aufgetreten ist, müssen wir sofort die Replikation auf dem Standby stoppen:

postgres=# SELECT pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t

postgres=# SELECT pg_get_wal_replay_pause_state();
 pg_get_wal_replay_pause_state 
-------------------------------
 not paused

postgres=# SELECT pg_wal_replay_pause();
 pg_wal_replay_pause 
---------------------
 
(1 row)

postgres=# SELECT pg_get_wal_replay_pause_state();
 pg_get_wal_replay_pause_state 
-------------------------------
 paused

postgres=# SELECT pg_is_wal_replay_paused();
 pg_is_wal_replay_paused 
-------------------------
 t

Allenfalls muss auch die Applikation angehalten werden, da ein weiteres Laufen lassen aus Business Sicht keinen Sinn macht.

Anschliessend haben wir Zeit, den Zeitpunkt des Ups-Queries zu ermitteln.

Nach weiterer Recherche und etwas Reserve legen wir den Zeitpunkt des Ups-Queries auf NACH 2026-07-31 14:10:00+00 fest!

Aufholen bis zum Ups-Query

Dann lassen wir den verzögerten Standby aufholen bis zum Ups-Query:

#
# postgresql.conf
#
# recovery_min_apply_delay = '5min' # Achtung: auskommentieren!
recovery_target_time = '2026-07-31 14:10:00+00'
# recovery_target_xid = '135586'
# recovery_target_lsn = '0/312DF748'
recovery_target_inclusive = off
recovery_target_action = 'pause'

und machen die Standby Datenbank nach Überprüfung zum Primary mit anschliessendem Failover:

postgres=# SELECT pg_promote();
 pg_promote 
------------
 t

In unserem Beispiel mussten wir mit 5 Rows (= 5 Sekunden) Datenverlust leben. Wer es genauer braucht, der muss mehr Zeit in das Bestimmen von recovery_target_* investieren. Wie das genau geht erklären wir hier: PostgreSQL Point-in-Time-Recovery bei Ups-Queries.

Backups mit der MySQL Clone Operation

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 27 Jul 2026 16:04:00 +0200

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.

Dabei hat sich bei uns die Frage gestellt, ob ein physisches remote Backup auch mit der “neuen” MySQL Server Clone-Funktionalität möglich ist, welche mit MySQL 8.0.17 (Juli 2019) dazu gekommen ist.

Mit der MySQL Clone-Operation kann sowohl eine lokale als auch eine remote Kopie der Datenbank erstellt werden. Die ursprüngliche Idee für dieses Feature war wahrscheinlich, Knoten im InnoDB Cluster automatisiert zu erstellen (analog zum Percona XtraDB Cluster SST).

Die bei der Clone-Operation verwendete Terminologie:

Donor (Geber, Quell-Datenbank der Daten)
Recipient (Empfänger, Ziel der Daten(-Bank))

Die Clone-Operation wird vom Recipient aus gestartet. Die Daten können ins eigene, alternativ aber auch in ein anderes Verzeichnis geclont werden.

Vorbereitungen

Das Plugin muss sowohl auf dem Donor als auch auf dem Recipient installiert sein.

SQL> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
Query OK, 0 rows affected (0.01 sec)

SQL> SELECT PLUGIN_NAME, PLUGIN_STATUS
 FROM INFORMATION_SCHEMA.PLUGINS
 WHERE PLUGIN_NAME = 'clone'
;
+-------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------+---------------+
| clone | ACTIVE |
+-------------+---------------+

Wenn das Laden des Plugins beim Neustart erzwungen werden soll, muss es wie folgt in der MySQL Konfigurationsdatei (my.cnf) konfiguriert werden:

[mysqld]
plugin_load_add = mysql_clone.so
clone = FORCE_PLUS_PERMANENT

Lokales Backup mittels Clone

Diese Variante kann als Ersatz einer physischen Backup Lösung (xtrabackup oder MySQL Enterprise Backup (mysql_backup)) dienen. Auf der Datenbank, welche in diesem Fall als Recipient agiert, wird folgender Befehl ausgeführt:

SQL> CLONE LOCAL DATA DIRECTORY = '/mnt/backup/mysql_clone';

Was bei der Clone-Operation noch fehlt sind:

Die ganzen TLS Schlüssel (*.pem Files).
Die Datei auto.cnf welche die server_uuid enthält.
Die Datei mysqld-auto.cnf welche dynamisch geänderte, persistierte Server Konfigurationsvariablen enthält.
Die mysql_upgrade_history.
Die MySQL Konfigurationsdatei (my.cnf) sowie
die Binary Logs.

$ cp ${datadir}/*auto.cnf ${datadir}/mysql_upgrade_history ${datadir}/*.pem /mnt/backup/mysql_clone/

Das Wiederherstellen der Datenbank ist recht einfach:

$ systemctl stop mysql
$ rm -rf ${datadir}/*
$ cp -a /mnt/backup/mysql_clone/* ${datadir}/
$ chown -R mysql: ${datadir}/*
$ systemctl start mysql

Der Ordner #clone wird durch die Clone-Operation erstellt und kann ignoriert, darf aber nicht gelöscht werden.

$ ls -lad /mnt/backup/mysql_clone/*
...
drwxr-x--- 2 dba dba 4096 Jul 27 14:52 '#clone'
...

Er wird beim Starten der MySQL Datenbank automatisch entfernt. Wenn man ihn trotzdem löscht erhält man folgende Fehlermeldungen:

[System] [MY-013576] [InnoDB] InnoDB initialization has started.
[System] [MY-013577] [InnoDB] InnoDB initialization has ended.
mysqld: Can't create/write to file './performance_schema/clone_status_385.sdi' (OS errno 2 - No such file or directory)
mysqld: Can't create file './performance_schema/clone_status_385.sdi' (errno: 2 - No such file or directory)
[ERROR] [MY-013272] [Clone] Plugin Clone reported: 'Client: PFS table creation failed.'
[ERROR] [MY-010202] [Server] Plugin 'clone' init function returned error.

Die für das Point-in-Time-Recovery erforderliche Binary Log Position kann wie folgt ermittelt werden:

SQL> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
+-------------------------------+-----------------+
| BINLOG_FILE | BINLOG_POSITION |
+-------------------------------+-----------------+
| boss_percona-84_binlog.000003 | 1231898 |
+-------------------------------+-----------------+

Remote Backup mittels Clone

Um einen remote Backup mittels der Clone-Funktionalität erstellen zu können braucht es eine minimal funktionale MySQL Datenbank auf dem remote System. Ein simpler Prozess/ein simples Tool reicht dazu leider nicht.

Auf dem Donor braucht es einen User mit den folgenden Privilegien:

SQL> CREATE USER 'backup_user'@'%' IDENTIFIED BY 'secret';
SQL> GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'%';

Zudem muss auf dem Recipient noch der mögliche Donor eingetragen werden:

SQL> SET GLOBAL clone_valid_donor_list = '192.168.1.129:3306';

Dann erfolgt das Backup remote wie folgt:

SQL> CLONE INSTANCE FROM 'backup_user'@'192.168.1.129':3306 IDENTIFIED BY 'secret'
DATA DIRECTORY = '/mnt/backup/mysql_clone';

Die weiter oben beschriebenen, noch fehlenden Dateien, müssen jetzt ebenfalls noch irgendwie kopiert werden:

$ scp mysql@192.168.1.129:${datadir}/*auto.cnf /mnt/backup/mysql_clone/
$ scp mysql@192.168.1.129:${datadir}/mysql_upgrade_history /mnt/backup/mysql_clone/
$ scp mysql@192.168.1.129:${datadir}/*.pem /mnt/backup/mysql_clone/

Das Wiederherstellen der Datenbank erfolgt analog zur Beschreibung oben.

Fazit

Die MySQL Clone-Operation ist ein cooles Feature, welches ich lange vernachlässigt habe, weil mir nicht in den Sinn kam, dass man es auch für Backzwecke nutzen könnte.

Es würde mich nicht wundern, wenn die MySQL Entwickler nach PostgreSQL pg_basebackup geschielt haben, als sie dieses Feature implementiert haben.

In MariaDB fehlt dieses Feature leider, meines Wissens, noch gänzlich. Schade!

Quellen

Allgemein: The Clone Plugin
Für das Clone-Backup gibt es einige wenige, minimale Einschränkungen, welche hier beschrieben sind: Clone Plugin Limitations.
Das Überwachen des Clone-Backups ist hier beschrieben: Monitoring Cloning Operations.
Das Tuning des Clone-Backups ist hier beschrieben: Clone System Variable Reference
Arunjith Aravindan, Percona, 2023-08-08: Provisioning Replication With Clone Plugin

PostgreSQL Point-in-Time-Recovery bei Ups-Queries

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 22 Jul 2026 07:26:00 +0200

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.

If you want to recover to some previous point in time (say, right before the junior DBA dropped your main transaction table), just specify the required stopping point. You can specify the stop point, known as the “recovery target”, either by date/time, named restore point or by completion of a specific transaction ID. As of this writing only the date/time and named restore point options are very usable, since there are no tools to help you identify with any accuracy which transaction ID to use. [ 1 ]

In dem Universum, aus dem ich komme, kennt man das anders. Hier ist es absolut kein Problem ein Point-in-Time-Recovery auf ein Statement oder eine Transaktion genau zu machen. Sofern man sein Handwerk beherrscht.

Jetzt sticht mich aber der Hafer, ob das in dieser, für mich neuen Welt, nicht auch geht…?

Die Testumgebung

Wie aus unseren Schulungen bekannt, machen wir solche Experimente auf unserer test Tabelle immer unter Last (insert_test.sh):

test=# DELETE FROM test WHERE id BETWEEN 10 AND 20;
DELETE 11

Der Alarm

Jetzt kommt die Meldung an den DBA: “Ups! Es ist etwas kaputt gegangen! Kannst Du das bitte wieder reparieren?”

Welche Informationen brauchen wir also, um hier helfen zu können?

Wann ist es, möglichst genau, kaputt gegangen?
- Am 22. Juli, ca. 10:55/CEST ➜ Achtung: PostgreSQL scheint hier immer in UTC zu arbeiten, also: 08:55/UTC.
Wie, mit welchem Statement und auf welche Datenbank ist es kaputt gegangen?
- delete from test where id between 10 and 20
- Datenbank: test
- Wie viele Rows wurden (ungefähr) gelöscht?

Neben den üblichen Diskussionen über Datenbank stilllegen, Applikation stilllegen, etc. damit nicht noch mehr Unheil angerichtet wird, geht es jetzt darum, wie man die Datenbank wieder in den Zustand von vor dem Ups-Query bringt.

Vorbereitungen

Um herauszufinden, wo GENAU wir beim Point-in-Time-Recovery stoppen wollen, brauchen wir die archivierten WAL Files. Und mit dem Tool pg_waldump gucken wir dann in die WAL Files rein.

Auf noch “aktive” WAL Files sollten wir nicht zugreifen,

Can give wrong results when the server is running. [ 2 ]

das gibt potentiell falsche Resultate und Fehler:

$ pg_waldump 000000010000000000000033 >/dev/null
pg_waldump: error: error in WAL record at 0/330B6CF8: invalid record length at 0/330B6D20: expected at least 24, got 0

$ pg_waldump 000000010000000000000034 >/dev/null
pg_waldump: error: could not find a valid record after 0/34000000

Um das sicher zu stellen rotieren wir das aktuelle WAL File weg, damit es archiviert wird:

postgres=# SELECT pg_switch_wal();
 pg_switch_wal 
---------------
 0/3228AB50

Zuerst wollen wir wissen, welche WAL Files in dem betreffendem Zeitraum in Betracht kommen (Achtung: Server läuft ebenfalls in UTC!):

$ PGDATA='/var/lib/postgresql/18/main'
$ WALARCHIVE='/mnt/backup/wal_archive'
$ PATH="${PATH}:/usr/lib/postgresql/18/bin"

$ ll ${WALARCHIVE}/????????????????????????
-rw------- 1 postgres postgres 16777216 Jul 22 08:32 /mnt/backup/wal_archive/00000001000000000000002F
-rw------- 1 postgres postgres 16777216 Jul 22 08:47 /mnt/backup/wal_archive/000000010000000000000030
-rw------- 1 postgres postgres 16777216 Jul 22 09:02 /mnt/backup/wal_archive/000000010000000000000031
-rw------- 1 postgres postgres 16777216 Jul 22 09:11 /mnt/backup/wal_archive/000000010000000000000032

Etwas genauer sehen wir es, wen wir in die WAL Files reinschauen (wahrscheinlich geht das eleganter?):

$ for file in ${WALARCHIVE}/???????????????????????? ; do
 echo ${file}
 pg_waldump ${file} | head | grep COMMIT
done

/mnt/backup/wal_archive/000000010000000000000030
rmgr: Transaction len (rec/tot): 34/ 34, tx: 109112, lsn: 0/300000E0, prev 0/300000A0, desc: COMMIT 2026-07-22 08:32:31.317115 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 109113, lsn: 0/300001C0, prev 0/30000180, desc: COMMIT 2026-07-22 08:32:31.368472 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 109114, lsn: 0/300002A0, prev 0/30000260, desc: COMMIT 2026-07-22 08:32:31.427410 UTC
/mnt/backup/wal_archive/000000010000000000000031
rmgr: Transaction len (rec/tot): 34/ 34, tx: 127114, lsn: 0/31001D78, prev 0/31000FF8, desc: COMMIT 2026-07-22 08:47:31.912547 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 127115, lsn: 0/31001E58, prev 0/31001E18, desc: COMMIT 2026-07-22 08:47:31.971700 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 127116, lsn: 0/31001F38, prev 0/31001EF8, desc: COMMIT 2026-07-22 08:47:32.026471 UTC
/mnt/backup/wal_archive/000000010000000000000032
rmgr: Transaction len (rec/tot): 34/ 34, tx: 145081, lsn: 0/320000E0, prev 0/320000A0, desc: COMMIT 2026-07-22 09:02:31.648356 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 145082, lsn: 0/320001C0, prev 0/32000180, desc: COMMIT 2026-07-22 09:02:31.689970 UTC
rmgr: Transaction len (rec/tot): 34/ 34, tx: 145083, lsn: 0/320002A0, prev 0/32000260, desc: COMMIT 2026-07-22 09:02:31.749528 UTC

Wenn die Zeitangabe zur Katastrophe stimmt (08:55/CEST), dann müsste das Statement in WAL 000000010000000000000031 liegen…

Zur Sicherheit machen wir einen kurzen Check:

$ pg_waldump ${WALARCHIVE}/000000010000000000000031 | grep DELETE
rmgr: Heap len (rec/tot): 59/ 8179, tx: 135586, lsn: 0/312DF748, prev 0/312DF720, desc: DELETE xmax: 135586, off: 10, infobits: [KEYS_UPDATED], flags: 0x01, blkref #0: rel 1663/21506/21508 blk 0 FPW
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1758, prev 0/312DF748, desc: DELETE xmax: 135586, off: 11, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1790, prev 0/312E1758, desc: DELETE xmax: 135586, off: 12, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E17C8, prev 0/312E1790, desc: DELETE xmax: 135586, off: 13, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1800, prev 0/312E17C8, desc: DELETE xmax: 135586, off: 14, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1838, prev 0/312E1800, desc: DELETE xmax: 135586, off: 15, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1870, prev 0/312E1838, desc: DELETE xmax: 135586, off: 16, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18A8, prev 0/312E1870, desc: DELETE xmax: 135586, off: 17, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18E0, prev 0/312E18A8, desc: DELETE xmax: 135586, off: 18, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1918, prev 0/312E18E0, desc: DELETE xmax: 135586, off: 19, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1950, prev 0/312E1918, desc: DELETE xmax: 135586, off: 20, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0

Glück gehabt! Da gibt es DELETEs drin und zwar genau 11! Wir könnten also schon nahe dran sein…

Um genauer filtern zu können brauchen wir jetzt noch:

die OID des Tablespaces
die OID der Datenbank
die OID der Tabelle

postgres=# SELECT oid, spcname AS tablespace, spcowner::regrole AS owner
 FROM pg_tablespace
;
 oid | tablespace | owner 
------+------------+----------
 1663 | pg_default | postgres
 1664 | pg_global | postgres

postgres=# SELECT oid, datname AS database
 FROM pg_database
 WHERE oid = 21506
;
 oid | database 
-------+-----------
 5 | postgres
 16388 | enswitch
 1 | template1
 4 | template0
 21498 | oli
 21506 | test

postgres=# \connect test
test=# SELECT c.oid, ns.nspname AS schema, c.relname AS object_name, c.relkind
 FROM pg_class AS c
 JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
 WHERE c.relkind = 'r' -- Ordinary Table
 AND c.relname = 'test'
;
 oid | schema | object_name | relkind 
-------+--------+-------------+---------
 21508 | public | test | r

Jetzt können wir auf Tabelle genau filtern:

$ pg_waldump --relation=1663/21506/21508 --rmgr=Heap ${WALARCHIVE}/000000010000000000000031 | grep DELETE
rmgr: Heap len (rec/tot): 59/ 8179, tx: 135586, lsn: 0/312DF748, prev 0/312DF720, desc: DELETE xmax: 135586, off: 10, infobits: [KEYS_UPDATED], flags: 0x01, blkref #0: rel 1663/21506/21508 blk 0 FPW
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1758, prev 0/312DF748, desc: DELETE xmax: 135586, off: 11, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1790, prev 0/312E1758, desc: DELETE xmax: 135586, off: 12, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E17C8, prev 0/312E1790, desc: DELETE xmax: 135586, off: 13, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1800, prev 0/312E17C8, desc: DELETE xmax: 135586, off: 14, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1838, prev 0/312E1800, desc: DELETE xmax: 135586, off: 15, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1870, prev 0/312E1838, desc: DELETE xmax: 135586, off: 16, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18A8, prev 0/312E1870, desc: DELETE xmax: 135586, off: 17, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18E0, prev 0/312E18A8, desc: DELETE xmax: 135586, off: 18, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1918, prev 0/312E18E0, desc: DELETE xmax: 135586, off: 19, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1950, prev 0/312E1918, desc: DELETE xmax: 135586, off: 20, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0

Das gibt jetzt genau die 11 Rows auf der Tabelle test.

Jetzt schauen wir das Ganze mit dem Betrachter unserer Wahl noch etwas genauer an (am besten Filtern auf LSN). Wir sehen, die Transaktion vorher und unsere Transaktion bis zum COMMIT und das ganze als rückwärts-verkettete Liste (prev ➜ lsn)?

rmgr: Transaction len (rec/tot): 34/ 34, tx: 135585, lsn: 0/312DF720, prev 0/312DF6E0, desc: COMMIT 2026-07-22 08:54:34.033961 UTC
rmgr: Heap len (rec/tot): 59/ 8179, tx: 135586, lsn: 0/312DF748, prev 0/312DF720, desc: DELETE xmax: 135586, off: 10, infobits: [KEYS_UPDATED], flags: 0x01, blkref #0: rel 1663/21506/21508 blk 0 FPW
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1758, prev 0/312DF748, desc: DELETE xmax: 135586, off: 11, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1790, prev 0/312E1758, desc: DELETE xmax: 135586, off: 12, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E17C8, prev 0/312E1790, desc: DELETE xmax: 135586, off: 13, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1800, prev 0/312E17C8, desc: DELETE xmax: 135586, off: 14, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1838, prev 0/312E1800, desc: DELETE xmax: 135586, off: 15, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1870, prev 0/312E1838, desc: DELETE xmax: 135586, off: 16, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18A8, prev 0/312E1870, desc: DELETE xmax: 135586, off: 17, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E18E0, prev 0/312E18A8, desc: DELETE xmax: 135586, off: 18, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1918, prev 0/312E18E0, desc: DELETE xmax: 135586, off: 19, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Heap len (rec/tot): 54/ 54, tx: 135586, lsn: 0/312E1950, prev 0/312E1918, desc: DELETE xmax: 135586, off: 20, infobits: [KEYS_UPDATED], flags: 0x00, blkref #0: rel 1663/21506/21508 blk 0
rmgr: Transaction len (rec/tot): 34/ 34, tx: 135586, lsn: 0/312E1988, prev 0/312E1950, desc: COMMIT 2026-07-22 08:54:34.052628 UTC

Unsere Ups-Query Transaktion hat also die XID 135586 und fängt bei der LSN 0/312DF748 an. Da wir ja die Transaktion beim Recovery NICHT mehr haben wollen, ist das Recovery dann exklusiv!

Somit hätten wir also bereits die recovery_target Informationen beisammen:

#
# postgres.conf
#
recovery_target_xid = '135586'
recovery_target_lsn = '0/312DF748'
recovery_target_inclusive = off

Recovery zur XID

Jetzt können wir das Point-in-Time-Recovery mit XID als Target ausführen. Das sieht dann im Log wie folgt aus:

LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG: database system was interrupted; last known up at 2026-07-21 14:21:59 UTC
cp: cannot stat '/mnt/backup/wal_archive/00000002.history': No such file or directory
LOG: starting backup recovery with redo LSN 0/21000108, checkpoint LSN 0/2100BAF0, on timeline ID 1
LOG: restored log file "000000010000000000000021" from archive
LOG: starting point-in-time recovery to XID 135586
LOG: redo starts at 0/21000108
LOG: restored log file "000000010000000000000022" from archive
LOG: completed backup recovery with redo LSN 0/21000108 and end LSN 0/2100C070
LOG: consistent recovery state reached at 0/2100C070
LOG: database system is ready to accept read-only connections
LOG: restored log file "000000010000000000000023" from archive
LOG: restored log file "000000010000000000000024" from archive
LOG: restored log file "000000010000000000000025" from archive
LOG: restored log file "000000010000000000000026" from archive
LOG: restored log file "000000010000000000000027" from archive
LOG: restored log file "000000010000000000000028" from archive
LOG: restored log file "000000010000000000000029" from archive
LOG: restored log file "00000001000000000000002A" from archive
LOG: restored log file "00000001000000000000002B" from archive
LOG: restored log file "00000001000000000000002C" from archive 
LOG: restored log file "00000001000000000000002D" from archive
LOG: restored log file "00000001000000000000002E" from archive
LOG: restored log file "00000001000000000000002F" from archive
LOG: restored log file "000000010000000000000030" from archive
LOG: restored log file "000000010000000000000031" from archive
LOG: recovery stopping before commit of transaction 135586, time 2026-07-22 08:54:34.052628+00
LOG: pausing at the end of recovery
HINT: Execute pg_wal_replay_resume() to promote.

Dann prüfen wir zuerst, ob das Ups-Query Rückgängig gemacht wurde und allenfalls, bis wohin die Daten noch/wieder da sind. Wenn das Resultat zufriedenstellend ist kann die Datenbank wieder aus dem Recovery Mode in Primary Mode promoted werden:

test=# SELECT pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t

test=# SELECT pg_promote();
 pg_promote 
------------
 t

Ein Blick ins Log zeigt uns, dass alles geklappt hat:

LOG: received promote request
LOG: redo done at 0/312E1988 system usage: CPU: user: 0.12 s, system: 0.07 s, elapsed: 169.82 s
LOG: last completed transaction was at log time 2026-07-22 08:54:34.033961+00
cp: cannot stat '/mnt/backup/wal_archive/00000002.history': No such file or directory 
LOG: selected new timeline ID: 2
cp: cannot stat '/mnt/backup/wal_archive/00000001.history': No such file or directory 
LOG: archive recovery complete
LOG: checkpoint starting: force
LOG: database system is ready to accept connections

Recovery zur LSN

Ob das Ganz mit LSN auch funktioniert, wollten wir natürlich ebenfalls ausprobieren. Das sieht dann im Log wie folgt aus:

LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG: database system was interrupted; last known up at 2026-07-21 14:21:59 UTC
cp: cannot stat '/mnt/backup/wal_archive/00000002.history': No such file or directory
LOG: starting backup recovery with redo LSN 0/21000108, checkpoint LSN 0/2100BAF0, on timeline ID 1
LOG: restored log file "000000010000000000000021" from archive
LOG: starting point-in-time recovery to WAL location (LSN) "0/312DF748"
LOG: redo starts at 0/21000108
LOG: restored log file "000000010000000000000022" from archive
LOG: completed backup recovery with redo LSN 0/21000108 and end LSN 0/2100C070
LOG: consistent recovery state reached at 0/2100C070
LOG: database system is ready to accept read-only connections
LOG: restored log file "000000010000000000000023" from archive
LOG: restored log file "000000010000000000000024" from archive
LOG: restored log file "000000010000000000000025" from archive
LOG: restored log file "000000010000000000000026" from archive
LOG: restored log file "000000010000000000000027" from archive
LOG: restored log file "000000010000000000000028" from archive
LOG: restored log file "000000010000000000000029" from archive
LOG: restored log file "00000001000000000000002A" from archive
LOG: restored log file "00000001000000000000002B" from archive
LOG: restored log file "00000001000000000000002C" from archive 
LOG: restored log file "00000001000000000000002D" from archive
LOG: restored log file "00000001000000000000002E" from archive
LOG: restored log file "00000001000000000000002F" from archive
LOG: restored log file "000000010000000000000030" from archive
LOG: restored log file "000000010000000000000031" from archive
LOG: recovery stopping before WAL location (LSN) "0/312DF748"
LOG: pausing at the end of recovery
HINT: Execute pg_wal_replay_resume() to promote.

Und dann, nach Prüfen und Promoten geht es wie folgt weiter:

LOG: received promote request 
LOG: redo done at 0/312DF748 system usage: CPU: user: 0.13 s, system: 0.05 s, elapsed: 90.70 s
LOG: last completed transaction was at log time 2026-07-22 08:54:34.033961+00
cp: cannot stat '/mnt/backup/wal_archive/00000002.history': No such file or directory 
LOG: selected new timeline ID: 2
cp: cannot stat '/mnt/backup/wal_archive/00000001.history': No such file or directory 
LOG: archive recovery complete
LOG: checkpoint starting: force
LOG: database system is ready to accept connections

Nacharbeiten

Ob und wie man die Daten die NACH dem Ups-Query angefallen sind, retten kann und will, ist dann noch mal eine ganz andere Geschichte…

Zur Sicherheit: Die betroffene Datenbank vor dem Restore/Recovery noch mal wegsichern, vielleicht können oder müssen wir da noch Daten rausfieseln?

Datenbank Index Optimierer

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 15 Jul 2026 11:54:00 +0200

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…

Was wollen wir den genau überprüfen?

Tabellen ohne Primary Key
Doppelte Indices
Teilweise redundante Indices
Ungenutzte Indices

MariaDB, MySQL und Percona Server

Tabellen ohne Primary Key

SQL> SELECT DISTINCT t.table_schema, t.table_name
 FROM information_schema.tables AS t
 LEFT JOIN information_schema.columns AS c ON t.table_schema = c.table_schema AND t.table_name = c.table_name
 AND c.column_key = "PRI"
 WHERE t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema')
 AND c.table_name IS NULL AND t.table_type NOT IN('VIEW', 'SEQUENCE')
 AND t.table_schema = 'testtest'
;
+--------------+------------+
| table_schema | table_name |
+--------------+------------+
| testtest | archived |
+--------------+------------+
1 row in set

Quelle: Tables without a Primary Key

Doppelte Indices

SQL> SELECT table_name, redundant_index_name, redundant_index_columns, dominant_index_name, dominant_index_columns, sql_drop_index
 FROM sys.schema_redundant_indexes
 WHERE redundant_index_columns = dominant_index_columns
 AND table_schema = 'testtest'
;
+------------+----------------------+-------------------------+---------------------+------------------------+------------------------------------------------------+
| table_name | redundant_index_name | redundant_index_columns | dominant_index_name | dominant_index_columns | sql_drop_index |
+------------+----------------------+-------------------------+---------------------+------------------------+------------------------------------------------------+
| archived | dupl2 | category_id | dupl1 | category_id | ALTER TABLE `testtest`.`archived` DROP INDEX `dupl2` |
+------------+----------------------+-------------------------+---------------------+------------------------+------------------------------------------------------+
1 row in set

Quelle: Duplicate and redundant indices

Teilweise redundante Indices

SQL> SELECT table_name, redundant_index_name, redundant_index_columns, dominant_index_name, dominant_index_columns, sql_drop_index
 FROM sys.schema_redundant_indexes
 WHERE table_schema = 'testtest'
;
+-------------------+----------------------+-------------------------+---------------------+---------------------------------+-------------------------------------------------------------------+
| table_name | redundant_index_name | redundant_index_columns | dominant_index_name | dominant_index_columns | sql_drop_index |
+-------------------+----------------------+-------------------------+---------------------+---------------------------------+-------------------------------------------------------------------+
| access | customer | customer | customer_2 | customer,callerid_internal | ALTER TABLE `testtest`.`access` DROP INDEX `customer` |
| access | customer | customer | customer_3 | customer,callerid_external | ALTER TABLE `testtest`.`access` DROP INDEX `customer` |
| active_customers | uniqueid | uniqueid | PRIMARY | uniqueid,scustomer | ALTER TABLE `testtest`.`active_customers` DROP INDEX `uniqueid` |
| analytics_include | analytics | analytics | PRIMARY | analytics,feature,dtype,dnumber | ALTER TABLE `testtest`.`analytics_include` DROP INDEX `analytics` |
| archived | dupl2 | category_id | dupl1 | category_id | ALTER TABLE `testtest`.`archived` DROP INDEX `dupl2` |
...
| texts_media | uniqueid | uniqueid | PRIMARY | uniqueid,filename | ALTER TABLE `testtest`.`texts_media` DROP INDEX `uniqueid` |
| unlimited_access | customer | customer | customer_2 | customer,callerid_internal | ALTER TABLE `testtest`.`unlimited_access` DROP INDEX `customer` |
| unlimited_access | customer | customer | customer_3 | customer,callerid_external | ALTER TABLE `testtest`.`unlimited_access` DROP INDEX `customer` |
+-------------------+----------------------+-------------------------+---------------------+---------------------------------+-------------------------------------------------------------------+
26 rows in set

Quelle: Duplicate and redundant indices

Ungenutzte Indices

SQL> SELECT object_name, index_name
 FROM sys.schema_unused_indexes
 WHERE object_schema = 'testtest'
;
+------------------------+------------------------+
| object_name | index_name |
+------------------------+------------------------+
| access | customer_3 |
| access | customer_2 |
| actions | class |
| actions | action |
| active | channel |
...
| urls | customer |
| voucher_batches | customer |
| vouchers | batch |
+------------------------+------------------------+
413 rows in set

Achtung:

Bei MariaDB muss das PERFORMANCE_SCHEMA zuerst eingeschaltet werden.
Die Informationen sind korrekt seit dem letzten Datenbank-Neustart. Wurde ein Index das letzte mal VOR dem letzten Neustart genutzt, wir er hier als ungenutzt angezeigt.

Quelle: Unused indexes

Und jetzt mit PostgreSQL

Tabellen ohne Primary Key

SQL> SELECT tab.table_schema, tab.table_name
 FROM information_schema.tables tab
 LEFT JOIN information_schema.table_constraints tco
 ON tab.table_schema = tco.table_schema
 AND tab.table_name = tco.table_name 
 AND tco.constraint_type = 'PRIMARY KEY'
 WHERE tab.table_type = 'BASE TABLE'
 AND tab.table_schema NOT IN ('pg_catalog', 'information_schema')
 AND tco.constraint_name IS NULL
 ORDER BY table_schema, table_name
;
 table_schema | table_name 
--------------+------------
 public | archived
(1 row)

Quelle: Find tables without primary keys (PKs) in PostgreSQL database

Doppelte Indices

Basierend auf dem MySQL sys Schema:

SQL> WITH schema_flattened_keys AS (
 SELECT sai.relid, sai.indexrelid
 , sai.schemaname AS table_schema, sai.relname AS table_name, sai.indexrelname AS index_name
 , CASE pi.indisunique WHEN 'f' THEN 1 ELSE 0 END AS non_unique
 , index_columns.columns AS index_columns
 FROM pg_stat_all_indexes AS sai
 JOIN pg_index AS pi ON pi.indexrelid = sai.indexrelid
 JOIN (
 SELECT attrelid, string_agg(attname, ',' ORDER BY attnum ASC) AS columns
 FROM pg_attribute GROUP BY attrelid
 ) AS index_columns ON index_columns.attrelid = sai.indexrelid
 WHERE sai.schemaname NOT IN ('pg_toast', 'pg_catalog')
)
SELECT redundant_keys.table_schema AS table_schema, redundant_keys.table_name AS table_name, redundant_keys.index_name AS redundant_index_name
 , redundant_keys.index_columns AS redundant_index_columns, redundant_keys.non_unique AS redundant_index_non_unique
 , dominant_keys.index_name AS dominant_index_name, dominant_keys.index_columns AS dominant_index_columns, dominant_keys.non_unique AS dominant_index_non_unique
 , CONCAT('ALTER TABLE ', redundant_keys.table_schema, '.', redundant_keys.table_name, ' DROP INDEX ', redundant_keys.index_name, '') AS sql_drop_index
 FROM schema_flattened_keys redundant_keys
 JOIN schema_flattened_keys dominant_keys ON redundant_keys.table_schema = dominant_keys.table_schema AND redundant_keys.table_name = dominant_keys.table_name
 WHERE (redundant_keys.index_name <> dominant_keys.index_name
 AND ((redundant_keys.index_columns = dominant_keys.index_columns)
 AND ((redundant_keys.non_unique > dominant_keys.non_unique) OR (redundant_keys.non_unique = dominant_keys.non_unique))
 )
 OR ((POSITION(CONCAT(redundant_keys.index_columns,',') IN dominant_keys.index_columns) = 1) AND (redundant_keys.non_unique = 1))
 OR ((POSITION(CONCAT(dominant_keys.index_columns,',') IN redundant_keys.index_columns) = 1) AND (dominant_keys.non_unique = 0))
 )
 AND redundant_keys.index_columns = dominant_keys.index_columns
;
 table_schema | table_name | redundant_index_name | redundant_index_columns | redundant_index_non_unique | dominant_index_name | dominant_index_columns | dominant_index_non_unique | sql_drop_index 
--------------+------------+----------------------+-------------------------+----------------------------+---------------------+------------------------+---------------------------+----------------------------------------------
 public | archived | dupl1 | category_id | 1 | dupl2 | category_id | 1 | ALTER TABLE public.archived DROP INDEX dupl1
 public | archived | dupl2 | category_id | 1 | dupl1 | category_id | 1 | ALTER TABLE public.archived DROP INDEX dupl2
(2 rows)

Quelle: Duplicate and redundant indices

Teilweise redundante Indices

Basierend auf dem MySQL sys Schema:

SQL> WITH schema_flattened_keys AS (
 SELECT sai.relid, sai.indexrelid
 , sai.schemaname AS table_schema, sai.relname AS table_name, sai.indexrelname AS index_name
 , CASE pi.indisunique WHEN 'f' THEN 1 ELSE 0 END AS non_unique
 , index_columns.columns AS index_columns
 FROM pg_stat_all_indexes AS sai
 JOIN pg_index AS pi ON pi.indexrelid = sai.indexrelid
 JOIN (
 SELECT attrelid, string_agg(attname, ',' ORDER BY attnum ASC) AS columns
 FROM pg_attribute GROUP BY attrelid
 ) AS index_columns ON index_columns.attrelid = sai.indexrelid
 WHERE sai.schemaname NOT IN ('pg_toast', 'pg_catalog')
)
SELECT redundant_keys.table_schema AS table_schema, redundant_keys.table_name AS table_name, redundant_keys.index_name AS redundant_index_name
 , redundant_keys.index_columns AS redundant_index_columns, redundant_keys.non_unique AS redundant_index_non_unique
 , dominant_keys.index_name AS dominant_index_name, dominant_keys.index_columns AS dominant_index_columns, dominant_keys.non_unique AS dominant_index_non_unique
 , CONCAT('ALTER TABLE ', redundant_keys.table_schema, '.', redundant_keys.table_name, ' DROP INDEX ', redundant_keys.index_name, '') AS sql_drop_index
 FROM schema_flattened_keys redundant_keys
 JOIN schema_flattened_keys dominant_keys ON redundant_keys.table_schema = dominant_keys.table_schema AND redundant_keys.table_name = dominant_keys.table_name
 WHERE (redundant_keys.index_name <> dominant_keys.index_name
 AND ((redundant_keys.index_columns = dominant_keys.index_columns)
 AND ((redundant_keys.non_unique > dominant_keys.non_unique) OR (redundant_keys.non_unique = dominant_keys.non_unique))
 )
 OR ((POSITION(CONCAT(redundant_keys.index_columns,',') IN dominant_keys.index_columns) = 1) AND (redundant_keys.non_unique = 1))
 OR ((POSITION(CONCAT(dominant_keys.index_columns,',') IN redundant_keys.index_columns) = 1) AND (dominant_keys.non_unique = 0))
 )
;
 table_schema | table_name | redundant_index_name | redundant_index_columns | redundant_index_non_unique | dominant_index_name | dominant_index_columns | dominant_index_non_unique | sql_drop_index 
--------------+-----------------------+------------------------------------------+-------------------------+----------------------------+-------------------------------------------------+-----------------------------------------+---------------------------+---------------------------------------------------------------------------------------------
 public | numbers | numbers_customer_idx | customer | 1 | numbers_customer_text_dtype_text_dnumber_idx | customer,text_dtype,text_dnumber | 1 | ALTER TABLE public.numbers DROP INDEX numbers_customer_idx
 public | numbers | numbers_customer_idx | customer | 1 | numbers_customer_fax_dtype_fax_dnumber_idx | customer,fax_dtype,fax_dnumber | 1 | ALTER TABLE public.numbers DROP INDEX numbers_customer_idx
 public | numbers | numbers_customer_idx | customer | 1 | numbers_pkey | customer,stype,snumber | 0 | ALTER TABLE public.numbers DROP INDEX numbers_customer_idx
 public | numbers | numbers_dtype_idx | dtype | 1 | numbers_dtype_dnumber_idx | dtype,dnumber | 1 | ALTER TABLE public.numbers DROP INDEX numbers_dtype_idx
 public | number_callers | number_callers_dtype_idx | dtype | 1 | number_callers_dtype_dnumber_idx | dtype,dnumber | 1 | ALTER TABLE public.number_callers DROP INDEX number_callers_dtype_idx
 public | prefixes | prefixes_customer_idx | customer | 1 | prefixes_customer_dtype_dnumber_idx | customer,dtype,dnumber | 1 | ALTER TABLE public.prefixes DROP INDEX prefixes_customer_idx
 public | number_times | number_times_dtype_idx | dtype | 1 | number_times_dtype_dnumber_idx | dtype,dnumber | 1 | ALTER TABLE public.number_times DROP INDEX number_times_dtype_idx
 public | phones | phones_customer_idx | customer | 1 | phones_customer_callerid_location_idx | customer,callerid_location | 1 | ALTER TABLE public.phones DROP INDEX phones_customer_idx
 public | phones | phones_customer_idx | customer | 1 | phones_customer_callerid_external_idx | customer,callerid_external | 1 | ALTER TABLE public.phones DROP INDEX phones_customer_idx
 public | phones | phones_customer_idx | customer | 1 | phones_customer_callerid_internal_idx | customer,callerid_internal | 1 | ALTER TABLE public.phones DROP INDEX phones_customer_idx
 public | phones_hardware | phones_hardware_phone_idx | phone | 1 | phones_hardware_phone_hardware_address_idx | phone,hardware_address | 0 | ALTER TABLE public.phones_hardware DROP INDEX phones_hardware_phone_idx
 public | speeddials | speeddials_stype_idx | stype | 1 | speeddials_stype_snumber_idx | stype,snumber | 1 | ALTER TABLE public.speeddials DROP INDEX speeddials_stype_idx
 public | speeddials | speeddials_dtype_idx | dtype | 1 | speeddials_dtype_dnumber_idx | dtype,dnumber | 1 | ALTER TABLE public.speeddials DROP INDEX speeddials_dtype_idx
 public | mailbox_destinations | mailbox_destinations_context_mailbox_idx | context,mailbox | 1 | mailbox_destinations_pkey | context,mailbox,dcustomer,dtype,dnumber | 0 | ALTER TABLE public.mailbox_destinations DROP INDEX mailbox_destinations_context_mailbox_idx
 public | outgroup_times | outgroup_times_outgroup_idx | outgroup | 1 | outgroup_times_outgroup_name_idx | outgroup,name | 0 | ALTER TABLE public.outgroup_times DROP INDEX outgroup_times_outgroup_idx
 public | ingroup_times | ingroup_times_ingroup_idx | ingroup | 1 | ingroup_times_ingroup_name_idx | ingroup,name | 0 | ALTER TABLE public.ingroup_times DROP INDEX ingroup_times_ingroup_idx
 public | active_customers | active_customers_uniqueid_idx | uniqueid | 1 | active_customers_pkey | uniqueid,scustomer | 0 | ALTER TABLE public.active_customers DROP INDEX active_customers_uniqueid_idx
 public | access | access_customer_idx | customer | 1 | access_customer_callerid_external_idx | customer,callerid_external | 1 | ALTER TABLE public.access DROP INDEX access_customer_idx
 public | access | access_customer_idx | customer | 1 | access_customer_callerid_internal_idx | customer,callerid_internal | 1 | ALTER TABLE public.access DROP INDEX access_customer_idx
 public | unlimited_access | unlimited_access_customer_idx | customer | 1 | unlimited_access_customer_callerid_external_idx | customer,callerid_external | 1 | ALTER TABLE public.unlimited_access DROP INDEX unlimited_access_customer_idx
 public | unlimited_access | unlimited_access_customer_idx | customer | 1 | unlimited_access_customer_callerid_internal_idx | customer,callerid_internal | 1 | ALTER TABLE public.unlimited_access DROP INDEX unlimited_access_customer_idx
 public | texts | texts_dcustomer_idx | dcustomer | 1 | texts_dcustomer_dtype_dnumber_idx | dcustomer,dtype,dnumber | 1 | ALTER TABLE public.texts DROP INDEX texts_dcustomer_idx
 public | texts_media | texts_media_uniqueid_idx | uniqueid | 1 | texts_media_pkey | uniqueid,filename | 0 | ALTER TABLE public.texts_media DROP INDEX texts_media_uniqueid_idx
 public | number_calleridgroups | number_calleridgroups_dtype_idx | dtype | 1 | number_calleridgroups_dtype_dnumber_idx | dtype,dnumber | 1 | ALTER TABLE public.number_calleridgroups DROP INDEX number_calleridgroups_dtype_idx
 public | analytics_include | analytics_i | analytics | 1 | analytics_include_pkey | analytics,feature,dtype,dnumber | 0 | ALTER TABLE public.analytics_include DROP INDEX analytics_i
 public | archived | dupl1 | category_id | 1 | dupl2 | category_id | 1 | ALTER TABLE public.archived DROP INDEX dupl1
 public | archived | dupl2 | category_id | 1 | dupl1 | category_id | 1 | ALTER TABLE public.archived DROP INDEX dupl2
(27 rows)

Quelle: Duplicate and redundant indices

Ungenutzte Indices

SQL> SELECT relid::regclass AS table, indexrelid::regclass AS index
 , pg_size_pretty(pg_relation_size(indexrelid::regclass)) AS index_size
 , idx_tup_read, idx_tup_fetch, idx_scan
 FROM pg_stat_user_indexes 
 JOIN pg_index USING (indexrelid) 
 WHERE idx_scan = 0 
 AND indisunique IS FALSE
;
 table | index | index_size | idx_tup_read | idx_tup_fetch | idx_scan 
------------------------+-----------------------------------------------------------------+------------+--------------+---------------+----------
 customers | customers_prefix_idx | 16 kB | 0 | 0 | 0
 customers | customers_parent_idx | 16 kB | 0 | 0 | 0
 customers | customers_email_idx | 16 kB | 0 | 0 | 0
 customers | customers_affiliate_customer_idx | 16 kB | 0 | 0 | 0
 customers | customers_bill_ref_idx | 16 kB | 0 | 0 | 0
...
 analytics_include | analytics_i | 8192 bytes | 0 | 0 | 0
 archived | dupl1 | 8192 bytes | 0 | 0 | 0
 archived | dupl2 | 8192 bytes | 0 | 0 | 0
(413 rows)

Quellen:

PG Assistant

An den Swiss PGDay2026(s) hat Bertrand Hartwig sein Tool PG Assistant vorgestellt. In diesem Zusammenhang wollte ich es gleich mal ausprobieren…

Fehlende Primary Keys und doppelte Indices konnte PG Assistant finden. Teilweise redundante Indices oder ungenutzte Indices hat er mir nicht angezeigt, kann aber auch an mir liegen…

PG Assistant: Dashboard / Dev advisor

PG Assistant: Global Advisor / Dev advisor

PG Assistant: Strictly duplicate unused index

Intallation von PG Assistant

$ apt update
$ apt install python3 python3.13-venv unzip pip
$ wget https://github.com/beh74/pgassistant-community/archive/refs/heads/main.zip
$ unzip main.zip 
$ cd pgassistant-community-main/
$ python3 -m venv env
$ source env/bin/activate
$ pip3 install -r requirements.txt
$ export FLASK_APP=run.py
$ flask run --host=0.0.0.0 --port=80

Dann mit dem Web-Browser auf die angezeigte URL verbinden.

In der Datenbank muss ein User angelegt:

SQL> CREATE ROLE pgassistant WITH LOGIN SUPERUSER PASSWORD 'secret';

sowie die pg_hba.conf angepasst werden.

Nachtrag

Ungenutzte Indices findet man mit dem PG Assitant wie folgt: Database Objects ➜ Indexes ➜ Status: Unused ➜ “NO INDEX ACTIVITY”

PG Assistant: Unused Indexes

MariaDB verkürzt Wartungszeitraum von 5 auf 3 Jahre

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 10 Jun 2026 21:37:00 +0200

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…

MariaDB Server LTS Release Wartungszeiträume

Release	GA Datum	EoL Datum	Dauer
12.3	28 May 2026	Jun 2029	3 Jahre
11.8	4 Jun 2025	4 Jun 2028	3 Jahre
11.4	29 May 2024	29 May 2029	5 Jahre
10.11	16 Feb 2023	16 Feb 2028	5 Jahre
10.6	6 Jul 2021	6 Jul 2026	5 Jahre
10.5	24 Jun 2020	24 Jun 2025	5 Jahre
10.4	18 Jun 2019	18 Jun 2024	5 Jahre
10.3	25 May 2018	25 May 2023	5 Jahre
10.2	23 May 2017	23 May 2022	5 Jahre
10.1	17 Oct 2015	17 Oct 2020	5 Jahre
10.0	31 Mar 2014	31 Mar 2019	5 Jahre

Quelle: MariaDB Server long-term release maintenance periods

Ich bin ja mal gespannt, wie das die ganzen Distributionen lösen? Die haben nämlich einen deutlich längeren Wartungszeitraum.

Und wie machen es denn die Mitbewerber, die anderen Datenbanken?

Debian

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years.

Quelle: Debian Long Term Support

Version	Name	Release	ext-LTS	EoL	Dauer
Debian 13	trixie	2025-08-09	2030-07-01	2035-06-30	5 / 10 Jahre
Debian 12	bookworm	2023-06-10	2028-07-01	2033-06-30	5 / 10 Jahre
Debian 11	bullseye	2021-08-14	2026-09-01	2031-06-30	5 / 10 Jahre
Debian 10	buster	2019-06-06	2024-07-01	2029-06-30	5 / 10 Jahre
Debian 9	stretch	2017-06-17	2022-07-01	2027-06-30	5 / 10 Jahre
Debian 8	jessie	2015-04-26	2020-07-01	2025-06-30	5 / 10 Jahre
Debian 7	wheezy	2013-05-04	2018-06-01	2020-06-30	5 / 7 Jahre

Quelle: Extended Long Term Support

Ubuntu

Version	Name	Release	End of Support	EoL	Dauer
Ubuntu 26.04 LTS	Resolute Raccoon	23. April 2026	May 2031	April 2041	5 / 15 Jahre
Ubuntu 24.04 LTS	Noble Numbat	25. April 2024	June 2029	April 2039	5 / 15 Jahre
Ubuntu 22.04 LTS	Jammy Jellyfish	21. April 2022	June 2027	April 2037	5 / 15 Jahre
Ubuntu 20.04 LTS	Focal Fossa	23. April 2020	May 2025	April 2035	5 / 15 Jahre
Ubuntu 18.04 LTS	Bionic Beaver	26. April 2018	June 2023	April 2033	5 / 15 Jahre
Ubuntu 16.04 LTS	Xenial Xerus	21. April 2016	April 2021	April 2031	5 / 15 Jahre
Ubuntu 14.04 LTS	Trusty Tahr	17. April 2014	April 2019	April 2029	5 / 15 Jahre

Quelle: List of releases

Rocky Linux

Release	Codename	Release Date	Active Support End	End of Life	Dauer
Rocky Linux 10	Red Quartz	June 11, 2025	May 31, 2030	May 31, 2035	5 / 10 Jahre
Rocky Linux 9	Blue Onyx	July 14, 2022	May 31, 2027	May 31, 2032	5 / 10 Jahre
Rocky Linux 8	Green Obsidian	May 1, 2021	May 31, 2024	May 31, 2029	3 / 8 Jahre

Quelle: Rocky Linux Release and Version Guide

Oracle / MySQL Releases

Release	GA Date	Premier Support End	Extended Support End	Dauer
MySQL 9.7	Apr 2026	Apr 2031	Apr 2034	5 / 8 Jahre
MySQL 8.4	Apr 2024	Apr 2029	Apr 2032	5 / 8 Jahre
MySQL 8.0	Apr 2018	Apr 2025	Apr 2026	7 Jahre / 8 Jahre
MySQL 5.7	Oct 2015	Oct 2020	Oct 2023	5 Jahre / 8 Jahre
MySQL 5.6	Feb 2013	Feb 2018	Feb 2021	5 Jahre / 8 Jahre
MySQL 5.5	Dec 2010	Dec 2015	Dec 2018	5 Jahre / 8 Jahre
MySQL 5.1	Dec 2008	Dec 2013	Not Available	5 Jahre
MySQL 5.0	Oct 2005	Dec 2011	Not Available	6 Jahre

Quelle: Oracle Lifetime Support Policy

Percona

Percona Distribution for PostgreSQL (PDPG) und Percona Server for MySQL (PS): Mindestens 5 Jahre, wenn ich die Support-Matrix richtig interpretiere…

Quelle: Percona Release Lifecycle Overview

OurSQL / VillageSQL

Noch keine fertige Software vorhanden und somit noch keine Support Policies, sofern mir bekannt. Sofern das überhaupt mal vorgesehen ist?

Quelle: OurSQL und VillageSQL

PostgreSQL

Version	First Release	Final Release	Dauer
18	September 25, 2025	November 14, 2030	5 Jahre
17	September 26, 2024	November 8, 2029	5 Jahre
16	September 14, 2023	November 9, 2028	5 Jahre
15	October 13, 2022	November 11, 2027	5 Jahre
14	September 30, 2021	November 12, 2026	5 Jahre
13	September 24, 2020	November 13, 2025	5 Jahre
12	October 3, 2019	November 21, 2024	5 Jahre
11	October 18, 2018	November 9, 2023	5 Jahre
10	October 5, 2017	November 10, 2022	5 Jahre

Quelle: Versioning Policy

Weitere Quellen

MariaDB 10.6 Changes & Improvements
MariaDB 10.6 is a long-term maintenance stable version. The first stable release was in July 2021, and it will be maintained until July 2026.
MariaDB 10.11 Changes & Improvements
MariaDB 10.11 is a long-term maintenance release series, maintained until February 2028.
MariaDB 11.4 Changes & Improvements
MariaDB 11.4 is a current long-term series, maintained until May 2029.
MariaDB 11.8 Changes & Improvements
MariaDB 11.8 is a long-term release, maintained until June 2028.
MariaDB 12.3 Changes & Improvements
MariaDB 12.3 is a long term release, maintained until June 2029.

Wie lädt man Daten am schnellsten in die Datenbank?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 10 Feb 2026 22:48:00 +0100

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

Hier kurz einige Eckdaten: CPU: 2 Sockel x 24 Kerne x 2 Threads = 96 vCores, 756 G RAM, 2 x 10 Tbyte PCIe SSD im RAID-10 und 7 Tbyte Daten, einige Tausend Mandanten, stark wachsend.

Der aktuelle Durchsatz: 1 M SELECT/min, 56 k INSERT/min, 44 k UPDATE/min , 7 k DELETE/min gemittelt über 30 Tage. Tendenz stark steigend. Applikation und Queries nicht durchgängig optimiert. Datenbank Konfiguration: “state of the art” nicht mit Benchmarks verifiziert. CPU-Auslastung ca. 50% im Schnitt, in der Spitze mehr. I/O System hat noch Luft nach oben.

Der Kunde sammelt Positions- und sonstige Gerätedaten ein und speichert diese in der Datenbank. Also ein klassisches IoT Problem (mit Zeitreihen, Index Clustered Table, etc.).

Die Frage, die er gestellt hat, ist: Wie kriege ich am schnellsten Daten von einer Tabelle (pending data, eine Art Queue) in eine andere Tabelle (final data, pro Mandant) kopiert.

Der Datenfluss sieht in etwa wie folgt aus:

+------------+
| IoT Device |--+
+------------+ \
 \ +-----+
+------------+ \ | AS | +--------------+ Processing +------------+
| IoT Device |------+-->| |-->| Pending data |------------->| Final data |
+------------+ / | 400 | +--------------+ of data +------------+
 / +-----+
+------------+ /
| IoT Device |--+
+------------+

3 verschiedene Varianten, die Daten zu kopieren, standen zur Auswahl.

Variante 1: `INSERT` und `DELETE` (einfachste Form)

Die einfachste Variante ist simples INSERT und DELETE. Diese Variante ist insbesondere darum problematisch, weil MariaDB/MySQL und PostgreSQL per default AUTOCOMMIT eingeschaltet haben (hier, hier, hier und hier).

Damit man sich das ein bisschen besser vorstellen kann, hier etwas Pseudocode dazu:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 foreach ( row ) {
 INSERT INTO final;
 -- implicit COMMIT
 DELETE FROM pending WHERE id = row[id];
 -- implicit COMMIT
 }
}

Wenn wir also 20 k Zeilen umkopieren wollen, verursacht diese Variante: 40 k COMMITs (fsync) und 42 k Netzwerk-Roundtrips!

Variante 2: `START TRANSACTION` und `INSERT` und `DELETE`

Diese Variante wird von versierteren Datenbank-Entwicklern verwendet. Hier der passende Pseudocode dazu:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 foreach ( row ) {
 INSERT INTO final;
 DELETE FROM pending WHERE id = row[id];
 }
 COMMIT;
}

Wenn wir in diesem Beispiel 20 k Zeilen umkopieren wollen verursacht diese Variante nur noch 2 k COMMITs (fsync)! Also 20 mal weniger! Aber dafür 46 k Netzwerk-Roundtrips (10% mehr).

Variante 3: `START TRANSACTION` und optimiertes `INSERT` und `DELETE`

Diese Variante ist programmiertechnisch ein klein wenig anspruchsvoller. Sie wird verwendet, wenn man den Grenzen des Möglich etwas näher kommen will. Hier der Pseudocode dazu:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 INSERT INTO final (), (), (), (), (), (), (), (), (), ();
 DELETE FROM pending WHERE id = IN (...);
 COMMIT;
}

Und diese 3. Variante verursacht bei 20 k Zeilen ebenfalls nur noch 2 k COMMIT’s (fsync), spart sich aber die Schleife über die INSERT und DELETE Statements in der Datenbank. Wir sparen also einerseits Netzwerk Round-Trips (nur noch 10 k) und CPU-Cycles auf der Datenbank (welche sich schlecht skalieren lassen) zum Parsen der Queries.

Test Set-up

Um das Ganze zu testen haben wir ein kleines Script vorbereitet: load_data.php

Vorbereitung und Ausführung mit MariaDB/MySQL

Mit folgenden Befehlen kann man diese Tests selber ausführen:

SQL> CREATE DATABASE test;
SQL> CREATE USER 'app'@'127.0.0.1' IDENTIFIED BY 'secret';
SQL> GRANT ALL ON *.* TO 'app'@'127.0.0.1';

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --clean-up

Die Messwerte kann sich jeder selbst mit dem entsprechenden Test-Skript erarbeiten.

Vorbereitung und Ausführung mit PostgreSQL

Mit folgenden Befehlen kann man diese Tests selber ausführen:

postgres# CREATE DATABASE test;
postgres# CREATE USER app PASSWORD 'secret';
postgres# GRANT ALL ON DATABASE test TO app;
postgres# GRANT ALL ON SCHEMA public TO app;

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --clean-up

Die Messwerte kann sich jeder selbst mit dem entsprechenden Test-Skript erarbeiten.

Resultate

Um unnötige Diskussionen zu vermeiden, haben wir hier “nur” die relative Performance (Laufzeit) aufgeführt, wie es MarkC in letzter Zeit auch macht. Unsere Messwerte können gerne bilateral zur Verfügung stellen. Sie lassen sich aber einfach mit dem Test-Skript selber reproduzieren.

Weniger ist besser:

	Variante 1	Variante 2	Variante 3
MariaDB 11.8, avg(5)	100.0%	7.5%	6.2%
PostgreSQL 19dev, avg(5)	100.0%	11.2%	7.0%

Achtung: Die Werte von MariaDB/MySQL und PostgreSQL lassen sich NICHT direkt vergleichen!

Und hier noch die graphische Auswertung:

Bemerkungen

Mit schnelleren Disks, wäre der Unterschied zwischen 1 und 2/3 wahrscheinlich nicht mehr ganz so gravierend ausgefallen. Tests beim Kunden haben “nur” ca. Faktor 5 (statt Faktor 9 bis 16) unterschied gezeigt.

Es gibt sicher weitere Möglichkeiten, wie man diesen Lade-Vorgang noch optimieren kann. Hier kommen mir in den Sinn:

INSERT INTO ... SELECT * FROM
LOAD DATA INFILE/COPY, wenn möglich
Prepared Statements
Server side Stored Language (SQL/PSM, PL/pgSQL, …) :-(
PDO-Fetch der Resultate?
etc.

Vielleicht sollte ich mich mal um einen Profiler kümmern (Xdebug oder xhprof)?

MariaDB hat das Konzept des dynamisch konfigurierbaren Buffer Pools kaputt gemacht!

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 20:25:00 +0100

Problembeschreibung

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

The innodb_buffer_pool_size configuration option can be set dynamically using a SET statement, allowing you to resize the buffer pool without restarting the server. For example:

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

MariaDB 10.2.2 hat dieses Feature im September 2016 übernommen (Quelle):

InnoDB was merged from MySQL-5.7.14 (XtraDB is disabled in MariaDB-10.2.2 pending a similar merge)

Das Problematische ist einerseits, dass dieses Feature jetzt nicht mehr funktioniert wie bis anhin und nicht mehr funktioniert wie erwartet. Anderseits haben sie das Verhalten im Frühling 2025 innerhalb einer Major Release Serie (LTS) geändert, was meiner Meinung nach ein absolutes no-go ist (Quelle):

From MariaDB 10.11.12 / 11.4.6 / 11.8.2, there are significant changes to the InnoDB buffer pool behavior.

Und zudem ist die Beschreibung dazu recht dürftig (Quelle):

decreasing innodb_buffer_pool_size at runtime does not release memory (MDEV-32339)

reorganise innodb buffer pool (and remove buffer pool chunks) (MDEV-29445)

The Linux memory pressure interface, which could previously not be disabled and could cause performance anomalies, was rewritten and is disabled by default. (MDEV-34863)

Server crashes when resizing default innodb buffer pool after setting innodb-buffer-pool-chunk-size to 1M (MDEV-34677)

Im entsprechende Worklog (MDEV-36197) beschreibt MarkoM zudem ein anderes Verhalten:

innodb_buffer_pool_size_auto_max (my proposal for this task) would set the maximum for the automation (default: 0 to disable the logic).

was meiner Meinung nach wesentlich sinnvoller gewesen wäre.

Wie ging es früher?

Wie ging es früher bei MariaDB und heute immer noch bei MySQL:

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 134217728 |
+-------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = @@innodb_buffer_pool_chunk_size * 128;

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 268435456 |
+-------------------------------+-----------+

Somit alles OK. Funktioniert wie erwartet und wie gewohnt.

Was macht MariaDB heute?

Was passiert heute bei MariaDB:

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = 256*1024*1024;
Query OK, 0 rows affected, 1 warning (0.000 sec)

SQL> show warnings;
+---------+------+----------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------+
| Warning | 1292 | Truncated incorrect innodb_buffer_pool_size value: '268435456' |
+---------+------+----------------------------------------------------------------+

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

Also gar nichts! Nicht mal einen Fehler, nur eine Warnung. Und wenn ich nicht genau schaue, merke ich nicht mal, dass da was nicht geklappt hat.

Im MariaDB Error Log steht:

[Note] InnoDB: Memory pressure event disregarded; innodb_buffer_pool_size=128m, innodb_buffer_pool_size_auto_min=128m

Wenn man dann etwas auf die Suche geht, findet man heraus, das hier etwas geändert hat: Buffer Pool Changes und versucht intuitiv:

SQL> SET GLOBAL innodb_buffer_pool_size_max = 256*1024*1024;
ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size_max' is a read only variable

Geht aber auch nicht.

Das bedeutet, man muss die Datenbank neu starten! Und das möglicherweise genau in dem Augenblick, in welchem man den Neustart eigentlich gar nicht gebrauchen kann und dieses Feature nötig hätte…

In der Doku steht dann auch (Quelle):

Default Value: specified by the initial value of innodb_buffer_pool_size, rounded up to the block size of that variable. See the section about buffer pool changes in MariaDB 10.11.12, 11.4.6, and 11.8.2.

und (Quelle):

If innodb_buffer_pool_size_max is 0 or not specified, it defaults to the innodb_buffer_pool_size value.

Das heisst, ich muss mir wieder vorher Gedanken machen, wie gross ich innodb_buffer_pool_size_max machen soll und kann erst dann nachträglich im Betrieb korrigieren, sollte ich es vergessen oder mich verschätzt haben.

Dies ist meiner Meinung nach ein vollkommener Rückschritt aus betrieblicher Sicht. Wahrscheinlich ist das wieder eine Implementierung für irgendwelche Cloud-only as a Service Lösungen (Enterprise?).

Mein Vorschlage ist: Entweder, wie im MDEV vorgeschlagen: 0 soll dieses Feature ausschalten und das Verhalten wie bisher sein oder aber, der Default-Wert soll auf 75% der RAM-Size gesetzt werden, so wie es innodb_dedicated_server bei MySQL macht.

Ich habe mich erdreistet hier mal einen Bug zu eröffnen: New InnoDB Buffer Pool autosize feature not so optimal implemented.

FedericoR hat mit verdankenswerter Weise noch folgen Link empfohlen: Issues with new buffer pool configuration in MariaDB Minors (10.11.12/13/14, 11.4.6/7/8, 11.8.2/3). Ich schein nich der Einzige zu sein, dem dies Änderung auf diese Art sauer aufgestossen ist…

Wie macht das PostgreSQL?

PostgreSQL ist zur Zeit (noch) nicht in der Lage, shared_buffers dynamisch zu ändern. Der Default ist üblicherweise 128M. Hier gilt die Faustregel, ähnlich wie bei MyISAM, 25 - 40% vom RAM. Das Fehlen dieses Features ist bei PostgreSQL aber wahrscheinlich nicht so gravierend, da sich PostgreSQL stark auf den Filesystem Cache verlässt, ähnlich wie MyISAM.

Quelle: Resource Consumption

Kommentare

Siehe hier.

Wie viel Platz braucht NULL?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 10:36:00 +0100

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!

Und ja, ich weiss, dass wiederspricht den Empfehlungen einiger meiner PostgreSQL Kollegen (hier und hier). In der MySQL-Welt wird eher auf solche Dinge Wert gelegt (Quelle):

Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables

Zudem funktioniert InnoDB ein klein wening anders (Index Clusterd Table und Primary Key in allen Secondary Keys) als PostgreSQL (Heap Table, Indices mit Row Pointer (ctid)).

Aber das ist eigentlich nicht das Thema. Sofort im Anschluss kam er nämlich mit der Frage, ob das AusNULLen von Spalten vom Typ DOUBLE (8 byte, in PostgreSQL-Sprech DOUBLE PRECISION) auch Platzeinsparungen brächte oder ob er die Spalten lieber gleich droppen solle. Meine erste reflexartige Antwort bei DOUBLE war: NULL bringt was, gefolgt von OPTIMIZE TABLE (in PostgreSQL-Sprech VACUUM FULL). Der zweite Gedanke war aber, DOUBLE ist ein Datentyp fixer länger, gilt das mit NULL da auch oder nur bei Datentypen mit variabler Länge? Vorsicht ist die Mutter der Porzelankiste! Liebe zuerst mal das Manual konsultieren…

Und dort steht (Quelle):

Declare columns to be NOT NULL if possible. It makes SQL operations faster, by enabling better use of indexes and eliminating overhead for testing whether each value is NULL. You also save some storage space, one bit per column. If you really need NULL values in your tables, use them. Just avoid the default setting that allows NULL values in every column.

und (Quelle):

The variable-length part of the record header contains a bit vector for indicating NULL columns. … Columns that are NULL do not occupy space other than the bit in this vector. The variable-length part of the header also contains the lengths of variable-length columns. Each length takes one or two bytes, depending on the maximum length of the column. If all columns in the index are NOT NULL and have a fixed length, the record header has no variable-length part.

Versuch mit MariaDB/MySQL

Versuchsaufbau

Irgendwie ist mir das etwas zu komplizert beschrieben. Eine kleine Skizze würde vielleicht helfen? Also machen wir einen Versuch:

SQL> -- DROP TABLE IF EXISTS tracking;

SQL> CREATE TABLE tracking (
 id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
, d0 DOUBLE, d1 DOUBLE, d2 DOUBLE, d3 DOUBLE, d4 DOUBLE
, d5 DOUBLE, d6 DOUBLE, d7 DOUBLE, d8 DOUBLE, d9 DOUBLE
);

SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

Die Tabelle wird sowohl bei MariaDB als auch bei MySQL bei 16 M Rows ca. 1.8 Gbyte gross. Da dieses Informationen im INFORMATION_SCHEMA nur sehr unpräzise angegeben werden schauen wir auf dem Filesystem nach:

MariaDB 11.8:

SQL> system ls -l tracking.ibd
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL 8.4:

SQL> system ls -l tracking.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Defragementieren der Tabelle

Dann “defragmentieren” wir die Tabelle mit dem OPTIMIZE TABLE Befehl:

SQL> OPTIMIZE TABLE tracking;
+---------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------------+----------+----------+-------------------------------------------------------------------+
| test.tracking | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.tracking | optimize | status | OK |
+---------------+----------+----------+-------------------------------------------------------------------+

Achtung: Die Tabelle wir einmal umkopiert! Es braucht also kurzzeitig die doppelte Menge an Diskplatz! Dies können wird schön beobachten während der OPTIMIZE TABLE Befehls läuft:

MariaDB:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 '#sql-alter-d57-8c.frm'
-rw-rw---- 1 mysql mysql 968884224 Feb 7 10:39 '#sql-alter-d57-8c.ibd'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-r----- 1 mysql mysql 369098752 Feb 7 10:40 #sql-ib1594-4164062678.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Das Resultat ist dann aber erstaunlich! Bei MariaDB ist die Tabelle in etwas gleich gross geblieben:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:39 tracking.ibd

Bei MySQL hingegen ist die Tabelle nach dem “defragmentieren” sogar angewachsen und zwar um ca. 14%:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:41 tracking.ibd

Wenn wir den OPTIMIZE TABLE Befehl nochmal ausführen bleibt die Grösse sowohl bei MariaDB als auch MySQL konstant:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:46 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:48 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:48 tracking.ibd

Versuch 1: AusNULLen

Jetzt NULLen wir die Werte aus:

SQL> UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

Nach diesem Schritt sind die Grössen der Dateien sogar noch etwas gewachsen:

MariaDB (+1.3%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:49 tracking.frm
-rw-rw---- 1 mysql mysql 1937768448 Feb 7 11:04 tracking.ibd

MySQL (+0.2%):

-rw-r----- 1 mysql mysql 2202009600 Feb 7 11:04 tracking.ibd

Anschliessend defragemntieren wir die Tabelle erneut mit dem OPTIMIZE TABLE Befehl. Die Tabellen schrumpfen wie erwartet.

MariaDB (auf 23%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:09 tracking.frm
-rw-rw---- 1 mysql mysql 448790528 Feb 7 11:10 tracking.ibd

MySQL (auf 24%):

-rw-r----- 1 mysql mysql 520093696 Feb 7 11:10 tracking.ibd

Ein erneutes OPTIMIZE TABLE bringt anschliessend KEINE Veränderung mehr in der Dateigrösse…

Versuch 2: Löschen der Spalten

Jetzt probieren wir das Ganze nochmal mit dem DROP COLUMN Befehl. Die Ausganglage ist wieder die selbe wie oben beschrieben:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:15 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 11:18 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 1929379840 Feb 7 11:19 tracking.ibd

Nach dem OPTIMIZE TABLE Befehl sehen die Werte ähnlich aus wie im ersten Versuch:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:20 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:21 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:21 tracking.ibd

Ein erneutes OPTIMIZE TABLE bring ebenfalls keine weiteren Veränderungen mehr, wie oben:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:22 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:23 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:24 tracking.ibd

Und jetzt der eigentliche zweite Versuch mit Löschen der Spalten:

SQL> ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Als erstes stellen wir fest, dass der Befehl INSTANTANEOUS ist, als keinerlei Änderung an den Daten vornimmt sondern nur Änderung an den Metadaten. Das ist auf der einen Seite gut, da der Einfluss auf die Applikation dadurch minimal gehalten wird.. Auf der anderen Seite bedeutet das ja auch: Keine Platzersparnis.

Also rücken wir dem Ganzen wieder mit dem OPTIMIZE TABLE Befehl zu Leibe:

MariaDB (auf 93%):

-rw-rw---- 1 mysql mysql 925 Feb 7 11:28 tracking.frm
-rw-rw---- 1 mysql mysql 415236096 Feb 7 11:29 tracking.ibd

MySQL (auf 92%):

-rw-r----- 1 mysql mysql 478150656 Feb 7 11:28 tracking.ibd

Fazit

Sowohl das ausNULLen der Spalten als auch das Löschen der Spalten bringen signifikante Platzersparnis. Wobei das Löschen der Spalten nochmal ca. 7% mehr bringt als das ausNULLen. Wenn es applikatorisch möglich ist, sollte man daher nicht mehr benötigte Spalen löschen, wenn nicht möglich, diese zumindest ausNULLen.

Versuch mit PostgreSQL

Und jetzt schauen wir uns das Ganze noch bei PostgreSQL 19devel an.

Versuchsaufbau

Der Versuchsaufbau erfolgt analog zu MariaDB/MySQL:

postgres=# -- DROP TABLE IF EXISTS tracking;

postgres=# CREATE TABLE tracking (
 id SERIAL PRIMARY KEY
, d0 DOUBLE PRECISION, d1 DOUBLE PRECISION, d2 DOUBLE PRECISION, d3 DOUBLE PRECISION, d4 DOUBLE PRECISION
, d5 DOUBLE PRECISION, d6 DOUBLE PRECISION, d7 DOUBLE PRECISION, d8 DOUBLE PRECISION, d9 DOUBLE PRECISION
);

postgres=# \timing

postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

Zuerst wollen wir mal wissen, wie gross die Tabelle eigentlich geworden ist. PostgreSQL scheint diese Informationen sehr genau zu kennen:

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376856576 | 359 MB | 2340274176 | 2232 MB | 2340798464 | 2232 MB

Dann wollen wir wissen, wo im Filesystem diese Dateien zu finden sind:

postgres=# SELECT oid AS db_oid FROM pg_database WHERE datname = current_database();
 db_oid
--------
 5

postgres=# SELECT oid AS table_oid, relname, relnamespace, relfilenode
 FROM pg_class WHERE relname = 'tracking';
 table_oid | relname | relnamespace | relfilenode
-----------+----------+--------------+-------------
 40965 | tracking | 2200 | 40965

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 WHERE c.relname = 'tracking';
 index_name | index_oid
---------------+-----------
 tracking_pkey | 40970

postgres=# SELECT pg_relation_filepath('tracking');
 pg_relation_filepath
----------------------
 base/5/40965

Tabellen- und Indexgrösse im Filesystem:

$ ls -ltr 40965* 40970*
-rw------- 1 mysql mysql 40960 Feb 7 18:33 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:33 40965_fsm
-rw------- 1 mysql mysql 889675776 Feb 7 18:34 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:34 40965
-rw------- 1 mysql mysql 376856576 Feb 7 18:35 40970

*_fsm bedeutet “free space map”
*_vm bedeutet “visibility map”
*.1 bedeutet 2. Segment des Objekts (Tabelle oder Index)

PostgreSQL scheint per default mit Segmenten von 1 Gbyte Grösse zu arbeiten und im Unterschied zu MariaDB/MySQL (INFORMATION_SCHEMA) sehr genau zu wissen, wie gross seine Dateien sind. Und die Diskrepanz von oben (zwischen tot_rel_siz und tab_and_idx_siz) lässt sich durch die fsm und die vm-Dateien erklären.

Das PostgreSQL Equivalent zum MariaDB/MySQL OPTIMIZE TABLE ist der Befehl VACUUM FULL:

postgres=# VACUUM FULL tracking;

$ ls -ltr
-rw------- 1 mysql mysql 40960 Feb 7 18:39 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:39 40965_fsm
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40965
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 0 Feb 7 18:39 40975

...

-rw------- 1 mysql mysql 49152 Feb 7 18:39 2704
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2703
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2696
-rw------- 1 mysql mysql 65536 Feb 7 18:39 2674
-rw------- 1 mysql mysql 81920 Feb 7 18:39 2673
-rw------- 1 mysql mysql 98304 Feb 7 18:39 2659
-rw------- 1 mysql mysql 139264 Feb 7 18:39 2658
-rw------- 1 mysql mysql 24576 Feb 7 18:39 2619_fsm
-rw------- 1 mysql mysql 163840 Feb 7 18:39 2619
-rw------- 1 mysql mysql 106496 Feb 7 18:39 2608
-rw------- 1 mysql mysql 491520 Feb 7 18:39 1249
-rw------- 1 mysql mysql 122880 Feb 7 18:39 1247
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2662
-rw------- 1 mysql mysql 114688 Feb 7 18:39 1259
-rw------- 1 mysql mysql 16384 Feb 7 18:39 3455
-rw------- 1 mysql mysql 49152 Feb 7 18:39 2663
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 376864768 Feb 7 18:39 40975
-rw------- 1 mysql mysql 0 Feb 7 18:39 40965
-rw------- 1 mysql mysql 0 Feb 7 18:39 40970

Das erste, was man feststellt, ist, dass PostgreSQL ganz viele Dateien anlangt und die “free space map” Datei ist verschwunden. Die Tabellen-Segmente sind dafür, im Unterschied zu MariaDB/MySQL gleich gross geblieben. Zudem sieht man, dass die alte Tabelle “verschwunden” (40965, 40970) und eine neue entstanden (40972 und 40975) ist. Der VACUUM FULL Befehl bei PostgreSQL erstellt also ebenfalls, wie bei MariaDB/MySQL eine Kopie der Daten.

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376864768 | 359 MB | 2340282368 | 2232 MB | 2340282368 | 2232 MB

Um zu verstehen, welche Dateien/Objekte denn sonst noch so alles angelangt wurden, hilft folgendes Query:

postgres=# SELECT c.oid, c.relname, ns.nspname
FROM pg_class AS c
JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 oid | relname | nspname
-------+-----------------------------------+------------
 40965 | tracking | public
 40970 | tracking_pkey | public
 2619 | pg_statistic | pg_catalog
 1247 | pg_type | pg_catalog
 2703 | pg_type_oid_index | pg_catalog
 2704 | pg_type_typname_nsp_index | pg_catalog
 2658 | pg_attribute_relid_attnam_index | pg_catalog
 2659 | pg_attribute_relid_attnum_index | pg_catalog
 2662 | pg_class_oid_index | pg_catalog
 2663 | pg_class_relname_nsp_index | pg_catalog
 3455 | pg_class_tblspc_relfilenode_index | pg_catalog
 2696 | pg_statistic_relid_att_inh_index | pg_catalog
 2673 | pg_depend_depender_index | pg_catalog
 2674 | pg_depend_reference_index | pg_catalog
 1249 | pg_attribute | pg_catalog
 1259 | pg_class | pg_catalog
 2608 | pg_depend | pg_catalog

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid, ns.nspname
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
 WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 index_name | index_oid | nspname
-----------------------------------+-----------+------------
 pg_type_typname_nsp_index | 2704 | pg_catalog
 pg_attribute_relid_attnam_index | 2658 | pg_catalog
 tracking_pkey | 40970 | public
 pg_class_relname_nsp_index | 2663 | pg_catalog
 pg_class_tblspc_relfilenode_index | 3455 | pg_catalog
 pg_type_oid_index | 2703 | pg_catalog
 pg_attribute_relid_attnum_index | 2659 | pg_catalog
 pg_statistic_relid_att_inh_index | 2696 | pg_catalog
 pg_depend_depender_index | 2673 | pg_catalog
 pg_depend_reference_index | 2674 | pg_catalog
 pg_class_oid_index | 2662 | pg_catalog

Versuch 1: AusNULLen

Dann NULLen wir die Spalten bei PostgreSQL ebenfalls aus. Die Sicht aufs Datei-System sparen wir uns ab hier, da PostgreSQL die Dateigrössen ja genau zu kennen scheint, wie wir oben gesehen haben:

postgres=# UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 2695716864 | 2571 MB | 753696768 | 719 MB | 3449413632 | 3290 MB | 3450101760 | 3290 MB

Hier sehen wir, dass die Tabellen-Segmente massiv anwachsen (+37%), was in der PostgreSQL Terminologie als “bloat” bezeichnet wird. Die MVCC Implementierung von PostgreSQL speichert sowohl die alte auch nie neue Version der Row “in-place” also direkt in der Tabelle im Gegensatz zu MariaDB/MySQL welche die alte Version im UNDO Space und die neue Row “in-place” speichert. Auch die Index-Datei vergrössert sich signifikant (+100%). Dazu müssen wir noch weiter forschen, warum das so ist. Zudem wird wieder eine “free space map” erstellt (Differenz zwischen tot_rel_siz und tab_and_idx_siz).

Ein anschliessendes VACUUM FULL verkleinert die Tabelle (auf 28%) und den Index (auf 50%) wieder im Bezug auf die vorherige Grösse:

postgres=# VACUUM FULL tracking;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

und auch in Bezug zur ursprünglichen Grösse wird die Tabelle (auf 38%) und der Index (auf 100%) wieder kleiner. Warum der Index gleich gross geblieben ist und nur die Tabelle geschrumpft ist, muss noch recherchiert werden…

Versuch 2: Löschen der Spalten

Anschliessend werden die Spalten noch mit DROP COLUMN gelöscht.

postgres=# ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Da die Rückmeldung sofort kam, kann davon ausgegangen werden, dass diese Operation ebenfalls instant erfolgt. Leider habe ich auf die Schnelle nichts in der PostgreSQL Dokumentation dazu gefunden.

An der Grösse hat sich nichts signifikant geändert, was bei einer Instant-Operation ja eigentlich auch zu erwarten ist. Dass sich jedoch nach dem VACUUM FULL Befehl die Grösse nicht mehr geändert hat, hat doch ein wenig erstaunt:

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1120010240 | 1068 MB

postgres=# VACUUM FULL tracking;

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

Bemerkungen

Locking bei PostgreSQL funktioniert wie folgt:

VACUUM Nebenläufige DML Befehle sind möglich ähnlich wie beim MariaDB/MySQL OPTIMIZE TABLE Befehl. Das Resultat ist aber nicht ganz das Selbe.
VACUUM FULL verursacht einen ACCESS EXCLUSIVE Lock. Ähnlich wie bei MariaDB/MySQL 5.5 und älter beim OPTIMIZE TABLE Befehl. DML und SELECT Befehle sind NICHT zulässig.

Quellen

Zusatzversuche

Statt 0.0 wurde NULL in die Spalten d0 - d9 abgefüllt. Die Tabelle blieb klein (tot_rel_siz_prtty = 1068 MB). Es lohnt sich also auch bei PostgreSQL NULL statt Dummy-Werte zu speichern.
Die Spalten d0 - d9 wurden mit DOUBLE PRECISION NOT NULL angelegt und die Werte 0.0 abgefüllt. Keinen Effekt: Die Tabelle blieb gross (tot_rel_siz_prtty = 2232 MB).

Jemand löscht meine Shared Memory Segmente!

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sat, 07 Feb 2026 19:58:00 +0100

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

psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
FATAL: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

oder wir sehen ähnliche Meldungen im PostgreSQL Error Log:

ERROR: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

Weil ich ein MariaDB/MySQL Admin bin, kenne ich mich nicht so gut mit Shared Memory Problemen aus (MariaDB/MySQL arbeitet nicht mit Shared Memory). Zum Glück hat uns eine Suche im Internet auf eine Fährte geführt (Quelle). Dort wird vermerkt:

The documentation of systemd states that this only happens for non-system users. Can you check whether your “postgres” user (or whatever you are using) is a system user?

Linux System User

Zuerst musste ich mal herausfinden was ein System User unter Linux überhaupt ist. Eine Antwort habe ich hier gefunden: What’s the difference between a normal user and a system user?.

That is not a technical difference but an organizational decision. E.g. it makes sense to show normal users in a login dialog (so that you can click them instead of having to type the user name) but it wouldn’t to show system accounts (the UIDs under which daemons and other automatic processes run) there.

Der LSB Standard meint dazu: User ID Ranges:

The system User IDs from 0 to 99 should be statically allocated by the system, and shall not be created by applications.
The system User IDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts using useradd.

Auf meinem Ubuntu System sieht das wie folgt aus:

$ grep SYS_ /etc/login.defs
#SYS_UID_MIN 100
#SYS_UID_MAX 999
#SYS_GID_MIN 100
#SYS_GID_MAX 999

Für den PostgreSQL User würde das ja auch stimmen:

$ id postgres
uid=130(postgres) gid=142(postgres) groups=142(postgres),116(ssl-cert)

Da aber die betroffene PostgreSQL Instanz unter unserm myEnv läuft, ist das was anderes:

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

Jetzt haben wir also zwei Möglickeiten:

Wir ändern SYS_UID_MAX und SYS_GID_MAX auf 1001 (einfache Variante).
Oder wir ändern die UID und die GID unseres Users dba auf unter 1000.

Einfache Variante: Ändern von `SYS_UID_MAX` und `SYS_GID_MAX` auf 1001

# /etc/login.defs
SYS_UID_MAX 1001
SYS_GID_MAX 1001

Zur Sicherheit wurde die Maschine neu gebootet. Das ha aber nicht geholfen: Nach kurzer Zeit treten wieder die selber Fehler auf.

Kompliziertere Variante: Ändern der `UID` von 1001 auf 990

$ cat /etc/passwd
...
polkitd:x:997:997:User for polkitd:/:/usr/sbin/nologin
systemd-coredump:x:998:998:systemd Core Dumper:/:/usr/sbin/nologin
tomcat:x:999:999:Apache Tomcat:/:/sbin/nologin
oli:x:1000:1000:Oli Sennhauser,,,:/home/oli:/bin/bash
dba:x:1001:1001:DBA user:/home/dba:/bin/bash
...

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

Dazu müssen alle Prozesse dieses Users gestoppt sein!

$ usermod --uid 990 dba
$ groupmod --gid 990 dba

$ find / -user 1001 -exec chown --no-dereference dba {} \;
$ find / -group 1001 -exec chgrp --no-dereference dba {} \;

Damit scheint das Problem gelöst zu sein!

Zusatzinformationen

Eine weiter oben erwähnte Quelle hat noch empfohlen, beim systemd-logind folgende Parameter zu setzen:

# /etc/systemd/system/systemd-logind.service.d/override.conf
RemoveIPC=no
RuntimeDirectorySize=1%

Diese Massnahme ist jetzt aber nicht mehr notwendig, das es auch ohne diese Änderung funktioniert.

CSV Dateien in die Datenbank laden

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 06 Feb 2026 17:12:00 +0100

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.

Also machte ich mich auf die Suche nach den Koordinaten und wurde beim Bundesamt für Landestopografie (swisstopo) fündig.

Die Daten werden dort als CSV Datei zur Verfügung gestellt. Details hier: Schweizer Ortschafts-Koordinaten.

Wie lädt man jetzt diese Daten in eine Datenbank?

Laden der Daten mit MariaDB/MySQL

MariaDB und MySQL haben dafür den Befehl LOAD DATA INFILE:

SQL> DROP TABLE IF EXISTS wgs84;

SQL> -- SET GLOBAL local_infile = ON; -- Only needed with MySQL

SQL> CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id SMALLINT UNSIGNED
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE
, n DOUBLE
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

SQL> -- TRUNCATE TABLE wgs84;

SQL> LOAD DATA LOCAL INFILE '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
INTO TABLE wgs84
FIELDS TERMINATED BY ';'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES
;
Query OK, 5713 rows affected
Records: 5713 Deleted: 0 Skipped: 0 Warnings: 0

Anschliessend kann man die Daten in der Datenbank abfragen:

SQL> SELECT * FROM wgs84 ORDER BY ortschaftsname LIMIT 5;
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| ortschaftsname | plz4 | zusatzziffer | zip_id | gemeindename | bfs_nr | kantonskuerzel | adressenanteil | e | n | sprache | validity |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| Aadorf | 8355 | 0 | 4672 | Aadorf | 4551 | TG | 96.802 % | 8.903193007810433 | 47.491079014637265 | de | 2008-07-01 |
| Aadorf | 8355 | 0 | 4672 | Elgg | 294 | ZH | 3.198 % | 8.89206766645808 | 47.4933781685032 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Aarau | 4001 | AG | 99.713 % | 8.048148371736266 | 47.38973523857376 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Suhr | 4012 | AG | 0.287 % | 8.059410934099922 | 47.383298214804334 | de | 2008-07-01 |
| Aarau | 5004 | 0 | 2932 | Aarau | 4001 | AG | 100 % | 8.060698546432551 | 47.400587704180744 | de | 2008-07-01 |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
5 rows in set

Bzw. etwas präziser:

SQL> SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
+-------------+-----------+-------------------+--------------------+
| city | city_code | lon | lat |
+-------------+-----------+-------------------+--------------------+
| Aarburg | 4663 | 7.904271716719409 | 47.321443418782955 |
| Aarburg | 4663 | 7.889249714098425 | 47.313536073562474 |
| Aarburg | 4663 | 7.880309179095798 | 47.31255194439023 |
| Adligenswil | 6043 | 8.364849060491428 | 47.07037816052481 |
| Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056 |
| Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134 |
| Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145 |
+-------------+-----------+-------------------+--------------------+
7 rows in set (0.003 sec)

Das ausmisten der Duplikate überlasse ich der geneigten Lesering oder dem geneigten Leser… :-)

Soweit so gut, jetzt zu den Feinheiten:

Unterschiede zwischen MariaDB und MySQL

Das oben beschriebene Verfahren funktioniert einwandfrei bei MariaDB 11.4 und 11.8. Bei MySQL 8.4 gibt es kleine Unterschiede:

Die erste Fehlermeldung, die das Laden verhindert ist diese:

ERROR 3948 (42000): Loading local data is disabled; this must be enabled on both the client and server sides

Sie kann relativ einfach umgangen werden mit dem Befehl:

SQL> SET GLOBAL local_infile = ON;

Beim nächsten Versuch wird man wie folgt scheitern:

ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.

Dieses Problem kann gelöst werden, indem man den MySQL Client wie folgt startet:

$ mysql --local-infile=1 --user=root test

Quellen

MariaDB: LOAD DATA INFILE
MySQL: LOAD DATA Statement

Laden der Daten mit PostgreSQL

PostgreSQL hat hierfür den Befehl COPY ... FROM:

postgres=# DROP TABLE IF EXISTS wgs84;

postgres=# CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id INT
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE PRECISION
, n DOUBLE PRECISION
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

postgres=# -- TRUNCATE TABLE wgs84;

postgres=# COPY wgs84
FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
DELIMITER ';'
CSV HEADER
;
COPY 5713

Auch hier erhalten wir das Resultat wie erwartet in der für PostgreSQL üblichen Form:

postgres=# SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
 city | city_code | lon | lat
-------------+-----------+-------------------+--------------------
 Aarburg | 4663 | 7.904271716719409 | 47.321443418782955
 Aarburg | 4663 | 7.889249714098425 | 47.313536073562474
 Aarburg | 4663 | 7.880309179095798 | 47.31255194439023
 Adligenswil | 6043 | 8.36487538940682 | 47.07037794822416
 Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056
 Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134
 Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145
(7 rows)

Quellen

PostgreSQL: COPY

Kleine Unterschiede zwischen MariaDB/MySQL und PostgreSQL

Grundsätzlich lautet der Ladebefehl in den beiden Datenbankwelten gänzlich unterschiedlich.

Bei MariaDB und PostgreSQL laufen die Befehle ‘out-of-the-box’. MySQL hat hier noch zwei zusätzliche Sicherheitshürden eingebaut.

PostgreSQL kennt keine UNSIGNED Integer Datentypen, daher muss der nächstgrössere Datentyp (INT) verwendet werden, was ein klein wenig weniger platzsparender ist als bei MariaDB/MySQL.

Bemerkungen

Als wir den selben Test vor ein paar wenigen Tagen gemacht hatten, gab es noch eine Fehler beim Laden. Es scheint also, dass sich die Datenquelle ebenfalls minimal geändert hat…

Ich habe auf die Schnelle nicht herausgefunden, ob es zu diesen Lade-Befehlen einen SQL-Standard gibt und wenn ja, ob MariaDB/MySQL oder PostgreSQL hier Standard konform sind.

Und natürlich gibt es noch andere Möglichkeiten, wie man seine CSV Daten in die Datenbank rein kriegt…

Die Tools mariadb-import/mysqlimport verwendet man, wenn man das von der Kommandozeile aus machen möchte. Die CSV Storage Engine kann ebenfalls dazu missbraucht werden (Details siehe hier). Eine offiziell unterstütze Variante ist ist die MariaDB CONNECT Storage Engine mit dem CSV Type (siehe hier):

SQL> INSTALL SONAME 'ha_connect';

SQL> CREATE TABLE wgs84_fdw
ENGINE = CONNECT
table_type = CSV
file_name='/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
header = 1
sep_char = ';'
quoted = 0;

SQL> INSERT INTO wgs84 SELECT * FROM wgs84_fdw;

So wie es aussieht, wird die CONNECT Storage Engine von MariaDB leider nicht mehr weiter supportet?!? Und auch das Tool mydumper/myloader scheint mit CSV Dateien umgehen zu können.

Und natürlich kann das ganze auch applikatorisch gelöst werden…

Bei PostgreSQL gibt es folgende Möglichkeiten:

postgres=# \copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER

dann von der Shell aus:

$ psql --user=dba -c "\copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER"

Und die Variante über den Foreign Data Wrapper (FWD). Habe ich aber nicht ausprobiert:

postgres=# CREATE EXTENSION postgres_fdw;

postgres=# CREATE SERVER foreign_server
 FOREIGN DATA WRAPPER postgres_fdw
 OPTIONS (
 datasource 'CSV:/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv',
 format 'CSV'
 )
;

postgres=# CREATE USER MAPPING FOR local_user
 SERVER foreign_server
 OPTIONS (user 'foreign_user', password 'password')
;

postgres=# CREATE FOREIGN TABLE foreign_table (
 id integer NOT NULL,
 data text
)
 SERVER foreign_server
 OPTIONS (schema_name 'some_schema', table_name 'some_table')
;

Nachtrag

Der MariaDB/MySQL Datentyp DOUBLE heist in ProsgreSQL DOUBLE PRECISION.

Attribute Promotion und Demotion im MariaDB Galera Cluster

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 28 Nov 2025 15:32:49 +0000

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

Das kann man in etwa übersetzten mit Spalten Erweiterung/Einschränkung.

Einfach gesagt geht es darum, wie sich der Slave verhält oder verhalten soll, wenn Master und Slave unterschiedliche Spalten-Definitionen oder gar eine unterschiedliche Anzahl von Spalten oder eine Unterschiedliche Reihenfolge der Spalten aufweisen.

Use case des Kunden

Diese Woche haben wir mit einem Kunden den Fall diskutiert, wie er ein Rolling-Schema-Upgrade (RSU) in einem Galera Cluster ausführen könnte.

Bei früheren Schema-Änderungen hat er immer Probleme gekriegt was bis zum Totalausfall des Clusters für mehrere Stunden geführt hat.

Der Kunde meint, dass niemals Spalten gelöscht und neue Spalten immer nur am Ende einer Tabelle hinzugefügt werden.

Und das NICHT sichergestellt werden kann, dass wärend des Rolling-Schema-Upgrades keine schreibenden Verbindungen mehr existieren.

Verwendet wird das PHP ORM-Framework Doctrine.

Was sagt die MariaDB Dokumentation dazu?

Das Studium der MariaDB Dokumentation führte zu keinem schlüssigen Resultat ob ein Rolling-Schema-Upgrade im laufenden Galera Cluster Betrieb MIT Änderungen (DML Statements) auf dem zu ändernden Schema (UND den zu ändernden Tabellen) unterstützt wird oder nicht und somit funktionieren sollte oder nicht.

Quelle: Rolling Schema Upgrade (RSU)

Beim Replizieren mit unterschiedlichen Tabellenstrukturen steht dazu nur Allgemeines zur Replikation aber nichts Spezifisches zu Galera (ob es geht oder nicht):

Tables on the replica and the primary do not need to have the same definition in order for replication to take place. There can be differing numbers of columns, or differing data definitions and, in certain cases, replication can still proceed.

Quelle: Replication When the Primary and Replica Have Different Table Definitions

Für das Attribute Promotion/Demotion Feature gibt es einen speziellen MariaDB Server Konfigurationsparameter der das verhalten steuert: slave_type_conversions.

Wenn man hier zwischen den Zeilen liest, könnte das auch für Galera Cluster funktionieren:

Determines the type conversion mode on the replica when using row-based replication, including replications in MariaDB Galera cluster.

Quelle: slave_type_conversions

Testplanung

Bei solchen Fragestellungen mache ich immer eine grobe Risikoabschätzung: Häufig verwendete und breit eingesetzte Features: Risiko für Probleme ist eher gering. Selten verwendete oder neue Features: Risiko für Probleme ist hoch! Diese Einschätzung beruht leider weniger auf handfesten Zahlen sondern mehr auf Erfahrung…

Mir ist keine einziger MariaDB Nutzer bekannt, der Rolling-Schema-Upgrade im laufenden Betrieb durchführt. Geschweige denn Schreiblast auf dem aktuellen Schema und den aktuellen Tabellen hat (Attribute Promotion/Demotion). Also: Einsatz von Rolling-Schema-Upgrade x Häufigkeit der Verwendung von Attribute Promotion/Demotion ist sehr selten und somit das Risiko sehr hoch!

Da die Situation nicht klar ist und die Dokumentation nichts eindeutiges her gibt wurde getestet.

Um mögliche bereits gefixte MariaDB Bugs zu vermeiden wurde die neuste MariaDB 11.8.5 LTS Version verwendet.

An speziellen Datenbank Konfigurationsparameter wurde verwendet:

slave_type_conversions = 'ALL_NON_LOSSY,ALL_LOSSY'

Unsere Test-Tabelle sieht wie üblich wie folgt aus:

CREATE TABLE `test` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 `data` varchar(128) DEFAULT NULL,
 `ts` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
 PRIMARY KEY (`id`)
);

Und Testdaten wurden wie folgt generiert:

INSERT INTO test VALUES (NULL, 'Some data to fill table up', NOW());
... -- 9 x

Befehle zur Überwachung der Tests:

SQL> SHOW GLOBAL VARIABLES LIKE 'slave_type_conversions';
SQL> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
SQL> SHOW CREATE TABLE test<br>G
SQL> CHECKSUM TABLE test;
SQL> SELECT * FROM test;

Testen

Test 1: Attribute Promotion mit DML remote (auf Node C)

Dies ist der einfachste Fall: Eine Spalte wird hinzugefügt und ein Default-Wert festgelegt. Änderungen auf der Tabelle erfolgen auf einem anderen Knoten:

nodeA> SET SESSION wsrep_OSU_method = 'RSU';
nodeA> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL DEFAULT 'foo';
nodeA> SET SESSION wsrep_OSU_method = 'TOI';

MariaDB Error Log Datei:

[Note] WSREP: Member 0.0 (Node A) desyncs itself from group
[Note] WSREP: Shifting SYNCED→DONOR/DESYNCED (TO: 36)
[Note] WSREP: pause
[Note] WSREP: Provider paused at 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:36 (43)
[Note] WSREP: Provider paused at: 36
[Note] WSREP: resume
[Note] WSREP: resuming provider at 43
[Note] WSREP: Provider resumed.
[Note] WSREP: Member 0.0 (Node A) resyncs itself to group.
[Note] WSREP: Shifting DONOR/DESYNCED→JOINED (TO: 36)
[Note] WSREP: Processing event queue:... -nan% (0/0 events) complete.
[Note] WSREP: Member 0.0 (Node A) synced with group.
[Note] WSREP: Processing event queue:... 100.0% (1/1 events) complete.
[Note] WSREP: Shifting JOINED→SYNCED (TO: 36)
[Note] WSREP: Server Node A synced with group

Dann die weiteren Befehle:

nodeC> INSERT INTO test VALUES (NULL, 'Some data to fill table up', NOW());
nodeC> UPDATE test SET data = 'Some data changed' WHERE id = 10;
nodeC> DELETE FROM test WHERE id = 19;

Anschliessend wurde der ALTER TABLE Befehl auf Knoten 2 und 3 ausgeführt.

Alle 3 Operationen haben einwandfrei funktioniert. Der Cluster ist noch voll funktionsfähig. Anschliessend:

SQL> ALTER TABLE test DROP COLUMN c1;

um das System für weitere Tests wieder in seinen Anfangszustand zurück zu überführen.

Test 2: Attribute Promotion mit DML remote (auf Node B)

Wenn man das gleiche Experiment auf Knoten B macht, fliegt einem der Cluster um die Ohren!

nodeB> INSERT INTO test VALUES (NULL, 'Some data to fill table up', NOW());

nodeC> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------------+
| Variable_name | Value |
+---------------------------+--------------+
| wsrep_local_state_comment | Inconsistent |
+---------------------------+--------------+

MariaDB Error Log Datei:

[Note] WSREP: Member 1(Node A) initiates vote on 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45,dbc9a6ea898b6a29: Got error 171 "The event was corrupt, leading to illegal data being read" from storage engine InnoDB, Error_code: 1030;
[Note] WSREP: Votes over 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45:
 dbc9a6ea898b6a29: 1/3
Waiting for more votes.
[Note] WSREP: Member 2(Node C) initiates vote on 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45,dbc9a6ea898b6a29: Got error 171 "The event was corrupt, leading to illegal data being read" from storage engine InnoDB, Error_code: 1030;
[Note] WSREP: Votes over 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45:
 dbc9a6ea898b6a29: 2/3
Winner: dbc9a6ea898b6a29
[Note] WSREP: Got vote request for seqno 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45
[Note] WSREP: Recovering vote result from history: 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45,dbc9a6ea898b6a29
[ERROR] WSREP: Vote 0 (success) on 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45 is inconsistent with group. Leaving cluster.
[Note] WSREP: Closing send monitor...
[Note] WSREP: Closed send monitor.
[Note] WSREP: gcomm: terminating thread
[Note] WSREP: gcomm: joining thread
[Note] WSREP: gcomm: closing backend
[Note] WSREP: view(view_id(NON_PRIM,1456a640-aca0,15) memb {
 1456a640-aca0,0
} joined {
} left {
} partitioned {
 97230fdb-b973,0
 a2e10f2c-8929,0
})
[Note] WSREP: PC protocol downgrade 1→0
[Note] WSREP: view((empty))
[Note] WSREP: gcomm: closed
[Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
[Note] WSREP: Flow-control interval: [16, 16]
[Note] WSREP: Received NON-PRIMARY.
[Note] WSREP: Shifting SYNCED→OPEN (TO: 45)
[Note] WSREP: New SELF-LEAVE.
[Note] WSREP: Flow-control interval: [0, 0]
[Note] WSREP: Received SELF-LEAVE. Closing connection.
[Note] WSREP: Shifting OPEN→CLOSED (TO: 45)
[Note] WSREP: RECV thread exiting 0: Success
[Note] WSREP: recv_thread() joined.
[Note] WSREP: Closing send queue.
[Note] WSREP: Closing receive queue.
[Note] WSREP: ================================================
View:
 id: 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45
 status: non-primary
 protocol_version: 4
 capabilities: MULTI-MASTER, CERTIFICATION, PARALLEL_APPLYING, REPLAY, ISOLATION, PAUSE, CAUSAL_READ, INCREMENTAL_WS, UNORDERED, PREORDERED, STREAMING, NBO
 final: no
 own_index: 0
 members(1):
 0: 1456a640-cc36-11f0-aca0-e388a5f80ba9, Node B
=================================================
[Note] WSREP: Non-primary view
[Note] WSREP: Server status change synced→connected
[Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
[Note] WSREP: ================================================
View:
 id: 22db9ea1-cb7b-11f0-b26e-6fbce72757f9:45
 status: non-primary
 protocol_version: 4
 capabilities: MULTI-MASTER, CERTIFICATION, PARALLEL_APPLYING, REPLAY, ISOLATION, PAUSE, CAUSAL_READ, INCREMENTAL_WS, UNORDERED, PREORDERED, STREAMING, NBO
 final: yes
 own_index: -1
 members(0):
=================================================
[Note] WSREP: Non-primary view
[Note] WSREP: Server status change connected→disconnected
[Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
[Note] WSREP: Applier thread exiting ret: 6 thd: 2
[Note] WSREP: Applier thread exiting ret: 6 thd: 9
[Warning] Aborted connection 2 to db: 'unconnected' user: 'unauthenticated' host: '' (This connection closed normally without authentication)
[Note] WSREP: Applier thread exiting ret: 6 thd: 5
[Warning] Aborted connection 5 to db: 'unconnected' user: 'unauthenticated' host: '' (This connection closed normally without authentication)
[Warning] Aborted connection 9 to db: 'unconnected' user: 'unauthenticated' host: '' (This connection closed normally without authentication)
[Note] WSREP: Service thread queue flushed.
[Note] WSREP: ####### Assign initial position for certification: 00000000-0000-0000-0000-000000000000:-1, protocol version: 6
[Note] WSREP: Applier thread exiting ret: 0 thd: 6
[Warning] Aborted connection 6 to db: 'unconnected' user: 'unauthenticated' host: '' (This connection closed normally without authentication)

Keine Ahnung, warum Knoten B und C sich unterschiedlich verhalten. Aber damit wir der ganze Rolling-Schema-Upgrade (RSU) Prozess völlig willkürlich und unplanbar.

Das Ganze wurde in verschiedenen Varianten getestet und der Knoten wird mal inkonsistent und mal nicht.

Der inkonsistente Knoten B wird über einen erzwungenen SST wieder in den Cluster synchronisiert.

Test 3: Attribute Promotion mit DML remote (auf Node C)

Dieser Fall ist etwas heikler, da kein Default-Wert vorgegeben wird.

nodeA> SET SESSION wsrep_OSU_method = 'RSU';
nodeA> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL; -- DEFAULT ''
nodeA> SET SESSION wsrep_OSU_method = 'TOI';

nodeC> INSERT INTO test VALUES (NULL, 'Some data to fill table up', NOW());
nodeC> UPDATE test SET data = 'Some data changed' WHERE id = 13;
nodeC> DELETE FROM test WHERE id = 22;

Anschliessend wurde der ALTER TABLE Befehl auf Knoten 2 und 3 ausgeführt.

Alle 3 Operationen haben einwandfrei funktioniert. Der Cluster ist noch voll funktionsfähig.

Test 4: Attribute Promotion mit DML remote (auf Node B)

Gleicher Test aber der Befehl ALTER TABLE ADD COLUMN wird auf Knoten A und der DML Befehl auf Knoten B ausgeführt.

Knoten A und C werden “Inconsistent” und Knoten B ist noch “Synced”.

Test 5: Attribute Promotion mit DML lokal (auf Node A)

Analoger Test aber der DML Befehl wird lokal, auf dem selben Knoten wie der DDL Befehl, ausgeführt.

nodeA> SET SESSION wsrep_OSU_method = 'RSU';
nodeA> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL; -- DEFAULT ''
nodeA> SET SESSION wsrep_OSU_method = 'TOI';

nodeA> INSERT INTO test VALUES (NULL, 'Some data to fill table up', NOW());
ERROR 1136 (21S01): Column count doesn't match value count at row 1

nodeA> INSERT INTO test (id, data, ts) VALUES (NULL, 'Some data to fill table up', NOW());
ERROR 1364 (HY000): Field 'c1' doesn't have a default value

nodeA> INSERT INTO test (id, data, ts, c1) VALUES (NULL, 'Some data to fill table up', NOW(), '');

nodeA> SELECT * FROM test;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

nodeA> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------------+
| Variable_name | Value |
+---------------------------+--------------+
| wsrep_local_state_comment | Inconsistent |
+---------------------------+--------------+

Cluster Knoten wurde inkonsistent. Interessanter weise hat bei weiteren Test das Ganze plötzlich geklappt! Also vollständig unvorhersagbar…

Test 6: DDL auf 2 Knoten

Neue Fragestellung: Was passiert nachdem der DDL Befehl auf 2 Knoten ausgeführt wurde und dann DML Befehle auftreten?

nodeA> SET SESSION wsrep_OSU_method = 'RSU';
nodeA> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL DEFAULT 'foo';
nodeA> SET SESSION wsrep_OSU_method = 'TOI';

nodeB> SET SESSION wsrep_OSU_method = 'RSU';
nodeB> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL DEFAULT 'foo';
nodeB> SET SESSION wsrep_OSU_method = 'TOI';

nodeC> INSERT INTO test (id, data, ts) VALUES (NULL, 'Some data to fill table up', NOW());

klappt, aber:

nodeB> INSERT INTO test (id, data, ts) VALUES (NULL, 'Some data to fill table up', NOW());

root@localhost [test]> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------------+
| Variable_name | Value |
+---------------------------+--------------+
| wsrep_local_state_comment | Inconsistent |
+---------------------------+--------------+

Test 7: UPDATE und DELETE Befehle vom selben Knoten

nodeA> SET SESSION wsrep_OSU_method = 'RSU';
nodeA> ALTER TABLE test ADD COLUMN c1 VARCHAR(64) NOT NULL DEFAULT 'foo';
nodeA> SET SESSION wsrep_OSU_method = 'TOI';

nodeA> UPDATE test SET data = 'Some data changed' WHERE id = 16;

nodeA> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------------+
| Variable_name | Value |
+---------------------------+--------------+
| wsrep_local_state_comment | Inconsistent |
+---------------------------+--------------+

nodeA> DELETE FROM test WHERE id = 25;
nodeA> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

...
[Warning] WSREP: Ignoring error 'Can't find record in 'test'' on Delete_rows_v1 event. Error_code: 1032
[Warning] Slave SQL: Could not execute Delete_rows_v1 event on table test.test; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find record in 'test', Error_code: 1032; Can't find re
[ERROR] Slave SQL: Could not read field 'id' of table 'test.test', Internal MariaDB error code: 1610
[ERROR] mariadbd: Can't find record in 'test'
...

Prozessliste von Knoten C:

nodeC> SHOW PROCESSLIST;
+----+-------------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+-------------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------------------------------+----------+
| 2 | system user | | NULL | Sleep | 1670 | After apply log event | NULL | 0.000 |
| 1 | system user | | NULL | Sleep | 4609 | wsrep aborter idle | NULL | 0.000 |
| 7 | system user | | NULL | Sleep | 4608 | | NULL | 0.000 |
| 8 | system user | | test | Sleep | 1441 | Executing | DELETE FROM test WHERE id = 25?5jR | 0.000 |
| 10 | system user | | NULL | Sleep | 2002 | wsrep applied write set | INSERT INTO test (id, data, ts) VALUES (NULL, 'Some data to fill table up', NOW()) 9O? | 0.000 |
| 28 | root | localhost | NULL | Query | 0 | starting | show processlist | 0.000 |
+----+-------------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------------------------------+----------+

Knoten C ist aber immer noch Synced:

nodeC> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

Herunterfahren des Knotens für zu folgender Fehlermeldung:

nodeC> SQL> shutdown;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Anschliessend war der ganze Cluster nicht mehr nutzbar. Und musste neu gestartet werden (Bootstrap).

Zusammenfassung

Wir haben zu dieser Thematik einen Bug bei MariaDB eröffnet: Attribute Promotion/Demotion in Galera Cluster

Weitere Tests wurden vorerst nicht durchgeführt, da dieses Feature in der getesteten Version zu instabil ist und DROP COLUMN kein Use Case unseres Kunden ist.

Fazit: MariaDB Galera Cluster fängt diese Situation in der untersuchten Version nicht sauber ab, der Cluster verhindert diesen Fall auch nicht. Cluster Knoten werden als inkonsistent markiert. Unsere aktuelle Empfehlung: Rolling-Schema-Upgrade (RSU) mit konkurrierenden DML-Befehlen (INSERT, UPDATE, DELETE) auf den zu ändernden Tabellen mit der untersuchten Version NICHT tun!

Weitere Quellen:

MariaDB Honeypot

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 04 Mar 2025 16:27:44 +0000

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.

Dies sieht dann im MariaDB Error Log in etwa wie folgt aus:

[Warning] Aborted connection 22939 to db: 'unconnected' user: 'unauthenticated' host: '118.193.58.125' (This connection closed normally without authentication)
[Warning] Aborted connection 22940 to db: 'unconnected' user: 'unauthenticated' host: '118.193.58.125' (This connection closed normally without authentication)
[Warning] Access denied for user ''@'118.193.58.125' (using password: NO)
[Warning] Access denied for user 'root'@'118.193.58.125' (using password: YES)
[Warning] Access denied for user 'root'@'118.193.58.125' (using password: YES)

Zuerst wird einmal probiert, ob da eine Datenbank lauscht und wie diese antwortet. Anschliessend wird auf verschiedene Arten versucht in die Datenbank einzudringen. So wie es aussieht, gibt es verschiedene Beprobungs- und Angriffsmuster. Der Anonymous User (''@'%') und 'root'@'%' werden mit und ohne Passwort geprüft. Ob noch weitere User probiert werden, muss sich noch über einen längeren Beobachtungszeitraum zeigen.

Und so sieht das aus Sicht des MariaDB General Query Logs aus:

287793 Connect root@196.251.91.77 on using TCP/IP
287793 Connect Access denied for user 'root'@'196.251.91.77' (using password: NO)
287794 Connect root@196.251.91.77 on using TCP/IP
287794 Connect Access denied for user 'root'@'196.251.91.77' (using password: YES)
287796 Connect root@196.251.91.77 on using TCP/IP
287796 Connect Access denied for user 'root'@'196.251.91.77' (using password: YES)

Vorbereiten des Honeypots

Nach Beendigung der Schulung brauchen wir die Maschinen nicht mehr, sie werden abgebaut. Daher hat es mich zum Schluss gereizt, auszuprobieren, was passiert, wenn ein Zugriffsversuch erfolgreich ist. Um das zu testen wurde der User 'root'@'%' ohne Passwort wie folgt angelegt und ihm alle Rechte auf das test Schema gegeben:

SQL> CREATE USER 'root'@'%';
SQL> GRANT ALL ON test.* TO 'root'@'%';

und sowohl das MariaDB General Log eingeschaltet als auch das MariaDB Error Log gesprächiger gemacht:

# my.cnf

[server]

general_log_file = /var/log/mysql/general.log
general_log = on
log_error = /var/log/mysql/error.log
log_warnings = 9 # too much!
bind_address = *
skip_name_resolve = on # How much info do we loose?
# skip_grant_tables

Anschliessend hiess es nur noch sich auf die Lauer legen und abwarten was passiert…

TODO: Es wäre hier noch spannend zu sehen, mit welchen Passwörtern versucht wird, in die Datenbank zu gelangen. Mal schauen, ob man das rausfinden kann ohne den MariaDB Quellcode zu patchen…? Ev. sollte man zusätzlich noch mit wireshark oder tcpdump versuchen, die Passwörter ersichtlich zu machen.

Die erste Fliege schwirrt an

Dann scheint die erste Fliege (aus Amsterdam, Niederlande) zum Honigtopf zu gelangen. Zuerst haben wir eine Warnung, dass der Reverse-Lookup der IP Adresse scheitert:

[Warning] Hostname 'no-reverse-dns-configured.com' does not resolve to '94.102.49.155'.

Aber dann geht sie rein. Tut aber nichts Spannendes:

250228 16:06:32 1222 Connect root@94.102.49.155 on using TCP/IP
 1222 Query SHOW databases
 1222 Query SHOW tables IN information_schema
 1222 Query SHOW tables IN test
 1222 Query SHOW VARIABLES
250228 16:06:33 1222 Quit

Was kriegt die Fliege zu sehen:

SQL> SHOW databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| test |
+--------------------+

SQL> SHOW tables IN information_schema;
+-------------------------------+
| Tables_in_information_schema |
+-------------------------------+
| ALL_PLUGINS |
| APPLICABLE_ROLES |
| CHARACTER_SETS |
| ... |
| INNODB_TABLESPACES_ENCRYPTION |
| INNODB_LOCK_WAITS |
| THREAD_POOL_STATS |
+-------------------------------+
82 rows in set (0.000 sec)

SQL> SHOW tables IN test;
+----------------+
| Tables_in_test |
+----------------+
| test |
+----------------+

SQL> SHOW VARIABLES;
+----------------------------------------------------------+------------+
| Variable_name | Value |
+----------------------------------------------------------+------------+
| allow_suspicious_udfs | OFF |
| alter_algorithm | DEFAULT |
| analyze_sample_percentage | 100.000000 |
| ... | |
| wsrep_sync_wait | 0 |
| wsrep_trx_fragment_size | 0 |
| wsrep_trx_fragment_unit | bytes |
+----------------------------------------------------------+------------+
686 rows in set (0.003 sec)

Möglicherweise ist hier der Algorithmus des Angriffs schlau genug und stellt fest, dass sich ein Angriff nicht lohnt?

Dann warten wir auf die nächste Fliege…

Die nächste Fliege kommt geflogen

Und da sieht man sie auch schon (diesmal aus USA, Minneapolis) im MariaDB Error Log:

[Warning] Hostname 'undefined.hostname.localhost' does not resolve to '196.251.83.136'.

Jetzt wird es spannen, im MariaDB General Query Log zu sehen, was genau passiert?

Zuerst wird eine Verbindung aufgebaut und offen gehalten (Fuss in der Angel behalten?):

250228 16:06:55 67 Connect root@196.251.83.136 on using TCP/IP
 67 Query SET AUTOCOMMIT=0

Dann, 15 Sekunden später wird eine Verbindung auf und wieder zu gemacht (sicherstellen, dass man auch wirklich erfolgreich war?):

250228 16:07:10 68 Connect root@196.251.83.136 on using TCP/IP
 68 Query SET AUTOCOMMIT=0
 68 Quit

Sofort danach werden alle Schemas abgefragt:

 69 Connect root@196.251.83.136 on using TCP/IP
 69 Query SET AUTOCOMMIT=0
 69 Query SHOW DATABASES
 69 Quit

Dann wird wieder eine Verbindung auf- und wieder abgebaut:

 70 Connect root@196.251.83.136 on using TCP/IP
 70 Query SET AUTOCOMMIT=0
 70 Quit

Anschliessend wird geprüft, wie gross das Schema ist. Wahrscheinlich um sicherzustellen, dass es nicht zu gross ist? Dann die Tabellen abgefragt. Die Verbindung wird offen gehalten, es wird 2 Sekunden später damit weitergearbeitet.

 71 Connect root@196.251.83.136 on using TCP/IP
 71 Query SET AUTOCOMMIT=0
 71 Query SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE table_schema = 'test'
 71 Query USE `test`
 71 Query SHOW tables

Anschliessend wir ein mariadb-dump Imitat? mit Version ≥ 10.1 gestartet um die ersten 10!!! Zeilen der Tabelle aaa_payload im Schema test zu dumpen.

250228 16:07:11 72 Connect root@196.251.83.136 on using TCP/IP
 72 Query /*!40100 SET @@SQL_MODE='' */
 72 Query /*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */
 72 Query /*!100100 SET WAIT_TIMEOUT=DEFAULT */
 72 Query set optimizer_switch='semijoin=off'
 72 Query SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('aaa_payload'))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE, TOTAL_EXTENTS, INITIAL_SIZE ORDER BY LOGFILE_GROUP_NAME
 72 Query SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('aaa_payload')) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
 72 Query set optimizer_switch=default
 72 Init DB test
 72 Query SHOW VARIABLES LIKE 'lower_case_table_names'
 72 Query SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'aaa_payload'
 72 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'aaa_payload'
 72 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'aaa_payload'
 72 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'aaa_payload'
 72 Query SET SQL_QUOTE_SHOW_CREATE=1
 72 Query show fields from `aaa_payload`
 72 Query SELECT /*!40001 SQL_NO_CACHE */ `id`, `name` FROM `aaa_payload` WHERE 1 LIMIT 10
 72 Quit

Dann das selbe nochmal mit einer Tabelle namens bbb_payload:

 73 Connect root@196.251.83.136 on using TCP/IP
 73 Query /*!40100 SET @@SQL_MODE='' */
 73 Query /*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */
 73 Query /*!100100 SET WAIT_TIMEOUT=DEFAULT */
 73 Query set optimizer_switch='semijoin=off'
 73 Query SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('bbb_payload'))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE, TOTAL_EXTENTS, INITIAL_SIZE ORDER BY LOGFILE_GROUP_NAME
 73 Query SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('bbb_payload')) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
 73 Query set optimizer_switch=default
 73 Init DB test
 73 Query SHOW VARIABLES LIKE 'lower_case_table_names'
250228 16:07:12 73 Query SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'bbb_payload'
 73 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'bbb_payload'
 73 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'bbb_payload'
 73 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'bbb_payload'
 73 Query SET SQL_QUOTE_SHOW_CREATE=1
 73 Query show fields from `bbb_payload`
 73 Query SELECT /*!40001 SQL_NO_CACHE */ `id`, `name` FROM `bbb_payload` WHERE 1 LIMIT 10
 73 Quit

Und schiesslich unsere Haupttabelle test aber auch hier nur die ersten 10!!! Zeilen:

 74 Connect root@196.251.83.136 on using TCP/IP
 74 Query /*!40100 SET @@SQL_MODE='' */
 74 Query /*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */
 74 Query /*!100100 SET WAIT_TIMEOUT=DEFAULT */
 74 Query set optimizer_switch='semijoin=off'
 74 Query SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('test'))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE, TOTAL_EXTENTS, INITIAL_SIZE ORDER BY LOGFILE_GROUP_NAME
 74 Query SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='test' AND TABLE_NAME IN ('test')) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
 74 Query set optimizer_switch=default
 74 Init DB test
 74 Query SHOW VARIABLES LIKE 'lower_case_table_names'
 74 Query SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'test'
 74 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'test'
 74 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'test'
 74 Query SELECT engine, table_type FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = DATABASE() AND table_name = 'test'
 74 Query SET SQL_QUOTE_SHOW_CREATE=1
 74 Query show fields from `test`
 74 Query SELECT /*!40001 SQL_NO_CACHE */ `id`, `data`, `ts` FROM `test` WHERE 1 LIMIT 10
 74 Quit

Dann geht es wieder mit Connection 71 weiter: Die 3 Tabellen test, bbb_payload und aaa_payload werden gelöscht:

 71 Query USE `test`
 71 Query SHOW TABLES
 71 Query SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'test' AND REFERENCED_TABLE_NAME IS NOT NULL
 71 Query SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'bbb_payload' AND REFERENCED_TABLE_NAME IS NOT NULL
250228 16:07:13 71 Query SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'aaa_payload' AND REFERENCED_TABLE_NAME IS NOT NULL
 71 Query DROP TABLE `test`
 71 Query DROP TABLE `bbb_payload`
 71 Query DROP TABLE `aaa_payload`

Dann wird eine Tabelle namens RECOVER_YOUR_DATA erstellt und mit dem Text versehen, wie man das Lösegeld bezahlen soll. Die Höhe beträgt 0.0101 Bitcoin was zur Zeit ca. EUR 863.40 entspricht. Wohlgemerkt, sie haben nur die ersten 10 Zeilen gedumpt und anschliessend gelöscht!

 71 Query CREATE TABLE IF NOT EXISTS RECOVER_YOUR_DATA (text VARCHAR(255))
 71 Query INSERT INTO RECOVER_YOUR_DATA (text) VALUES ('All your data is backed up. You must pay 0.0101 BTC to bc1qm0v2r0mmx3py3h7fzkerd9a6rzdrpw5afqacen In 48 hours, your data will be publicly disclosed and deleted. (more information: go to https://is.gd/yotuqu)')
 71 Query INSERT INTO RECOVER_YOUR_DATA (text) VALUES ('After payment send mail to us: rambler+2r8qm@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: 2R8QM')
 71 Query COMMIT
 71 Quit

Hinter dem Link ist folgender Text zu finden:

Please take note of the following:

We are aware that you have accessed this guide.
This offer stands for 24hs

After 72 hours, we cannot guarantee that we will be able to send the data to you.
The only way to recover your data is by making the payment. We will not provide the data for free.

Data leakage is a serious legal violation. Rest assured, the incident will remain confidential, and your data is protected.

After your payment is completed, all data downloaded from you will be deleted from our servers, government agencies, competitors, contractors, and local media are currently unaware of the incident.

If you pay we guarantee that your data will not be sold on Darkweb resources and will not be used to attack your company, employees, or counterparties in the future and the full database dump will be sent to you.

If you have not contacted us within two days from the time of the incident, we will consider the transaction incomplete. Your data will then be sent to any interested parties. This is your responsibility.

If you are a system administrator or programmer and your boss is unaware of this incident, we will contact them after 48 hours.

If you are unable to contact us using the provided email, please visit https://getsession.org/ and download the Session Messenger. Add us using the following Session ID for a smoother conversation and better negotiation:
Session ID:
05a5ba6491a15908207cce6e257b3316cd11cb2575f75194d3c59c37de68eaf55a

After payment, please provide us with a screenshot or proof of payment.
Once the payment is confirmed, we will send you a download link for your data. We will also delete our copy of the data.

IMPORTANT!!
DO NOT FORGET TO INCLUDE YOUR DBCODE IN YOUR MAIL OR MESSAGE YOU SEND TO US

The only accepted payment method is Bitcoin.
Be advised: PayPal, WeTransfer, Alipay, credit cards, and other methods will not be accepted.
If you prefer to pay with another cryptocurrency, please contact us to make arrangements.

If you don't have Bitcoin, you can purchase it using a credit card from the following websites:

MoonPay: https://www.moonpay.com/buy
Paybis: https://paybis.com/
Changelly: https://changelly.com/buy

Alternatively, you can buy Bitcoin using other payment methods from the following platforms (some of them work in China):

Coinbase: https://www.coinbase.com/
Paxful: https://paxful.com/
Binance: https://www.binance.com/
Crypto.com: https://www.crypto.com/
Huobi: https://www.huobi.com/
OKCoin: https://www.okcoin.com/
BTCC: https://www.btcc.com/
Paybis: https://paybis.com/
Coinmama: https://coinmama.com/
Bitfinex: https://www.bitfinex.com/
For users in China, Bitcoin can be purchased with Alipay from:

CoinCola: https://www.coincola.com/?lang=zh-HK
BitValve: https://www.bitvalve.com/buy-bitcoin/alipay

Und dieser Text wir in die Tabelle RECOVER_YOUR_DATA geschrieben:

SQL> SELECT * FROM RECOVER_YOUR_DATA;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| text |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| All your data is backed up. You must pay 0.0101 BTC to bc1qm0v2r0mmx3py3h7fzkerd9a6rzdrpw5afqacen In 48 hours, your data will be publicly disclosed and deleted. (more information: go to https://is.gd/yotuqu) |
| After payment send mail to us: rambler+2r8qm@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: 2R8QM |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Anschliessend wird das Schema test (wo die Tabelle RECOVER_YOUR_DATA drin ist?) gelöscht.

 75 Connect root@196.251.83.136 on using TCP/IP
 75 Query SET AUTOCOMMIT=0
 75 Query DROP DATABASE `test`
 75 Query COMMIT
 75 Quit

Und ein neues Schema erstellt mit dem Namen RECOVER_YOUR_DATA:

 76 Connect root@196.251.83.136 on using TCP/IP
 76 Query SET AUTOCOMMIT=0
 76 Query CREATE DATABASE IF NOT EXISTS RECOVER_YOUR_DATA
 76 Quit

Irgendwie scheint mir der Zugriff nicht logisch und hat noch Potential. Da die Tabelle RECOVER_YOUR_DATA fehlt (gelöscht mit Schema test) kann man ja gar nicht mehr bezahlen, falls man wollte…

Möglicherweise scheint der Entwickler auch nicht mit einem limitierten root Account gerechnet zu haben und das Tool verhält sich daher falsch? Siehe auch die drei Wiederholungen beim Dumpen der Tabellen.

Woher kommt der Zugriff?

Ich weiss nicht, wie gut man verschleiern kann woher man kommt und wie gut die Geo-Auflösung der IP-Adressen ist, davon habe ich zu wenig Ahnung. Eine Recherche hat ergeben, dass die IP aus Amsterdam (Niederlande) kommt.

Nach weiterer Suche stellte sich heraus, dass die IP einer Organisation Namens Internet Secuirty Ekabi (achtung Schreibfehler wie im Original!) gehört mit einer Adresse aus der USA und der Location auf den Seychellen. Wenn mir noch jemand mehr Tipps geben kann, was man da alles rausfinden kann, wäre ich sehr dankbar dafür!

Woher stammen die IP Adressen?

Im kurzen beobachteten Zeitraum haben wir Zugriffe aus folgenden Regionen beobachtet:

Alibaba Cloud, Singapore
Google Belgium, Brussels
Data-Center Imaqliq Ltd., Russia, St. Petersburg
Alibaba Cloud, Japan, Tokyo
FiberXpress BV, Netherlands, Amsterdam
M247 Europe SRL, United Kingdom, Manchester
Hetzner Online GmbH, Finland, Helsinki
Internet Secuirty Ekabi, Netherlands, Amsterdam (2 x)
Internet Security Cheapyhost, Netherlands, Amsterdam (9 x)
Internet Security Nybula, Netherlands, Amsterdam (2 x)

Zugriffsmuster

Alle Zugriffsversuche erfolgen OHNE SSL/TLS.

Fingerprint aus Sicht des MariaDB General Query Logs:

9 x
Connect root@34.140.63.218 on using TCP/IP
Connect Access denied for user 'root'@'34.140.63.218' (using password: NO)

1 x
Connect root@45.135.95.25 on using TCP/IP
Connect Access denied for user 'root'@'45.135.95.25' (using password: NO)
Connect root@45.135.95.25 on using TCP/IP
Connect Access denied for user 'root'@'45.135.95.25' (using password: NO)

4 x
Connect root@196.251.118.8 on using TCP/IP
Connect Access denied for user 'root'@'196.251.118.8' (using password: NO)
Connect root@196.251.118.8 on using TCP/IP
Connect Access denied for user 'root'@'196.251.118.8' (using password: YES)
Connect root@196.251.118.8 on using TCP/IP
... mit 2 Wiederholungen

1 x
Connect root@94.102.49.155 on using TCP/IP
Connect Access denied for user 'root'@'94.102.49.155' (using password: NO)
Connect root@94.102.49.155 on using TCP/IP
Connect Access denied for user 'root'@'94.102.49.155' (using password: YES)
... mit 6 Wiederholungen

2 x
Connect root@196.251.91.19 on using TCP/IP
Connect Access denied for user 'root'@'196.251.91.19' (using password: NO)
Connect root@196.251.91.19 on using TCP/IP
Connect Access denied for user 'root'@'196.251.91.19' (using password: YES)
... mit 28 Wiederholungen

1 x
Connect root@157.180.29.231 on using TCP/IP
Connect Access denied for user 'root'@'157.180.29.231' (using password: NO)
Connect root@157.180.29.231 on using TCP/IP
Connect Access denied for user 'root'@'157.180.29.231' (using password: NO)
Connect root@157.180.29.231 on using TCP/IP
Connect Access denied for user 'root'@'157.180.29.231' (using password: YES)
Connect root@157.180.29.231 on using TCP/IP
Connect Access denied for user 'root'@'157.180.29.231' (using password: YES)
Mit jeweils zeitlichem Abstand

2 x
Connect root@196.251.86.26 on using TCP/IP
Connect Access denied for user 'root'@'196.251.86.26' (using password: NO)
Connect root@196.251.86.26 on using TCP/IP
Connect Access denied for user 'root'@'196.251.86.26' (using password: YES)
Connect root@196.251.86.26 on using TCP/IP
... mit 38 Wiederholungen

Es kann natürlich sein, dass einige dieser Zugriffsversuche dieselben Werkzeuge verwenden und einfach nach einer unterschiedlichen Anzahl Versuche abgebrochen wurde und die Tools damit ein unterschiedliches Muster erzeugt haben.

Zugriffsmuster aus Sicht des MariaDB Error Logs

Mögliche Zugriffe auf das Galera Protokoll

[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Unsupported/unrecognized gmcast protocol version: {
 at ./gcomm/src/gmcast_message.hpp:unserialize():331
 at ./gcomm/src/gmcast.cpp:handle_up():1494
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.

und:

[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.
[Warning] WSREP: Failed to unserialize message. This may be a result of corrupt message, port scanner or another application connecting to group communication port.

Ob dies ein Zugriffsversuch war oder ob wir nur bei uns im Netzwerk oder Galera Cluster ein Problem hatten muss noch verifiziert werden.

Probleme mit der Namensauflösung

Um mehr und zusätzliche Informationen zu erhalten wurde die Datenbank OHNE skip_name_resolve betrieben. Dies führt zu verschiedenen Warnung betreffend Namensauflösung (vorwärts und rückwärts).

[Warning] Hostname 'no-reverse-dns-configured.com' does not resolve to '94.102.49.155'.
[Warning] Host name 'scanner-28.ch1.censys-scanner.com' could not be resolved: Name or service not known
[Warning] IP address '34.140.170.97' has been resolved to the host name '97.170.140.34.bc.googleusercontent.com', which resembles IPv4-address itself.
[Warning] IP address '165.154.100.58' could not be resolved: Name or service not known
[Warning] IP address '104.193.135.104' could not be resolved: Temporary failure in name resolution

Zudem sind verschiedene Scanner-Systeme aufgefallen, die teilweise richtig aufgelöst haben: security.ipip.net coop.net {ch1|hk2}.censys-scanner.com

Fazit: slog_warnings = 9 ist zu hoch, skip_name_resolve aktivieren.

Port probing

Einfaches Port probing (Abklopfen der Ports) kann wie folgt erfolgen:

# netcat -z -n -v 10.116.63.139 3300-3310

Im MariaDB Error Log auf Datenbank Seite sieht man dann wie folgt:

[Warning] Could not read packet: fd: 56 state: 1 read_length: 4 errno: 110 vio_errno: 1159 length: 0
[Warning] Aborted connection 52 to db: 'unconnected' user: 'unauthenticated' host: '_gateway.incus' (This connection closed normally without authentication)

Diese Port probes werden im MariaDB Gerneral Query Log schon gar nicht erst angezeigt.

Verschiedene Varianten und Muster des Port probings

Folgende 3 Muster des Port probings sind uns aufgefallen:

[Warning] Could not read packet: fd: 63 state: 1 read_length: 4 errno: 104 vio_errno: 1158 length: -1
[Warning] Aborted connection 76 to db: 'unconnected' user: 'unauthenticated' host: '45.142.193.153' (This connection closed normally without authentication)

198.235.24.140 115.231.78.10
[Warning] Could not read packet: fd: 63 state: 1 read_length: 4 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 50 to db: 'unconnected' user: 'unauthenticated' host: '20.65.194.133' (This connection closed normally without authentication)

[Warning] Could not write packet: fd: 64 state: 1 errno: 104 vio_errno: 1160 length: 42
[ERROR] mariadbd: Got an error writing communication packets
[Warning] Aborted connection 55 to db: 'unconnected' user: 'unauthenticated' host: 'connecting host' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 4 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 56 to db: 'unconnected' user: 'unauthenticated' host: '137.184.75.161' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 4 errno: 0 vio_errno: 1158 length: 0
[Warning] Aborted connection 57 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 87 state: 1 read_length: 4 errno: 0 vio_errno: 1158 length: 0
[Warning] Aborted connection 58 to db: 'unconnected' user: 'unauthenticated' host: '165.22.188.115' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 196974 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 59 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 196974 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 60 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 197053 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 61 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 197067 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 62 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 196986 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 63 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 131449 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 64 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 65900 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 65 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 65900 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 66 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 65910 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 67 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)
[Warning] Could not read packet: fd: 64 state: 1 read_length: 65887 errno: 11 vio_errno: 1158 length: 0
[Warning] Aborted connection 68 to db: 'unconnected' user: 'unauthenticated' host: '165.22.191.252' (This connection closed normally without authentication)

Was im dritten Fall genau probiert wurde, entzieht sich noch meiner Kenntnis.

Und hier noch die Aufschlüsselung der Fehlermeldungen:

# perror 104
OS error code 104: Connection reset by peer

# perror 11
OS error code 11: Resource temporarily unavailable

# perror 1158
MariaDB error code 1158 (ER_NET_READ_ERROR): Got an error reading communication packets
Learn more: https://mariadb.com/kb/en/e1158/

# perror 1160
MariaDB error code 1160 (ER_NET_ERROR_ON_WRITE): Got an error writing communication packets
Learn more: https://mariadb.com/kb/en/e1160/

Out of order packets (4 x)

Ein weiteres Muster, welches wir gesehen habe, sind Pakete in falscher Reihenfolge. Ob das Absicht ist oder mit dem Netzwerk zwischen Angreifer und Datenbank zu tun hat kann zur Zeit nicht gesagt werden (die IPs sollen aus Italien, USA und 2 x Schweden stammen).

Quellen: 45.91.171.169 45.147.250.222 20.168.122.53 91.223.169.88

Beispiel:

[ERROR] mariadbd: Got packets out of order
[Warning] Aborted connection 49 to db: 'unconnected' user: 'unauthenticated' host: '103.45.246.42' (This connection closed normally without authentication)

Unvollständiger Verbindungsaufbau (51 x)

Quellen: 80.82.70.133 194.165.16.167 162.142.125.208 205.210.31.204 104.248.130.34 198.235.24.96 209.38.99.93 171.36.7.2 34.77.151.17 118.193.33.60 147.185.132.118 88.214.25.121 198.235.24.129 188.166.68.252 118.193.43.158 206.189.5.176 205.210.31.178 165.22.187.120 45.142.193.153 196.251.90.186 134.209.221.50 89.185.82.115 104.248.229.49 198.235.24.72 35.205.56.72 198.235.24.28 43.248.108.8 167.71.184.54 205.210.31.70 154.212.141.215 89.248.174.130 154.212.141.212 198.235.24.164 34.140.35.166 167.94.146.56 167.94.145.101 167.94.145.98 103.149.26.234 167.94.146.49 137.184.64.140 167.94.145.104 167.94.146.59 170.64.154.53 165.22.188.115 185.47.172.136 199.45.154.148 162.142.125.207 162.142.125.47 147.185.132.108 20.171.28.254 103.203.57.18

und ebenfalls von diesen Netzen (Internet-Monitoring und AWS):

Quellen: {larry|sharon|susan}.probe.onyphe.net {poetic|glowing|principled
].monitoring.internet-measurement.com prod-{boron|barium}-{sfo2|us-central|us-east|nyc1|us-southeast}-{
d{2,3}}.{do|li}.binaryedge.ninja azpd{
w{5,8}}.stretchoid.com scan-{
d{2}
[a-z
]}.shadowserver.org pdcscan{2,3}.scanning.cybcube.com ec2-{
w
*}
[us-east-2
]?.compute
[-1
]?.amazonaws.com

Beispiel:

[Warning] Aborted connection 325749 to db: 'unconnected' user: 'unauthenticated' host: '137.184.64.140' (This connection closed normally without authentication)
... 0, 1, 4, 5, 8, 9, 10 Wiederholungen

Zugriffsversuch mittels regulärem Connect

Versuche OHNE Passwort (40x)

Quellen: 196.251.91.50 196.251.114.6 196.251.90.139 196.251.91.43 196.251.114.27 196.251.114.6 196.251.90.186 196.251.114.27 196.251.91.89 196.251.91.47 196.251.91.50 196.251.90.139 196.251.91.69 196.251.91.89 196.251.114.10 196.251.114.6 196.251.91.90 196.251.91.87 196.251.115.18 196.251.114.98 196.251.115.18 196.251.91.89 196.251.115.26 196.251.83.97 196.251.91.53 196.251.90.139 196.251.90.186 34.140.170.97 196.251.91.50 196.251.91.90 196.251.85.11 196.251.91.55 196.251.83.125 196.251.91.80 196.251.83.97 196.251.91.78

Beispiel:

[Warning] Access denied for user 'root'@'196.251.91.69' (using password: NO)

Versuche OHNE und dann MIT Passwort (28 x)

Quellen: 165.154.172.87 165.154.164.92 128.14.237.43 196.251.69.185 37.19.221.171 196.251.118.8 196.251.91.78 196.251.69.185 196.251.91.77 196.251.91.19 196.251.91.78 196.251.91.44 196.251.118.47 196.251.91.32 45.129.56.161 196.251.91.27 196.251.91.19 196.251.91.19 146.70.132.164 196.251.86.26 196.251.91.78 196.251.69.185 196.251.83.136 196.251.91.52 38.240.225.39 196.251.91.27 196.251.69.185 196.251.91.51

Beispiel:

[Warning] Access denied for user 'root'@'196.251.80.168' (using password: NO)
[Warning] Access denied for user 'root'@'196.251.80.168' (using password: YES)
... 1, 2, 3, 13, 27, 28, 37 Wiederholungen

Komplexere Zugriffsversuche mittels Port probing und regulärem Connect (15 x)

Quellen: 8.219.222.66 47.250.81.7 8.219.222.66 34.76.203.56 8.221.136.6 47.254.192.213 (6 x)

Beispiel:

[Warning] Aborted connection 1134 to db: 'unconnected' user: 'unauthenticated' host: '47.254.192.213' (This connection closed normally without authentication)
[Warning] Access denied for user 'root'@'47.254.192.213' (using password: NO)

Quelle: 45.150.237.21 (1 x)

Beispiel:

[Warning] Aborted connection 22965 to db: 'unconnected' user: 'unauthenticated' host: '45.150.237.21' (This connection closed normally without authentication)
... 9 Wiederholungen
[Warning] Access denied for user ''@'45.150.237.21' (using password: NO)

Quellen: 101.36.122.183 152.32.150.7 152.32.245.170 118.193.58.125 165.154.48.24 107.150.117.219 116.90.238.220 165.154.100.58 (8 x)

Beispiel:

[Warning] Aborted connection 2816 to db: 'unconnected' user: 'unauthenticated' host: '165.154.100.58' (This connection closed normally without authentication)
... 0, 1 Wiederholungen
[Warning] Access denied for user ''@'165.154.100.58' (using password: NO)
[Warning] Access denied for user 'root'@'165.154.100.58' (using password: YES)
... 0, 48 Widerholungen

Komplexere Zugriffsversuche mittels regulärem Connect und Port probing (3 x)

Quelle: 104.193.135.104 (1 x)

Beispiel:

[Warning] Access denied for user 'root'@'104.193.135.104' (using password: NO)
[Warning] Aborted connection 47 to db: 'unconnected' user: 'unauthenticated' host: '104.193.135.104' (This connection closed normally without authentication)

Quelle: 196.251.91.18 (1 x)

Beispiel:

[Warning] Access denied for user 'root'@'196.251.91.18' (using password: NO)
[Warning] Access denied for user 'root'@'196.251.91.18' (using password: YES)
... 3 Wiederholungen
[Warning] Aborted connection 1013 to db: 'unconnected' user: 'unauthenticated' host: '196.251.91.18' (This connection closed normally without authentication)

Quelle: 94.102.49.155 (1 x)

Beispiel:

[Warning] Access denied for user 'root'@'94.102.49.155' (using password: NO)
[Warning] Access denied for user 'root'@'94.102.49.155' (using password: YES)
... 1 Wiederholungen
[Warning] Aborted connection 1389 to db: 'unconnected' user: 'unauthenticated' host: '94.102.49.155' (This connection closed normally without authentication)
[Warning] Access denied for user 'root'@'94.102.49.155' (using password: YES)
... 3 Wiederholungen

Diese Muster sind im beobachteten Zeitraum selten aufgetreten.

Fazit

Lösegeld bei Cybercrime zu zahlen lohnt sich nicht!

Outlook / Todoes

Weiter Punkte die man das nächste mal klären, verfeinern und optimieren könnte:

Passwörter herausfinden, mit welchen probiert wird. Ev. MariaDB patchen? (sql_acl.cc)
Etwas mehr spannende Daten zur Verfügung stellen und schauen was dann genau passiert.
Mehrere verschiedene Angriffe aufzeichnen (auf IP gefiltert?). Ev. aus verschiedenen Ländern (USA, China, Russland, Ukraine, …)
Man könnte auch versuchen den Honeypot mit skip_grant_tables zu betreiben um Zugriffe mit Passwort zu ermöglichen?
log_warnings is mit 9 zu verbose eingestellt. Ev. reicht der Default?
Zugriff mit SSL only? Schauen ob TLS schon jemand kann.
Galera Protokoll? War das wirklich ein Angriff oder nur ein Problem im Netzwerk/mit dem Galera Cluster?
Das selbe Spiel mit MySQL machen um zu sehen, ob hier andere Angriffsmuster erfolgen.
Welche DB user werden sonst noch attakiert (CMS)?

Wie verhält sich Galera Cluster mit vielen Knoten?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 24 Jan 2025 17:29:33 +0000

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.

Da ich schon lange mal ausprobieren wollte, wie sich ein Galera Cluster mit zunehmender Anzahl Knoten verhält, war jetzt die Gelegenheit dies mal auszuprobieren.

Die folgenden Fragestellung sollten beantwortet werden:

Wie verhält sich der Durchsatz eines Galera Clusters in Abhängigkeit der Anzahl Galera-Knoten?
Mit welcher Konfiguration erhalten wir den grössten Durchsatz?

Insgesamt wurde mit 5 verschiedenen Versuchs-Parameter experimentiert:

Anzahl Galera Knoten.
Anzahl Client Maschinen (= Instanzen).
Anzahl Threads pro Client (--threads=).
Anzahl Galera Threads (wsrep_slave_threads).
Laufzeit der Tests. Dieser Parameter wurde variiert weil einige Tests während des Laufs abgebrochen sind. Möglicherweise kann mit einer kleineren Rate (--rate) im Lasttest dieser Parameter eliminiert werden. Wie sich zeigte, hatte er sehr wohl einen Einfluss auf das Resultat bzw. den gemessenen Durchsatz (z.B. Test 4b und 5 bzw. 18 und 19).

Insgesamt wurde 35 verschiedene Tests gefahren. Siehe Rohdaten.

Durchsatz in Abhängigkeit der Anzahl Galera Knoten

Throughput related to # nodes
Test	# gal nodes	# threads/client	runtime [s]	tps	runtime [s]
7	1	8	180	596.3	180
8	2	8	180	567.8	180
9	3	8	180	531.9	180
11	4	8	180	495.2	180
12	5	8	180	492.2	180
13	6	8	180	502.9	180
14	7	8	180	459.5	180
15	8	8	180	458.6	180
16	9	8	180	429.2	180

Throughput related to
# nodes

Der Durchsatz im Galera Cluster nahm leicht von 600 tps auf 430 tps ab (28%) wenn die Anzahl Knoten von 1 auf 9 erhöht wurde.

Durchsatz in Abhängigkeit der Anzahl Verbindungen

Hier wurde vor allem mit der Anzahl der Clients und der Threads pro Client variiert. Bei 30 - 40 Connections scheint in diesem Setup das Optimum zu liegen. Das variieren der Anzahl Galera Threads (wsrep_slave_threads) scheint in unserem Fall nicht sonderlich viel bewirkt zu haben. Wesentlich mehr als 1200 tps scheint das System nicht herzugeben. Insbesondere haben auch die Maschinen der beschriebene Galera Knoten nicht mehr allzu viel CPU Idle Zeit gehabt.

Total # connections vs. throughput
Test	# client nodes	# threads/client	# con tot	# gal threads	runtime [s]	tps
16	1	8	8	1	180	429.2
17	2	8	16	1	180	684.5
18	3	8	24	1	180	603.8
19	3	8	24	1	120	925.2
20	3	8	24	1	120	919.8
21	4	8	32	1	120	1081.1
22	5	8	40	1	120	1196.0
23	5	8	40	4	120	1132.2
23b	5	8	40	8	120	1106.0
24	5	16	80	4	120	1233.8
25	5	32	160	4	120	1095.7

Total
# connections vs. throughput

Durchsatz in Abhängigkeit aller möglichen Parametern

Mit dem weiteren Variieren der Parameter insbesondere dem Reduzieren der Anzahl Galera Knoten von 9 auf 3 konnte der Durchsatz von knapp unter 1200 auf knapp über 1400 tps weiter erhöht werden.

Throughput related to various different parameters
Test	# gal nodes	# client nodes	# threads/client	# con tot	tps
23	9	5	8	40	1132.2
23b	9	5	8	40	1106.0
24	9	5	16	80	1233.8
25	9	5	32	160	1095.7
26	8	5	32	160	1132.4
27	7	5	32	160	1207.6
28	6	5	16	80	1333.3
29	5	5	8	40	1278.6
30	5	5	8	40	1281.5
31	4	5	8	40	1374.1
32	3	5	8	40	1304.3
33	3	6	8	48	1428.9

Throughput related to various different parameters

Es scheint also, mit gegebener Hardware irgendwo ein Optimum zu geben welches sich um 3 Galera Knoten und ca 40 Connections befindet. Genauere Abklärungen wären hier spannend…

Statistische Versuchsplanung / Design of Experiments (DoE)

Hier wäre es noch spannend mit der Methode der statistischen Versuchsplanung zu arbeiten um dieses Optimum genauer zu bestimmen bzw. schneller zu finden.

Mettler Toledo: DoE - Statistische Versuchsplanung - Ein statistischer Ansatz zur Reaktionsoptimierung.
Wikipedia.de: Statistische Versuchsplanung.
Versuchsplanung - DoE - Design of Experiments.
Novustat: Quality Engineering: Statistische Versuchsplanung – Unser ultimativer Überblick!.

Harware Spezifikation

VM’s von Hetzner: CX22 (2 vCPU, 4 Gibyte RAM (effektiv: 3.5 Gibyte (warum das?)), 40 Gibyte Disk)

Architecture: x86_64
 CPU op-mode(s): 32-bit, 64-bit
 Address sizes: 40 bits physical, 48 bits virtual
 Byte Order: Little Endian
CPU(s): 2
 On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
 BIOS Vendor ID: QEMU
 Model name: Intel Xeon Processor (Skylake, IBRS, no TSX)
 BIOS Model name: NotSpecified
 CPU family: 6
 Model: 85
 Thread(s) per core: 1
 Core(s) per socket: 2
 Socket(s): 1
 Stepping: 4
 BogoMIPS: 4589.21
 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2a
 pic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap clwb avx512cd avx512bw avx512vl xs
 aveopt xsavec xgetbv1 xsaves arat pku ospke md_clear
Virtualization features:
 Hypervisor vendor: KVM
 Virtualization type: full
Caches (sum of all):
 L1d: 64 KiB (2 instances)
 L1i: 64 KiB (2 instances)
 L2: 8 MiB (2 instances)
 L3: 16 MiB (1 instance)

Benchmark-Tool / Last-Generator

Als Last-Generator wurde sysbench verwendet.

$ dnf install epel-release
$ dnf install sysbench

Jeder Client läuft auf seinem eigenen Schema um Galera Cluster Konflikte zu vermeiden. Dies ist in der Realität nicht in jedem Fall gegeben, stellt aber für Galera den optimalen Fall dar.

SQL> CREATE DATABASE sbtest<n>;

Jeder Client verbindet sich auf einen anderen Galera Knoten (1 - 6 Clients verteilt auf 1 - 9 Galera Knoten).

GALERA_IP=<galera_ip>
DATABASE=sbtest<n>

$ sysbench oltp_common --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --db-driver=mysql prepare
$ sysbench oltp_read_write --time=180 --db-driver=mysql --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --threads=8 --rate=1000 --report-interval=1 run
$ sysbench oltp_common --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --db-driver=mysql cleanup

MariaDB und Galera Konfiguration

[server]

binlog_format = row
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 2
query_cache_size = 0
query_cache_type = 0

wsrep_on = on
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_address = "gcomm://10.0.0.2,10.0.0.3,10.0.0.4,10.0.0.5,10.0.0.6,10.0.0.7,10.0.0.8,10.0.0.9,10.0.0.10,10.0.0.11,10.0.0.12,10.0.0.13,10.0.0.14,10.0.0.15,10.0.0.16,10.0.0.17"
wsrep_cluster_name = 'Galera Cluster'
wsrep_node_address = 10.0.0.2
wsrep_sst_method = rsync
wsrep_sst_auth = sst:secret

Rohdaten

Spielen mit MariaDB Vector für erste KI-Tests

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 27 Aug 2024 21:50:13 +0000

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…

Da ich nicht so der Theoretiker bin sondern eher gerne etwas praktisches mache, habe ich einen kleinen “KI” Prototypen gebaut, den jeder auf seinem Laptop (ohne GPU) sehr schnell und einfach nachbauen kann…

Ich habe mir auch erlaubt die Graphen aus dem Vortrag der MariaDB Foundation zu klauen (siehe Quellen am Ende).

Herunterladen der MariaDB Datenbank mit Vektor Funktionalität

Noch gib es keine MariaDB Pakete mit Vektor-Funktionalität, aber der Quellcode ist bereits verfügbar. Also baut man sich die Binaries halt schnell selber. Dies hat auf meiner alten Kiste eine knappe Stunde gedauert. Wenn die Binaries gebaut sind, kann man sich einen Tarball draus machen:

# tar xf mariadb-11.6.0_vector.tar.gz
# cd mariadb-11.6.0_vector/
# cmake .
# make
# make package

Anschliessend muss die MariaDB Datenbank nur noch gestartet werden.

Das Modell

Um das Konzept des Tokenisierens zu zeigen habe ich mir vorgenommen ein KI für URLs zu bauen und um das Konzept der verschiedenen Modelle und deren Verbesserungspotenzial zu zeigen habe ich eine ganz dummes Modell in PHP gebaut, welches ganz einfach und simple eine URL zerlegt.

Die Frage, die mit diesem Modell beantwortet werden können sollte lautet: “Gib mir ähnliche URLs zur folgenden URL.”

Die dazu gehörende Tabelle sieht wie folgt aus:

DROP TABLE IF EXISTS `urls`;
-- TRUNCATE TABLE is NOT sufficient!!!
CREATE TABLE `urls` (
 `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY
, `url` varchar(1024) DEFAULT NULL
, `title` varchar(2000) DEFAULT NULL
, `embedding` blob NOT NULL
, VECTOR KEY `embedding` (`embedding`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
;

Das Modell fromdual_llm_v1 kann man hier herunter laden.

Wie das Ganze in etwa funktioniert kann man an diesem Schaubild der MariaDB Foundation entnehmen:

Trainieren der KI

Dann wird die Datenbank trainiert: Die URL wird als gegeben angenommen und der Title kann z.B. über einen HTML Scraper ausgelesen werden. Hier 8 Trainings-Datensätze:

Anschliessend werden mittels unseres Models die Vektoren generiert:

(./fromdual_llm_v1.php https://mariadb.org/download/?t=mariadb&p=mariadb&r=11.6.0+Vector&os=source
./fromdual_llm_v1.php https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/
./fromdual_llm_v1.php https://mariadb.org/wp-content/uploads/2024/02/MariaDB-Vector.pdf
./fromdual_llm_v1.php https://mariadb.com/resources/blog/mariadb-vector-preview-is-out/
./fromdual_llm_v1.php https://mariadb.org/projects/mariadb-vector/
./fromdual_llm_v1.php https://metacpan.org/pod/Perl::Tokenizer
./fromdual_llm_v1.php https://www.qwak.com/post/utilizing-llms-with-embedding-stores
./fromdual_llm_v1.php https://github.com/qwak-ai/qwak-examples/tree/main/qa_bot_falcon_chroma) | grep '^<br>['
[0.2, 0.0107421875, 0, 0, 0, 0.0006103515625, 0.00054931640625, 0]
[0.2, 0.0107421875, 0, 0, 0, 0.00262451171875, 0, 0]
[0.2, 0.0107421875, 0, 0, 0, 0.0028076171875, 0, 0]
[0.2, 0.0107421875, 0, 0, 0, 0.0028076171875, 0, 0]
[0.2, 0.0107421875, 0, 0, 0, 0.00152587890625, 0, 0]
[0.2, 0.01171875, 0, 0, 0, 0.001220703125, 0, 0]
[0.2, 0.01171875, 0, 0, 0, 0.0025634765625, 0, 0]
[0.2, 0.009765625, 0, 0, 0, 0.00323486328125, 0, 0]

Mit diesen Vektoren wird jetzt die Datenbank gefüttert (trainiert):

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://mariadb.org/download/?t=mariadb&p=mariadb&r=11.6.0+Vector&os=source'
, 'Download MariaDB Server'
, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.00262451171875, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/'
, 'Creating the MariaDB Binary Tarball'
, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.0006103515625, 0.00054931640625, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://mariadb.org/wp-content/uploads/2024/02/MariaDB-Vector.pdf'
, 'MariaDB Vector'
, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.0028076171875, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://mariadb.com/resources/blog/mariadb-vector-preview-is-out/'
, 'MariaDB Vector preview is out'
, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.0028076171875, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://mariadb.org/projects/mariadb-vector/'
, 'MariaDB Vector'
, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.00152587890625, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://metacpan.org/pod/Perl::Tokenizer'
, 'Perl::Tokenizer - A tiny Perl code tokenizer'
, VEC_FromText('[0.2, 0.01171875, 0, 0, 0, 0.001220703125, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://www.qwak.com/post/utilizing-llms-with-embedding-stores'
, 'Integrating Vector Databases with LLMs: A Hands-On Guide'
, VEC_FromText('[0.2, 0.01171875, 0, 0, 0, 0.0025634765625, 0, 0]')
);

INSERT INTO `urls` (id, url, title, embedding) VALUES (
 NULL
, 'https://github.com/qwak-ai/qwak-examples/tree/main/qa_bot_falcon_chroma'
, 'LLM Model Enhanced with Vector DB'
, VEC_FromText('[0.2, 0.009765625, 0, 0, 0, 0.00323486328125, 0, 0]')
);

Hier mal zuerst ein Überblick, was jetzt in der Datenbank drin steht:

SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
;
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+
| 1 | https://mariadb.org/download/?t=mariadb&p=mariadb&r=11.6.0+Vector&os=source | Download MariaDB Server | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002625,0.000000,0.000000] |
| 2 | https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/ | Creating the MariaDB Binary Tarball | [0.200000,0.010742,0.000000,0.000000,0.000000,0.000610,0.000549,0.000000] |
| 3 | https://mariadb.org/wp-content/uploads/2024/02/MariaDB-Vector.pdf | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002808,0.000000,0.000000] |
| 4 | https://mariadb.com/resources/blog/mariadb-vector-preview-is-out/ | MariaDB Vector preview is out | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002808,0.000000,0.000000] |
| 5 | https://mariadb.org/projects/mariadb-vector/ | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.001526,0.000000,0.000000] |
| 6 | https://metacpan.org/pod/Perl::Tokenizer | Perl::Tokenizer - A tiny Perl code tokenizer | [0.200000,0.011719,0.000000,0.000000,0.000000,0.001221,0.000000,0.000000] |
| 7 | https://www.qwak.com/post/utilizing-llms-with-embedding-stores | Integrating Vector Databases with LLMs: A Hands-On Guide | [0.200000,0.011719,0.000000,0.000000,0.000000,0.002563,0.000000,0.000000] |
| 8 | https://github.com/qwak-ai/qwak-examples/tree/main/qa_bot_falcon_chroma | LLM Model Enhanced with Vector DB | [0.200000,0.009766,0.000000,0.000000,0.000000,0.003235,0.000000,0.000000] |
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+

Suche in der MariaDB Vektor Datenbank

Jetzt kommt der spannend Teil der ganzen Geschichte: Finden wir auch was in unserer MariaDB Vektor Datenbank mit URLs?

Wie das schematisch vor sich geht kann wieder dem Schaubild der MariaDB Foundation entnommen werden:

Als erster Versuch ein perfekter Treffer:

./fromdual_llm_v1.php https://mariadb.org/projects/mariadb-vector/
[0.2, 0.0107421875, 0, 0, 0, 0.00152587890625, 0, 0]

SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
 ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.00152587890625, 0, 0]'))
LIMIT 3
;
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| 5 | https://mariadb.org/projects/mariadb-vector/ | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.001526,0.000000,0.000000] |
| 6 | https://metacpan.org/pod/Perl::Tokenizer | Perl::Tokenizer - A tiny Perl code tokenizer. | [0.200000,0.011719,0.000000,0.000000,0.000000,0.001221,0.000000,0.000000] |
| 2 | https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/ | Creating the MariaDB Binary Tarball | [0.200000,0.010742,0.000000,0.000000,0.000000,0.000610,0.000549,0.000000] |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+

Die erste Zeile stimmt zu 100% überein. Dann werden die Resultate relativ schnell viel schlechter…

Zweiter Versuch eine ähnliche URL:

./fromdual_llm_v1.php https://mariadb.com/kb/en/e4201/
[0.2, 0.0107421875, 0, 0, 0, 0.00079345703125, 0, 0]

SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
 ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.00079345703125, 0, 0]'))
LIMIT 3
;
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| 2 | https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/ | Creating the MariaDB Binary Tarball | [0.200000,0.010742,0.000000,0.000000,0.000000,0.000610,0.000549,0.000000] |
| 5 | https://mariadb.org/projects/mariadb-vector/ | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.001526,0.000000,0.000000] |
| 6 | https://metacpan.org/pod/Perl::Tokenizer | Perl::Tokenizer - A tiny Perl code tokenizer. | [0.200000,0.011719,0.000000,0.000000,0.000000,0.001221,0.000000,0.000000] |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+

Hier würde ich unter den ersten 3 Treffern nur mariadb URLs erwarten. Dies ist aber nicht der Fall. Hier hat unser Modell also noch Verbesserungspotential!

Und noch eine andere ähnliche URL:

./fromdual_llm_v1.php https://mariadb.com/kb/en/vec_totext/
[0.2, 0.0107421875, 0, 0, 0, 0.0010986328125, 0, 0]

SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
 ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[0.2, 0.0107421875, 0, 0, 0, 0.0010986328125, 0, 0]'))
LIMIT 3
;
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+
| 5 | https://mariadb.org/projects/mariadb-vector/ | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.001526,0.000000,0.000000] |
| 2 | https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/ | Creating the MariaDB Binary Tarball | [0.200000,0.010742,0.000000,0.000000,0.000000,0.000610,0.000549,0.000000] |
| 6 | https://metacpan.org/pod/Perl::Tokenizer | Perl::Tokenizer - A tiny Perl code tokenizer. | [0.200000,0.011719,0.000000,0.000000,0.000000,0.001221,0.000000,0.000000] |
+----+----------------------------------------------------------------+-----------------------------------------------+---------------------------------------------------------------------------+

Selbes Problem hier. Der Hostname wird zu wenig gewichtet. Wahrscheinlich kann/muss man hier mit der Streuung spielen welche mariadb.org und mariadb.com erzeugen.

Und zu guter letzt eine URL die gar nicht im Datensatz vorkommt:

./fromdual_llm_v1.php https://www.mongodb.com/blog/post/vector-search-llm-essentials-what-when-why
[0.2, 0.0146484375, 0, 0, 0, 0.00323486328125, 0, 0]
SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
 ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[0.2, 0.0146484375, 0, 0, 0, 0.00323486328125, 0, 0]'))
LIMIT 5
;
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+
| 7 | https://www.qwak.com/post/utilizing-llms-with-embedding-stores | Integrating Vector Databases with LLMs: A Hands-On Guide | [0.200000,0.011719,0.000000,0.000000,0.000000,0.002563,0.000000,0.000000] |
| 6 | https://metacpan.org/pod/Perl::Tokenizer | Perl::Tokenizer - A tiny Perl code tokenizer. | [0.200000,0.011719,0.000000,0.000000,0.000000,0.001221,0.000000,0.000000] |
| 3 | https://mariadb.org/wp-content/uploads/2024/02/MariaDB-Vector.pdf | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002808,0.000000,0.000000] |
| 4 | https://mariadb.com/resources/blog/mariadb-vector-preview-is-out/ | MariaDB Vector preview is out | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002808,0.000000,0.000000] |
| 1 | https://mariadb.org/download/?t=mariadb&p=mariadb&r=11.6.0+Vector&os=source | Download MariaDB Server | [0.200000,0.010742,0.000000,0.000000,0.000000,0.002625,0.000000,0.000000] |
+----+-----------------------------------------------------------------------------+----------------------------------------------------------+---------------------------------------------------------------------------+

Hier scheint das Resultat völlig willkürlich zu sein. Wenn man sich den Vektor der Abfrage mit den Vektoren der Resultate vergleicht macht die Reihenfolge aber schon Sinn… Werden die Dimensionen im Vektor von links nach rechts ausgewertet? Es soll ja der Abstand von zwei Punkten im 8-dimensionalen Raum bestimmt werden…

Verbesserungen im Modell

Die Resultate unserer KI sind noch nicht so sonderlich berauschend. Einerseits liegt das sicher an der sehr beschränkten Datenmenge, andererseits haben wir auch sehr wichtige Kriterien in unserem Model noch nicht abgebildet oder völlig unsinnige Kriterien verwendet.

Verbesserungsvorschläge für ein nächstes Modell: Der hostname könnte zusätzlich noch tokenisiert werden, damit könnte man erreichen dass mariadb.com und mariadb.org näher beieinander liegen.

Die Länge von hostname, path, query und fragment ist sicherlich kein sonderlich schlaues Kriterium um eine Änhlichkeit von URLs abzubilden. Hier wäre also wesentlich mehr Intelligenz im Modell vonnöten. Eine Funktion 1/CRC32(dim) liefert ev. bereits minimal bessere Resultate?

titel könnte mit einbezogen werden, oder zumindest die wichtigsten Worte (Nomen, Verben) aus dem Titel.

Der Dokumententyp (MIME type) könnte mit einbezogen werden: Ist ein PDF ähnlicher zu einem anderen PDF als zu einer CSV Datei oder einer statischen HMTL Seite oder einer dynamischen PHP Seite?

Punkte die beim Spielen aufgefallen sind

Die Anzahl der Dimensionen in einem Vektor scheinen beim ersten INSERT festgelegt zu werden. Wenn man anschliessend Daten mit einer anderen Vektorlänge eingibt erscheint folgender Fehler:

INSERT INTO products (name, description, embedding) VALUES (
 'Coffee Machine'
, 'Built to make the best coffee you can imagine'
, VEC_FromText('[0.2, 0.013671875, 0, 0, 0, 6.103515625E-5, 0, 0]')
);
ERROR 1366 (22007): Incorrect vector value: '...' for column `test`.`products`.`embedding` at row 1

Ein Änderen der Vector-Länge ist mit einem TRUNCATE TABLE Befehl zur Zeit noch NICHT möglich. Die Tabelle muss gelöscht (DROP TABLE) und wieder kreiert (CREATE TABLE) werden.

Das Suchen mit einem kürzeren Vector geht hingegen:

SELECT id, url, title, VEC_ToText(embedding)
 FROM urls
 ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[0.2, 0.0107421875]'))
LIMIT 3
;
+----+-------------------------------------------------------------------------+-------------------------------------+---------------------------------------------------------------------------+
| id | url | title | VEC_ToText(embedding) |
+----+-------------------------------------------------------------------------+-------------------------------------+---------------------------------------------------------------------------+
| 8 | https://github.com/qwak-ai/qwak-examples/tree/main/qa_bot_falcon_chroma | LLM Model Enhanced with Vector DB | [0.200000,0.009766,0.000000,0.000000,0.000000,0.003235,0.000000,0.000000] |
| 2 | https://mariadb.com/kb/en/creating-the-mariadb-binary-tarball/ | Creating the MariaDB Binary Tarball | [0.200000,0.010742,0.000000,0.000000,0.000000,0.000610,0.000549,0.000000] |
| 5 | https://mariadb.org/projects/mariadb-vector/ | MariaDB Vector | [0.200000,0.010742,0.000000,0.000000,0.000000,0.001526,0.000000,0.000000] |
+----+-------------------------------------------------------------------------+-------------------------------------+---------------------------------------------------------------------------+

Ob das Resultat so sinnvoll ist, kann ich (noch) nicht beurteilen.

Quellen

Nachtrag

Wir haben unser Model verbessert (siehe v2). Jetzt sind die Resultate ein wenig besser/genauer.

Für die Benutzung des Modells siehe: ./fromdual_llm_v2.php --help

Partieller physischer Datenbank-Restore für MariaDB und MySQL

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 01 Jul 2024 16:52:00 +0000

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.

In der Praxis sieht die Situation jedoch oft anders aus: Es soll nicht eine ganze Datenbankinstanz wiederhergestellt werden, sondern nur einzelne Datenbanken oder gar einzelne Tabellen, weil nur diese kaputt gegangen sind.

Dies kann in vielen Fällen recht einfach mit den Tools mariadb-dump/mariadb oder mysqldump/mysql (logisches Backup) bewerkstelligt werden. Wenn die Datenbank oder die Tabelle jedoch sehr gross ist, wird die Wiederherstellung nicht in angemessener Zeit (einige Minuten bis wenige Stunden) abgeschlossen sein.

Genau in diesem Fall kommt der sogenannte partielle physische Restore ins Spiel. Partiell steht für eine oder mehrere Tabellen (oder eine ganze Datenbank), physisch für: Es werden nicht einzelne SQL-Anweisungen ausgeführt, sondern die Datenfiles werden physisch zurückgespielt. In diesem Szenario können, eine entsprechende Infrastruktur vorausgesetzt, sehr schnell sehr grosse Datenbestände zurückgespielt werden. Faustregel: Auf fetter Hardware: 1 Tbyte pro Stunde. Auf diese Weise können Datenbank-Restores sehr schnell durchgeführt werden.

MariaDB und MySQL bieten diese Funktionalität bereits von Haus aus an. Für einzelne Tabellen ist der Mechanismus einigermassen praktikabel (siehe Restore partial Backup). Für ganze Datenbanken mit möglicherweise Dutzenden oder Hunderten von Tabellen ist der Bord-Mechanismus jedoch sehr umständlich und fehleranfällig.

Anwendungsfall

Genau hier kommt die neue Funktionalität des FromDual Backup and Recovery Managers (brman) v2.3.0 ins Spiel: Er vereinfacht den partiellen physischen Datenbank-Restore erheblich.

Ein zweites Szenario, in welchem diese neue Funktionalität ebenfalls genutzt werden kann, ist der Umzug einer grossen Datenbank von einer Datenbankinstanz in eine andere Datenbankinstanz (z. B. von Dev nach Prod).

Vorbereitungen für den partiellen physischen Datenbank-Restore

Um eine Datenbank wiederherstellen zu können, muss natürlich zunächst ein sauberes Backup vorliegen. Dieses kann entweder mit dem FromDual Backup Manager (bman) erstellt werden:

PORT=3306
BACKUPNAME=bck_full_2024-07-01
BACKUPDIR=/tmp/bck

./brman/bin/bman --target=brman:secret@127.0.0.1:${PORT} --type=full --mode=physical --policy=daily --backupdir=${BACKUPDIR} --backup-name=${BACKUPNAME} --no-compress

oder man kann das Backup auch einfach mit den MariaDB- (mariadb-backup) oder MySQL-Bordmitteln (xtrabackup) erstellen:

PORT=3306
BACKUPNAME=bck_full_2024-07-01
BACKUPDIR=/tmp/bck
POLICY=daily

mariadb-backup --user=brman --password=secret --host=127.0.0.1 --port=${PORT} --backup --target-dir=${BACKUPDIR}/${POLICY}/${BACKUPNAME}
mariadb-backup --user=brman --password=secret --host=127.0.0.1 --port=${PORT} --prepare --target-dir=${BACKUPDIR}/${POLICY}/${BACKUPNAME}

Partieller physischer Datenbank-Restore

Um einen partiellen physischen Datenbank-Restore durchzuführen, muss die Datenbank, im Gegensatz zum vollständigen physischen Restore, laufen.

Der partielle physische Datenbank-Restore ist dann einfach:

PORT=3306
DATADIR=/var/lib/mysql
BACKUPNAME=bck_full_2024-07-01
BACKUPDIR=/tmp/bck

./brman/bin/rman --target=brman:secret@127.0.0.1:${PORT} --type=schema --mode=physical --policy=daily --schema=test --log=/tmp/rman.log --backupdir=${BACKUPDIR} --datadir=${DATADIR} --backup-name=${BACKUPNAME}

...
Start restore at 2024-07-01 16:29:48
 Backup with tool mariabackup version 10.11.8 (from path /home/mysql/product/mariadb-10.11/bin/mariabackup).
 Parent: We are the parent. Our child is: 63712. Waiting for database daemon...
 Child: We are the child: Starting database daemon...
 Child: Change ownership of database files (/tmp/bck/daily/bck_full_2024-07-01) to mysql
 Child: /home/mysql/product/mariadb-10.11/bin/mariadbd --no-defaults --user=mysql --basedir=/home/mysql/product/mariadb-10.11 --datadir=/tmp/bck/daily/bck_full_2024-07-01 --log-error=/tmp/my.err --port=3360 --socket=/tmp/my.sock --lower-case-table-names=0
 Parent: Tables not InnoDB or sequences: 0
 Parent: Tables with partitions: 0
 Parent: Tables with full-text index: 0
 Parent: InnoDB table `test` found to restore
 Parent: Dump database test
 Parent: /home/mysql/product/mariadb-10.11/bin/mariadb-dump --user=brman --host=127.0.0.1 --port=3360 --routines --events --triggers --no-data --skip-lock-tables --add-drop-database --databases test
 Parent: Shutdown backup database.
 Restore empty database test
 Prepare and export tables: /home/mysql/product/mariadb-10.11/bin/mariabackup --user=brman --host=127.0.0.1 --port=3321 --prepare --export --databases=test --target-dir=/tmp/bck/daily/bck_full_2024-07-01
 SET SESSION foreign_key_checks = 0
 SET SESSION sql_log_bin = off

 Restore table test
 ALTER TABLE `test`.`test` DISCARD TABLESPACE
 cp /tmp/bck/daily/bck_full_2024-07-01/test/test.cfg /home/mysql/database/mariadb-1011/data/test/test.cfg
 cp /tmp/bck/daily/bck_full_2024-07-01/test/test.ibd /home/mysql/database/mariadb-1011/data/test/test.ibd
 chown mysql: /home/mysql/database/mariadb-1011/data/test/test.cfg /home/mysql/database/mariadb-1011/data/test/test.ibd
 ALTER TABLE `test`.`test` IMPORT TABLESPACE
 rm /home/mysql/database/mariadb-1011/data/test/test.cfg
 rm /tmp/bck/daily/bck_full_2024-07-01/test/test.cfg
 ----------------------------------------
 WARNING: You should restart the database now! Otherwise possible future backups may fail. See MDEV-34418 (https://jira.mariadb.org/browse/MDEV-34418).
 ----------------------------------------

 Restore time was: 0d 0h 0' 2"
End restore at 2024-07-01 16:29:50 (rc=0)

Bei MariaDB empfiehlt es sich, die Datenbank anschliessend neu zu starten, bis der Bug MDEV-34418: mariadb-backup fails on database which was partially restored with mariadb-backup behoben ist. Für MySQL kann dieser Schritt entfallen.

Einschränkungen

Zur Zeit sind noch folgende Einschränkungen beim partiellen physischen Restore von Datenbanken mit rman zu beachten:

Es können nur ganze Datenbanken zurückgesichert werden. Das zurücksichern von einzelne Tabellen ist derzeit noch nicht implementiert. Verwenden Sie hierfür die Basis-Bordwerkzeuge.
Die Wiederherstellung partitionierter Tabellen ist derzeit noch nicht implementiert. Verwenden Sie dazu die Basis-Bordwerkzeuge für partitionierte Tabellen.
Ein anschliessendes Point-in-Time-Recovery der Datenbank ist noch nicht implementiert und muss manuell durchgeführt werden.
Ein partielles physisches Datenbank-Restore für einen gesamten Galera-Cluster ist derzeit noch nicht implementiert und muss manuell durchgeführt werden. In diesem Fall wird ein Restore auf einen Galera-Knoten und eine anschliessende Synchronisation der anderen Knoten mittels SST empfohlen.
Beim physischen partiellen Datenbank-Restore wird eine Pseudo-Instanz auf den Backup-Dateien gestartet. Diese Pseudoinstanz benötigt einen freien Port 3360.
Die Backup-Dateien müssen bereits in einem konsistenten Zustand vorliegen (--prepare).
Beim partiellen physischen Datenbank-Restore wird ein logisches Backup der Datenbank ohne die Daten auf der Pseudo-Instanz erstellt. Diese Sicherung wird auf die zu reparierende Instanz zurückgespielt. Das bedeutet, dass alle Objekte (Views, Trigger, Functions, Procedures, Events, etc.), die NACH dem vollständigen physischen Backup erstellt wurden, vor dem partiellen physischen Datenbank-Restore gelöscht werden und anschliessend nicht mehr vorhanden sind.
Die ursprüngliche Datenbankinstanz, von der das Backup erstellt wurde, und die Instanz, auf der der Restore durchgeführt wird, müssen die gleiche Einstellung für lower_case_table_names haben.
Sowohl das Backup als auch die Datenbankinstanz und das rman-Werkzeug müssen sich auf derselben Maschine befinden.
Das Backup muss zur Zeit noch in unkomprimierter Form vorliegen.

Quellen

Verkleinern des InnoDB-System-Tablespaces

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 12 Jun 2024 15:27:10 +0000

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).

Leider ist die Ankündigung dieses Features etwas zu kurz gekommen. In den MariaDB Release Notes heisst es lapidar:

The InnoDB system tablespace is now shrunk by reclaiming unused space at startup (MDEV-14795)

Aus den MariaDB 11.2.0 Release Notes.

Die Gründe, warum dieses Datei ins Unermessliche wachsen kann, sind eigentlich schon lange bekannt und die Massnahmen dagegen sind auch klar (siehe Quellen). Nur sehen wir immer wieder MariaDB-Anwender draussen im Feld, die das Problem nicht oder zu spät auf dem Schirm hatten und nun mit einer viel zu grossen ibdata1-Datei da stehen…

Wie kann das Problem provoziert werden?

Das Problem kann provoziert werden, indem man eine Tabelle im System-Tablespace anlegt:

SQL> SET global innodb_file_per_table = off;

SQL> CREATE TABLE `test` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 `data` varchar(128) DEFAULT NULL,
 `ts` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
 PRIMARY KEY (`id`)
) ENGINE=InnoDB;

und diese dann mit Daten befüllt:

SQL> INSERT INTO test
SELECT NULL, 'Some data to provoke huge data growth in system tablespace', NOW()
;

SQL> INSERT INTO test
SELECT NULL, 'Some data to provoke huge data growth in system tablespace', NOW()
 FROM test LIMIT 1000000
;

...

Während die Tabelle gefüllt wird, kann man auf dem Dateisystem beobachten, wie die Datei ibdata1 anschwillt:

$ while [ 1 ] ; do ll -h ibdata1 ; sleep 5 ; done
-rw-rw---- 1 mysql mysql 12M Jun 2 13:57 ibdata1
-rw-rw---- 1 mysql mysql 76M Jun 12 13:57 ibdata1
-rw-rw---- 1 mysql mysql 76M Jun 12 13:57 ibdata1
-rw-rw---- 1 mysql mysql 140M Jun 12 13:58 ibdata1
-rw-rw---- 1 mysql mysql 204M Jun 12 13:58 ibdata1
-rw-rw---- 1 mysql mysql 268M Jun 12 13:58 ibdata1
-rw-rw---- 1 mysql mysql 332M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 396M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 460M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 524M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 588M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 652M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 716M Jun 12 13:59 ibdata1
-rw-rw---- 1 mysql mysql 780M Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 844M Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 908M Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 972M Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 1.1G Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 1.2G Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 1.3G Jun 12 14:00 ibdata1
-rw-rw---- 1 mysql mysql 1.4G Jun 12 14:00 ibdata1

Wenn die Datei ibdata1 gross genug ist, kann man die Tabelle vom System-Tablespace in einen dedizierten Tablespace verschieben:

SQL> SET global innodb_file_per_table = off;
SQL> ALTER TABLE test.test FORCE;
Query OK, 0 rows affected (33.764 sec)

Und man sieht, wie die neue Datei aufgebaut wird:

$ ll -h ibdata1 test/*
-rw-rw---- 1 mysql mysql 1.4G Jun 12 14:01 ibdata1
-rw-rw---- 1 mysql mysql 1.1K Jun 12 14:01 test/#sql-alter-dca30-12.frm
-rw-rw---- 1 mysql mysql 696M Jun 12 14:01 test/#sql-alter-dca30-12.ibd
-rw-rw---- 1 mysql mysql 1.1K Jun 12 13:56 test/test.frm

-rw-rw---- 1 mysql mysql 1.4G Jun 12 14:01 ibdata1
-rw-rw---- 1 mysql mysql 1.1K Jun 12 14:01 test/test.frm
-rw-rw---- 1 mysql mysql 1.4G Jun 12 14:02 test/test.ibd

Wir haben jetzt also einmal die Daten aber doppelte so viel Platz verbraucht.

Und wie kann man den System-Tablespace wieder verkleinern?

Diese Information ist leider etwas versteck und muss aus der Dokumentation und den MariaDB Jira Issues (siehe Quellen) zusammengesucht werden:

SQL> SET GLOBAL innodb_fast_shutdown=0;
SQL> SHUTDOWN;

Beim Herunterfahren sieht man die entsprechenden Einträge im MariaDB Error Log:

[Note] bin/mariadbd (initiated by: root[root] @ localhost []): Normal shutdown
[Note] InnoDB: FTS optimize thread exiting.
[Note] InnoDB: Truncating system tablespace from 90880 to 768 pages
[Note] InnoDB: System tablespace truncated successfully
[Note] InnoDB: Starting shutdown...
[Note] InnoDB: Dumping buffer pool(s) to /home/mysql/database/mariadb-114/data/ib_buffer_pool
[Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
[Note] InnoDB: Buffer pool(s) dump completed at 240612 14:11:11
[Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
[Note] InnoDB: Shutdown completed; log sequence number 4011132308; transaction id 139
[Note] bin/mariadbd: Shutdown complete

Und wenn man sich die Datei ibdata1 danach auf Platte anschaut, ist sie wieder so klein wie zu Beginn des Experiments:

$ ll ibdata1* -h
-rw-rw---- 1 mysql mysql 12M Jun 12 14:11 ibdata1

Quellen

UNDO logs in InnoDB system tablespace ibdata1
Shrinking InnoDB system tablespace file ibdata1 PoC
Who else is using my memory - File System Cache analysis
InnoDB system tablespace cannot be shrunk (MDEV-14795)
ibdata1 shrinking (MDEV-31462)
InnoDB System Tablespaces - Decreasing the Size

dbstat für MariaDB nach einem Monat produktiver Nutzung

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 25 Apr 2024 12:39:58 +0000

Inhaltsverzeichnis

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).

Das ging soweit ganz gut, bis wir auf unserem MariaDB aktiv/passiv Master/Master Replikationscluster auf die Idee kamen, dbstat auch auf dem passiven dbstat Node zu aktivieren (eine ähnliche Situation hätte man auch bei einem Galera Cluster). Dabei stellten wir fest, dass das Design von dbstat noch Potential hatte. Nachdem dieses Problem behoben war (v0.0.2 und v0.0.3) und auch das Problem gelöst war, wie man Events auf Master UND Slave aktivieren kann (MDEV-33782: Event is always disabled on slave), schien auf den ersten Blick alles in Ordnung. Leider haben wir bei der Korrektur nicht bedacht, dass auch die Daten hätten angepasst werden müssen. Dies hatte zur Folge, dass unsere Replikation über die Osterfeiertage zum Stillstand kam, was dann beim Aufholen zu einem weiteren Problem führte (MDEV-33923: MariaDB parallel replication causes Foreign Key errors).

Nachdem auch dieser kleine Zwischenfall behoben war lief dbstat auf unserem Master/Master Replikationscluster seitdem einwandfrei… Das Produkt dbstat ist Open Source (GPLv2) und kann von GitHub heruntergeladen werden.

Einen Monat später

Datenbanken sollten NICHT mit der Zeit wachsen sondern nur mit der Anzahl {Kunden, Produkte, etc.}, sobald das gewünschte Gleichgewicht (steady state) erreicht ist. In unserer dbstat-Installation haben wir diesen Wert auf 30 Tage gesetzt. Es wird also langsam an der Zeit, dass sich die Grösse von dbstat stabilisiert und nicht weiter wächst…

Ausserdem wäre es spannend zu verstehen, welchen praktischen Nutzen dbstat hat. Deshalb haben wir uns jetzt an die Arbeit gemacht und versuchen, die Ergebnisse von dbstat auszuwerten.

Hier zunächst noch einmal ein Überblick über die 11 laufenden Events:

SQL> SELECT db, name, definer, CONCAT(interval_value, ' ', interval_field) AS 'interval'
 , last_executed, ends, status
 FROM mysql.event
 ORDER BY db, name ASC
;
+--------+-------------------------+------------------+----------+---------------------+------+---------+
| db | name | definer | interval | last_executed | ends | status |
+--------+-------------------------+------------------+----------+---------------------+------+---------+
| dbstat | gather_global_status | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:14 | NULL | ENABLED |
| dbstat | gather_global_variables | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:32 | NULL | ENABLED |
| dbstat | gather_metadata_lock | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:47 | NULL | ENABLED |
| dbstat | gather_processlist | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:28 | NULL | ENABLED |
| dbstat | gather_table_size | dbstat@localhost | 1 DAY | 2024-04-24 00:04:00 | NULL | ENABLED |
| dbstat | gather_trx_and_lck | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:35 | NULL | ENABLED |
| dbstat | purge_global_status | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:08 | NULL | ENABLED |
| dbstat | purge_metadata_lock | dbstat@localhost | 5 MINUTE | 2024-04-24 07:44:37 | NULL | ENABLED |
| dbstat | purge_processlist | dbstat@localhost | 1 MINUTE | 2024-04-24 07:43:58 | NULL | ENABLED |
| dbstat | purge_table_size | dbstat@localhost | 5 MINUTE | 2024-04-24 07:40:04 | NULL | ENABLED |
| dbstat | purge_trx_and_lck | dbstat@localhost | 1 MINUTE | 2024-04-24 07:44:45 | NULL | ENABLED |
+--------+-------------------------+------------------+----------+---------------------+------+---------+

Grösse der Tabellen

Zunächst ist das Wachstum von dbstat selbst interessant. Aber natürlich kann diese Auswertung auch für jede andere Datenbank, Tabelle oder Catalog (kommt in MariaDB 11.7?) durchgeführt werden:

SQL> SET SESSION sql_mode='STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,only_full_group_by';

SQL> SET @machine_name = @@hostname;

SQL> SELECT `table_schema`, SUBSTR(`ts`, 1, 10) AS date
 , ROUND(SUM(`data_length`)/1024/1024, 1) AS data_mb
 , ROUND(SUM(`index_length`)/1024/1024, 1) AS index_mb
 , ROUND(SUM(`data_free`)/1024/1024, 1) AS free_mb
 , ROUND((SUM(`data_length`) + SUM(`index_length`) + SUM(`data_free`))/1024/1024, 1) AS total_mb
 , ROUND(SUM(`table_rows`)/1000/1000, 1) AS rows_m
 FROM `table_size`
 WHERE `machine_name` = @machine_name
 AND `table_catalog` = 'def'
 AND `table_schema` = 'dbstat'
 GROUP BY `table_catalog`, `table_schema`, `date`
 ORDER BY `table_catalog`, `table_schema`, `date` ASC
;
+--------------+------------+---------+----------+---------+----------+--------+
| table_schema | date | data_mb | index_mb | free_mb | total_mb | rows_m |
+--------------+------------+---------+----------+---------+----------+--------+
| dbstat | 2024-03-26 | 762.8 | 1128.6 | 18.0 | 1909.4 | 10.9 |
| dbstat | 2024-03-27 | 835.8 | 1241.6 | 17.0 | 2094.4 | 11.1 |
| dbstat | 2024-03-28 | 837.8 | 1241.6 | 14.0 | 2093.4 | 11.8 |
| dbstat | 2024-03-29 | 960.7 | 1443.6 | 18.0 | 2422.4 | 14.2 |
| dbstat | 2024-03-30 | 960.7 | 1443.6 | 17.0 | 2421.4 | 15.0 |
| dbstat | 2024-03-31 | 1057.7 | 1604.6 | 20.0 | 2682.4 | 16.9 |
| dbstat | 2024-04-01 | 1057.7 | 1602.6 | 21.0 | 2681.4 | 17.6 |
| dbstat | 2024-04-02 | 1172.7 | 1797.6 | 22.0 | 2992.3 | 17.8 |
| dbstat | 2024-04-03 | 1442.8 | 2333.7 | 12.0 | 3788.5 | 22.8 |
| dbstat | 2024-04-04 | 1649.8 | 2723.7 | 13.0 | 4386.5 | 24.4 |
| dbstat | 2024-04-05 | 1649.8 | 2722.7 | 14.0 | 4386.5 | 26.0 |
| dbstat | 2024-04-06 | 1821.8 | 3034.8 | 13.0 | 4869.6 | 24.6 |
| dbstat | 2024-04-07 | 1821.8 | 3034.8 | 14.0 | 4870.6 | 26.2 |
| dbstat | 2024-04-08 | 1989.9 | 3344.8 | 12.0 | 5346.6 | 29.9 |
| dbstat | 2024-04-09 | 1990.9 | 3343.8 | 14.0 | 5348.6 | 31.5 |
| dbstat | 2024-04-10 | 2193.9 | 3712.8 | 13.0 | 5919.7 | 31.6 |
| dbstat | 2024-04-11 | 2193.9 | 3712.8 | 15.0 | 5921.7 | 31.1 |
| dbstat | 2024-04-12 | 2405.8 | 4119.1 | 12.0 | 6537.0 | 34.9 |
| dbstat | 2024-04-13 | 2405.8 | 4119.1 | 14.0 | 6538.9 | 35.7 |
| dbstat | 2024-04-14 | 2480.8 | 4278.9 | 15.0 | 6774.8 | 36.2 |
| dbstat | 2024-04-15 | 2560.8 | 4443.7 | 12.0 | 7016.5 | 37.5 |
| dbstat | 2024-04-16 | 2560.8 | 4443.7 | 12.0 | 7016.5 | 38.2 |
| dbstat | 2024-04-17 | 2640.8 | 4610.6 | 18.0 | 7269.4 | 38.5 |
| dbstat | 2024-04-18 | 2640.9 | 4611.6 | 14.0 | 7266.5 | 39.7 |
| dbstat | 2024-04-19 | 2743.9 | 4826.5 | 14.0 | 7584.3 | 36.9 |
| dbstat | 2024-04-20 | 2826.9 | 4995.5 | 14.0 | 7836.4 | 38.3 |
| dbstat | 2024-04-21 | 2830.9 | 4997.4 | 18.0 | 7846.3 | 39.2 |
| dbstat | 2024-04-22 | 2919.9 | 5177.4 | 14.0 | 8111.3 | 43.2 |
| dbstat | 2024-04-23 | 2923.0 | 5177.3 | 16.0 | 8116.3 | 44.1 |
| dbstat | 2024-04-24 | 3020.0 | 5376.3 | 16.0 | 8412.3 | 41.0 |
| dbstat | 2024-04-25 | 3024.0 | 5377.3 | 17.0 | 8418.3 | 40.9 |
+--------------+------------+---------+----------+---------+----------+--------+

Nimmt man zum Vergleich den Plattenplatz im O/S:

# du -shc *.ibd
8.6G global_status.ibd
308K global_variables.ibd
692K metadata_lock.ibd
97M processlist.ibd
18M table_size.ibd
212K trx_and_lck.ibd
8.7G total

sieht man, dass die Werte aus der Datenbank in etwa stimmen (5% Fehler)…

Wichtig: Die Datenbank dbstat erreicht nach ca. einem Monat eine Grösse von ca. 9 Gbyte auf einem nicht besonders grossen Datenbanksystem.

Man sieht auch, dass sich die Grösse der Datenbank gerade erst stabilisiert.

Wenn man genauer wissen will, welche Tabellen für welchen Teil des Datenvolumens verantwortlich sind, kann man auch in die Daten hineinzoomen bzw. hineindrillen (drill down):

SQL> SELECT `table_name`, SUBSTR(`ts`, 1, 10) AS date
 , ROUND(`data_length`/1024/1024, 1) AS data_mb
 , ROUND(`index_length`/1024/1024, 1) AS index_mb
 , ROUND(`data_free`/1024/1024, 1) AS free_mb
 , ROUND((`data_length` + `index_length` + `data_free`)/1024/1024, 1) AS total_mb
 , ROUND((`data_length` + `index_length` + `data_free`)/1024/1024/8418.26*100, 1) AS pct
 , ROUND(`table_rows`/1000/1000, 1) AS rows_m
 FROM `table_size`
 WHERE `machine_name` = @machine_name
 AND `table_catalog` = 'def'
 AND `table_schema` = 'dbstat'
 AND SUBSTR(`ts`, 1, 10) = CURRENT_DATE()
 ORDER BY rows_m DESC
;
+------------------+------------+---------+----------+---------+----------+------+--------+
| table_name | date | data_mb | index_mb | free_mb | total_mb | pct | rows_m |
+------------------+------------+---------+----------+---------+----------+------+--------+
| global_status | 2024-04-25 | 2949.9 | 5356.9 | 5.0 | 8311.8 | 98.7 | 40.4 |
| processlist | 2024-04-25 | 68.2 | 17.1 | 7.0 | 92.2 | 1.1 | 0.4 |
| global_variables | 2024-04-25 | 0.1 | 0.1 | 0.0 | 0.2 | 0.0 | 0.0 |
| metadata_lock | 2024-04-25 | 0.4 | 0.2 | 0.0 | 0.6 | 0.0 | 0.0 |
| table_size | 2024-04-25 | 5.4 | 3.1 | 5.0 | 13.5 | 0.2 | 0.0 |
| trx_and_lck | 2024-04-25 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
+------------------+------------+---------+----------+---------+----------+------+--------+

Anmerkung: Bitte entschuldigen Sie die Nichverwendung der Window-Funktion!

Der einzige wirkliche Treiber für die Datenmenge auf diesem System ist die Tabelle global_status. Dies ist auch zu erwarten (siehe Mengengerüst von dbstat).

SQL> SELECT SUBSTR(ts, 1, 10) AS date, table_rows/1000/1000 AS k_rows
 , ROUND(data_length/1024/1024, 1) AS data_mb, ROUND(index_length/1024/1024, 1) AS index_mb, ROUND(data_free/1024/1024, 1) AS free_mb
 , ROUND((data_length + index_length + data_free)/1024/1024, 1) AS total_mb
 FROM table_size
 WHERE `machine_name` = @machine_name
 AND `table_catalog` = 'def'
 AND `table_schema` = 'dbstat'
 AND table_name = 'global_status'
 AND ts > DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY)
;
+------------+-------------+---------+----------+---------+----------+
| date | k_rows | data_mb | index_mb | free_mb | total_mb |
+------------+-------------+---------+----------+---------+----------+
| 2024-04-15 | 37.13876300 | 2512.9 | 4433.0 | 4.0 | 6949.9 |
| 2024-04-16 | 37.94217200 | 2512.9 | 4433.0 | 4.0 | 6949.9 | + 0M
| 2024-04-17 | 38.19867500 | 2592.9 | 4600.0 | 7.0 | 7199.9 | + 250M
| 2024-04-18 | 39.39108500 | 2592.9 | 4600.0 | 5.0 | 7197.9 | - 2M
| 2024-04-19 | 36.52539600 | 2691.9 | 4813.0 | 5.0 | 7509.8 | + 312M
| 2024-04-20 | 37.99073500 | 2770.9 | 4980.9 | 6.0 | 7757.8 | + 248M
| 2024-04-21 | 38.79420200 | 2770.9 | 4980.9 | 7.0 | 7758.8 | + 1M
| 2024-04-22 | 42.82606200 | 2855.9 | 5158.9 | 6.0 | 8020.8 | + 263M
| 2024-04-23 | 43.62953000 | 2855.9 | 5158.9 | 7.0 | 8021.8 | + 1M
| 2024-04-24 | 40.54342200 | 2949.9 | 5356.9 | 7.0 | 8313.8 | + 292M
| 2024-04-25 | 40.43067700 | 2949.9 | 5356.9 | 5.0 | 8311.8 | - 2M
+------------+-------------+---------+----------+---------+----------+

Anmerkung: Sorry, ich sollte mich wirklich mit den Window-Funktionen vertraut machen…

Wenn wir die Daten etwas genauer analysieren, sehen wir, dass sich die Anzahl der Rows in den letzten 4 Tagen langsam stabilisiert hat (Achtung: table_rows wird berechnet (aus der Anzahl der Blöcke und der durchschnittlichen Zeilenlänge?) und ist kein exakter Wert), aber die “Datenmenge” hat bis gestern weiter zugenommen, was wahrscheinlich auf das “Zerfleddern” der Tabellen und Indizes zurückzuführen ist…

Der Primärschlüssel der Tabelle global_status wurde gewählt, um die Lokalisierung der Daten zu optimieren:

PRIMARY KEY (`machine_name`,`variable_name`,`ts`),

Die Lage sollte sich in den nächsten Tagen beruhigen. In 2 bis 4 Wochen müssen wir die Lage erneut prüfen.

Zusammenfassung: Ich würde sagen, dass dieses Feature die Anforderungen erfüllt und hilft, das Datenwachstum zu verstehen.

Liste der Prozesse

Da wir keine ernsthaften Lastprobleme in unseren Datenbanken haben, ist diese Funktion in unserem Fall nicht so interessant. Wir können zum Beispiel sehen, was eine (persistente) Verbindung gemacht hat:

SQL> SELECT connection_id, ts, command, time, state, SUBSTR(REGEXP_REPLACE(REPLACE(query, "<br>n", ' '), '<br> +', ' '), 1, 64)
 FROM processlist
 WHERE machine_name = @machine_name
 AND command != 'Sleep'
 AND connection_id = @connection_id
 AND state NOT IN (
 'Waiting for next activation'
 , 'Master has sent all binlog to slave; waiting for more updates'
 , 'Waiting for master to send event'
 , 'Slave has read all relay log; waiting for more updates'
 )
 ORDER BY ts ASC
;
+---------------+---------------------+---------+-------+----------------+----------------------------------------------------------------------+
| connection_id | ts | command | time | state | SUBSTR(REGEXP_REPLACE(REPLACE(query, "<br>n", ' '), '<br> +', ' '), 1, 64) |
+---------------+---------------------+---------+-------+----------------+----------------------------------------------------------------------+
| 18 | 2024-04-17 12:30:28 | Query | 0.029 | Sending data | select pp.item_preprocid,pp.itemid,pp.type,pp.params,pp.step,h.h |
| 18 | 2024-04-17 14:58:28 | Query | 0.009 | Writing to net | select itemtagid,itemid,tag,value from item_tag |
| 18 | 2024-04-18 06:24:28 | Query | 0.003 | Sending data | select pp.item_preprocid,pp.itemid,pp.type,pp.params,pp.step,h.h |
| 18 | 2024-04-18 11:34:28 | Query | 0.030 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-18 16:39:28 | Query | 0.006 | Sending data | select itemid,functionid,name,parameter,triggerid from functions |
| 18 | 2024-04-18 19:12:28 | Query | 0.014 | Sending data | select triggerid,description,expression,error,priority,type,valu |
| 18 | 2024-04-18 21:49:28 | Query | 0.004 | Writing to net | select i.itemid,i.hostid,i.templateid from items i inner join ho |
| 18 | 2024-04-19 00:21:28 | Query | 0.032 | Sending data | select pp.item_preprocid,pp.itemid,pp.type,pp.params,pp.step,h.h |
| 18 | 2024-04-19 02:59:28 | Query | 0.017 | Writing to net | select triggerid,description,expression,error,priority,type,valu |
| 18 | 2024-04-19 05:39:28 | Query | 0.052 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-19 08:19:28 | Query | 0.000 | Statistics | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-19 13:26:28 | Query | 0.075 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-19 15:57:28 | Query | 0.027 | Writing to net | select itemtagid,itemid,tag,value from item_tag |
| 18 | 2024-04-19 18:33:28 | Query | 0.010 | Sending data | select itemtagid,itemid,tag,value from item_tag |
| 18 | 2024-04-19 21:10:28 | Query | 0.008 | Sending data | select pp.item_preprocid,pp.itemid,pp.type,pp.params,pp.step,h.h |
| 18 | 2024-04-19 23:50:28 | Query | 0.067 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 02:28:28 | Query | 0.008 | Sending data | select triggerid,description,expression,error,priority,type,valu |
| 18 | 2024-04-20 05:08:28 | Query | 0.052 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 07:44:28 | Query | 0.123 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 10:21:28 | Query | 0.144 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 12:55:28 | Query | 0.004 | Sending data | select i.itemid,i.hostid,i.templateid from items i where i.flags |
| 18 | 2024-04-20 15:35:28 | Query | 0.092 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 18:12:28 | Query | 0.041 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 20:47:28 | Query | 0.113 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-20 23:25:28 | Query | 0.101 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 02:03:28 | Query | 0.120 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 04:42:28 | Query | 0.099 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 07:18:28 | Query | 0.015 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 12:32:28 | Query | 0.018 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 15:06:28 | Query | 0.091 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-21 20:16:28 | Query | 0.012 | Sending data | select itemtagid,itemid,tag,value from item_tag |
| 18 | 2024-04-22 06:44:28 | Query | 0.161 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-22 09:21:28 | Query | 0.000 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-22 11:54:28 | Query | 0.020 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-22 14:23:28 | Query | 0.067 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-22 16:59:28 | Query | 0.128 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-22 22:05:28 | Query | 0.078 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 00:38:28 | Query | 0.084 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 03:15:28 | Query | 0.098 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 05:52:28 | Query | 0.000 | starting | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 08:27:28 | Query | 0.011 | Sending data | select pp.item_preprocid,pp.itemid,pp.type,pp.params,pp.step,h.h |
| 18 | 2024-04-23 10:58:28 | Query | 0.000 | Sending data | select i.itemid,i.hostid,i.templateid from items i inner join ho |
| 18 | 2024-04-23 13:31:28 | Query | 0.110 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 16:01:28 | Query | 0.023 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 18:35:28 | Query | 0.095 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-23 21:10:28 | Query | 0.017 | Writing to net | select itemtagid,itemid,tag,value from item_tag |
| 18 | 2024-04-23 23:44:28 | Query | 0.014 | Sending data | select triggerid,description,expression,error,priority,type,valu |
| 18 | 2024-04-24 02:21:28 | Query | 0.024 | Sending data | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
| 18 | 2024-04-24 07:33:28 | Query | 0.046 | Writing to net | select i.itemid,i.hostid,i.status,i.type,i.value_type,i.key_,i.s |
+---------------+---------------------+---------+-------+----------------+----------------------------------------------------------------------+

Wichtig ist auch, dass wir in dieser Auswertung nur die Einträge sehen, wenn der Thread ETWAS gemacht hat (State Sleep haben wir ausgeblendet). Interessant ist auch, dass wir diese (persistente) Verbindung nicht vor dem 17. April sehen, aber ich habe im Moment KEINE Erklärung dafür aus operativer Sicht (Restart etc.). Wahrscheinlich muss die Anwendung (Zabbix) das erklären.

Globale Variablen

Interessant sind auch die Informationen in der Tabelle global_variables:

SQL> SELECT variable_name, ts, variable_value
 FROM global_variables
 WHERE machine_name = @machine_name
 AND variable_name IN (
 SELECT variable_name
 FROM global_variables
 WHERE machine_name = @machine_name
 GROUP BY variable_name
 HAVING COUNT(*) > 1
 )
 ORDER BY ts, variable_name
;
+---------------------------+---------------------+----------------+
| variable_name | ts | variable_value |
+---------------------------+---------------------+----------------+
| auto_increment_increment | 2024-03-09 22:10:42 | 1 |
| auto_increment_offset | 2024-03-09 22:10:42 | 1 |
| read_only | 2024-03-09 22:10:42 | OFF |
| slave_parallel_max_queued | 2024-03-09 22:10:42 | 131072 |
| slave_parallel_threads | 2024-03-09 22:10:42 | 0 |
| slave_parallel_workers | 2024-03-09 22:10:42 | 0 |
| slave_skip_errors | 2024-03-09 22:10:42 | OFF |
| system_time_zone | 2024-03-09 22:10:42 | CET |

| read_only | 2024-03-27 09:42:50 | ON |
| slave_skip_errors | 2024-03-27 12:33:13 | 1032 |
| slave_skip_errors | 2024-03-27 12:35:13 | OFF |
| slave_skip_errors | 2024-03-27 12:42:13 | 1032 |
| slave_skip_errors | 2024-03-27 12:50:13 | OFF |

| slave_parallel_threads | 2024-04-02 10:17:32 | 8 |
| slave_parallel_workers | 2024-04-02 10:17:32 | 8 |
| slave_parallel_max_queued | 2024-04-02 10:22:32 | 1048576 |
| slave_parallel_max_queued | 2024-04-02 10:23:32 | 4194304 |
| slave_parallel_max_queued | 2024-04-02 10:25:32 | 16777216 |
| slave_parallel_threads | 2024-04-02 10:25:32 | 16 |
| slave_parallel_workers | 2024-04-02 10:25:32 | 16 |
| slave_parallel_threads | 2024-04-02 10:28:32 | 32 |
| slave_parallel_workers | 2024-04-02 10:28:32 | 32 |
| auto_increment_increment | 2024-04-02 10:39:32 | 2 |
| auto_increment_offset | 2024-04-02 10:39:32 | 2 |
| slave_parallel_max_queued | 2024-04-02 10:57:32 | 131072 |
| slave_parallel_threads | 2024-04-02 10:57:32 | 0 |
| slave_parallel_workers | 2024-04-02 10:57:32 | 0 |
| system_time_zone | 2024-04-02 10:57:32 | CEST |

| slave_parallel_max_queued | 2024-04-16 14:06:32 | 16777216 |
| slave_parallel_threads | 2024-04-16 14:06:32 | 8 |
| slave_parallel_workers | 2024-04-16 14:06:32 | 8 |
| slave_parallel_max_queued | 2024-04-16 14:26:32 | 131072 |
| slave_parallel_threads | 2024-04-16 14:26:32 | 0 |
| slave_parallel_workers | 2024-04-16 14:26:32 | 0 |

| slave_parallel_max_queued | 2024-04-17 09:03:32 | 16777216 |
| slave_parallel_threads | 2024-04-17 09:03:32 | 16 |
| slave_parallel_workers | 2024-04-17 09:03:32 | 16 |

| slave_parallel_max_queued | 2024-04-24 08:26:32 | 131072 |
| slave_parallel_threads | 2024-04-24 08:26:32 | 0 |
| slave_parallel_workers | 2024-04-24 08:26:32 | 0 |
| read_only | 2024-04-24 08:42:32 | OFF |
+---------------------------+---------------------+----------------+

Hier sieht man sehr genau, wann und was an der Datenbank gemacht wurde:

Am 9. März wurde dbstat zum ersten Mal installiert.
Dann am 27. März (vor Ostern) scheint es dann Probleme mit der Replikation gegeben zu haben (hier wurde die neue Version von dbstat installiert, die das gleichzeitige Sammeln auf Master und Slave erlaubt. Dies führte zu Replikationsfehlern, die teilweise behoben wurden).
Am 2. April (nach Ostern) haben wir dann versucht, den Rückstand mit der parallelen Replikation aufzuholen. Man sieht auch, dass AUTO_INCREMENT_OFFSET und AUTO_INCREMENT_INCREMENT geändert wurden. Hier haben wir einen Fehler in der Datenbankkonfiguration korrigiert…
Ausserdem ist zu sehen, dass die Zeitzone von CET auf CEST geändert hat (Sommerzeit!) Warum erst am 2. April ist mir nicht ganz klar. (Vielleicht weil das über die Replikation gekommen ist?)
Dann haben wir am 16. und 17. April haben wir versucht einen “Bug” in der parallelen Replikation zu reproduzieren. Anscheinend haben wir den Wert nicht zurückgesetzt. Denn erst nach dem Neustart am 24. April (übliches zweiwöchentliches Wartungsfenster) wurde der Wert wieder zurückgesetzt.
Am 24. April sieht man auch, dass die Datenbank jetzt die Rolle des aktiven Masters übernommen hat (read_only = off). Es hat also ein Gracefull-Switchover stattgefunden…

Fazit: Ein sehr nützliches Feature um zu sehen, wann was geändert wurde. Obwohl ich alle diese Operationen genau verfolgt habe, bin ich doch erstaunt über die Aussagekraft dieses Features. Ich würde mir wünschen, dass es in allen Datenbanken installiert wird…

Metadata Lock und InnoDB Transaction Lock

Aufgrund des geringen Traffics auf unseren Datenbanken sehen wir hier leider nicht allzu viel Spannendes.

Hier sind die Metadata Locks, die wir in den den letzten 24 Stunden auf dem Master “erwischt” haben:

+---------------+---------------------+--------+-----------------+--------------+---------------+-----------------+----------------------------------------------------------------------+
| connection_id | ts | user | host | table_schema | table_name | state | SUBSTR(REGEXP_REPLACE(REPLACE(query, "<br>n", ' '), '<br> +', ' '), 1, 64) |
+---------------+---------------------+--------+-----------------+--------------+---------------+-----------------+----------------------------------------------------------------------+
| 18 | 2024-04-23 14:16:47 | zabbix | localhost:51252 | zabbix | triggers | Writing to net | select triggerid,description,expression,error,priority,type,valu |
| 1325025 | 2024-04-23 16:01:47 | zabbix | localhost:50150 | | | init for update | delete from history_text where itemid=85477 and clock<1678167661 |
| 1325025 | 2024-04-23 16:01:47 | zabbix | localhost:50150 | zabbix | history_text | init for update | delete from history_text where itemid=85477 and clock<1678167661 |
| 1365229 | 2024-04-24 02:13:47 | root | localhost:38096 | dbstat | global_status | Writing to net | SELECT /*!40001 SQL_NO_CACHE */ `machine_name`, `variable_name`, |
| 18 | 2024-04-24 03:10:47 | zabbix | localhost:51252 | zabbix | item_tag | Writing to net | select itemtagid,itemid,tag,value from item_tag |
| 1368524 | 2024-04-24 04:41:47 | zabbix | localhost:38112 | | | | NULL |
| 1368524 | 2024-04-24 04:41:47 | zabbix | localhost:38112 | zabbix | history_uint | | NULL |
| 18 | 2024-04-24 05:46:47 | zabbix | localhost:51252 | zabbix | item_tag | Sending data | select itemtagid,itemid,tag,value from item_tag |
+---------------+---------------------+--------+-----------------+--------------+---------------+-----------------+----------------------------------------------------------------------+

InnoDB-Locks haben wir in den letzten 24 Stunden repektive 7 Tage keine gefunden.

Es wäre interessant, ein System zu sehen, auf dem mehr passiert…

Globaler Status

Wenn ein normales Datenbankmonitoring wie z.B. der FromDual Performance Monitor für MariaDB und MySQL (fpmmm) mit Zabbix verwendet wird, ist dieses Feature nicht unbedingt notwendig. Die meisten unserer Kunden haben jedoch kein brauchbares Monitoring im Einsatz. Daher wäre dieses Feature sehr nützlich für Post-Morten-Analysen…

Zum Beispiel InnoDB-Lock-Waits, minuten-granular über die letzten 30 Tage (analog zu sar aus sysstat):

Hier sieht man, dass die Datenbank am 10. April zwischen 08:37 und 08:41 neu gestartet wurde. Das könnte man zwar auch anders herausfinden, ist aber leider oft aus verschiedenen Gründen nicht möglich (Error Log wegrotiert, etc.).

Interessant ist auch der Trendbruch um den 2. April. Zu diesem Zeitpunkt haben wir mit der parallelen Replikation rumexperimentiert. Es sollte kein Failover gewesen sein (siehe GLOBAL VARIABLES, weiter oben).

Obwohl die parallele Replikation später wieder deaktiviert wurde, gab es mehr Locks. Eine ähnliche Situation um den 16./17. April auch hier haben wir mit der parallelen Replikation herumgespielt, was sich auf das Locking-Verhalten ausgewirkt zu haben scheint.

Auch mit diesem Feature gibt es viele Möglichkeiten die Datenbank zu untersuchen. Leider ist unsere Datenbank relativ langweilig: Hauptsächlich monotoner Traffic (der durch das Monitoring reichlich vorhanden ist) und aussergwöhnlicher Traffic in sehr geringem Umfang.

Anmerkung: Dieser Text wurde mit der Unterstützung von DeepL optimiert.

MariaDBs parallele Replikation zum Aufholen

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 08 Apr 2024 11:01:45 +0000

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.

Per default ist die parallel Replikation deaktiviert:

SQL> SHOW GLOBAL VARIABLES LIKE '%parallel%';
+-------------------------------+------------+
| Variable_name | Value |
+-------------------------------+------------+
| slave_domain_parallel_threads | 0 |
| slave_parallel_max_queued | 131072 |
| slave_parallel_mode | optimistic |
| slave_parallel_threads | 0 |
| slave_parallel_workers | 0 |
+-------------------------------+------------+

Durch setzen der Server Variablen slave_parallel_threads wird die parallele Replikation aktiviert:

SQL> SET GLOBAL slave_parallel_threads = 8;
ERROR 1198 (HY000): This operation cannot be performed as you have a running slave ''; run STOP SLAVE '' first

Dies muss aber bei gestoppter Replikation erfolgen:

SQL> STOP SLAVE;
SQL> SET GLOBAL slave_parallel_threads = 8;
SQL> START SLAVE;

Anschliessend hat die Replikation etwas schneller aufgeholt. Da wir aber ungeduldig waren, haben wir versucht, das ganze noch schneller hin zu kriegen. Mit dem Befehl:

SQL> SHOW SLAVE STATUS<br>G
...
Slave_SQL_Running_State: Waiting for room in worker thread event queue
...

haben wir die folgende Meldung gefunden. Man würde sie auch über den Befehl SHOW PROCESSLIST sehen:

SQL> SHOW PROCESSLIST;
+--------+-------------+- ... -+-----------+------+-----------------------------------------------+- ... -+
| Id | User | ... | Command | Time | State | ... |
+--------+-------------+- ... -+-----------+------+-----------------------------------------------+- ... -+
... ... ...
| 212496 | system user | ... | Slave_SQL | 16 | Waiting for room in worker thread event queue | ... |
+--------+-------------+- ... -+-----------+------+-----------------------------------------------+- ... -+

Gemäss Doku kann es in diesem Fall helfen, die Variable slave_parallel_max_queued etwas zu vergrössern (Achtung: Oom!).

SQL> STOP SLAVE;
SQL> SET GLOBAL slave_parallel_max_queued = 1*1024*1024;
SQL> SHOW GLOBAL VARIABLES LIKE '%parallel%';
+-------------------------------+------------+
| Variable_name | Value |
+-------------------------------+------------+
| slave_domain_parallel_threads | 0 |
| slave_parallel_max_queued | 1048576 |
| slave_parallel_mode | optimistic |
| slave_parallel_threads | 8 |
| slave_parallel_workers | 8 |
+-------------------------------+------------+
SQL> START SLAVE;

Wir haben mit den Werten slave_parallel_threads im Bereich von 4 bis 32 (bei 8 vCores) und bei slave_parallel_max_queued im Bereich von 128 kbyte bis 32 Mbyte rumgespielt. Achtung: Nicht übertreiben: 32 Threads x 32 Mbyte = 1 Gbyte RAM (Oom)!

Um herauszufinden, welche Werte das Optimum sind, müsste man ausführlicher testen und messen. Jedenfalls hat die Replikation nach circa einer Stunde die 5 Tage Rückstand aufgeholt, gegen Schluss etwas mehr als zu Beginn, was hoffentlich durch unsere Konfigurationsanpassungen verursacht wurde.

Je nach dem, was gerade an DML Statements läuft sieht man, dass alle Threads genutzt werden können oder die einen Threads auf andere Threads warten müssen:

SQL> SHOW PROCESSLIST;
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+
| Id | User | Command | Time | State | Info |
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+
| 2 | event_scheduler | Daemon | 506179 | Waiting for next activation | NULL |
| 191154 | root | Query | 0 | starting | show pr... |
| 208669 | replication | Binlog Dump | 297 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 212495 | system user | Slave_IO | 20 | Waiting for master to send event | NULL |
| 212497 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212498 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212499 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212500 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212501 | system user | Slave_worker | 0 | Write_rows_log_event::write_row(-1) on table `history_uint` | insert ... |
| 212502 | system user | Slave_worker | 0 | Write_rows_log_event::write_row(-1) on table `history_uint` | insert ... |
| 212503 | system user | Slave_worker | 0 | Write_rows_log_event::write_row(-1) on table `history_str` | insert ... |
| 212504 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212505 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212506 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212507 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212510 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212509 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212508 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212511 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212512 | system user | Slave_worker | 0 | Waiting for prior transaction to commit | NULL |
| 212496 | system user | Slave_SQL | 16 | Waiting for room in worker thread event queue | NULL |
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+

SQL> SHOW PROCESSLIST;
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+
| Id | User | Command | Time | State | Info |
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+
| 2 | event_scheduler | Daemon | 506197 | Waiting for next activation | NULL |
| 191154 | root | Query | 0 | starting | show pr... |
| 208669 | replication | Binlog Dump | 315 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 212495 | system user | Slave_IO | 37 | Waiting for master to send event | NULL |
| 212497 | system user | Slave_worker | 0 | Delete_rows_log_event::ha_delete_row(-1) on table `history` | delete ... |
| 212498 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212499 | system user | Slave_worker | 0 | Delete_rows_log_event::ha_delete_row(-1) on table `history` | delete ... |
| 212500 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212501 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212502 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212503 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212504 | system user | Slave_worker | 0 | Delete_rows_log_event::ha_delete_row(-1) on table `history` | delete ... |
| 212505 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212506 | system user | Slave_worker | 0 | Delete_rows_log_event::ha_delete_row(-1) on table `history` | delete ... |
| 212507 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212510 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212509 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212508 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212511 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212512 | system user | Slave_worker | 0 | Delete_rows_log_event::find_row(-1) on table `history` | delete ... |
| 212496 | system user | Slave_SQL | 11 | Waiting for room in worker thread event queue | NULL |
+--------+-----------------+--------------+--------+---------------------------------------------------------------+------------+

Unser Monitoring hat uns auch schön angezeigt, dass die CPU Load hoch ging, das I/O-System mehr zu tun kriegte und mehr Rows modifiziert wurden…

Was ebenfalls auffiel ist, dass mit parallel Replication plötzlich Foreing Key Fehler auftraten, ein Phänomen, dass wir so vorher noch nicht beobachtet hatten:

FromDual.maas2.prod2 - Warning: InnoDB Foreign Key error detected

Trigger: InnoDB Foreign Key error detected
Trigger status: PROBLEM
Trigger severity: Warning
Trigger URL: https://fromdual.com/innodb-foreign-key-error-detected

Item values: 1

1. InnoDB new Foreign Key error (FromDual.maas2.prod2:FromDual.MySQL.innodb.ForeignKey_new): 1

Mit dem Befehl SHOW ENGINE INNODB STATUS<br>G kann man diese entsprechend inspizieren oder im Monitoring anschauen:

------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-04-02 10:36:39 0x7f36088ff640 Transaction:
TRANSACTION 7199599266, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
6 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1
MariaDB thread id 228555, OS thread handle 139870048613952, query id 28453893 Write_rows_log_event::write_row(-1) on table `alerts`
insert into alerts (alertid,actionid,eventid,userid,clock,mediatypeid,sendto,subject,message,status,error,esc_step,alerttype,acknowledgeid,parameters) values (203687,4,471733,3,1712044003,1,'xxx@fromdual.com','Zabbix server - High: Too many processes on Zabbix server','Trigger: Too many processes on Zabbix server
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values: 309

1. Number of processes (Zabbix server:proc.num[]): 309',3,'',1,0,null,'{}')
Foreign key constraint fails for table `zabbix`.`alerts`:
,
 CONSTRAINT `c_alerts_2` FOREIGN KEY (`eventid`) REFERENCES `events` (`eventid`) ON DELETE CASCADE in parent table, in index alerts_3 tuple:
DATA TUPLE: 2 fields;
 ...

But in parent table `zabbix`.`events`, in index PRIMARY,
the closest match we can find is record:
PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 ...

Quellen

Parallel Replication

MariaDB Server aus den Quellen bauen

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 04 Apr 2024 14:53:18 +0000

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…

I habe hierzu die MariaDB Dokumentation Get, Build and Test Latest MariaDB the Lazy Way befolgt um den Server zu bauen.

Auf Ubuntu 22.04 hat es bei mir, aus mir nicht bekannten Gründen, nicht funktioniert. Also habe ich mir einen Ubuntu 23.04 (Lunar Lobster) LXC Container geclont und darin den MariaDB Server gebaut.

Damit das ganze funktioniert musste aber vorher noch im Container /etc/apt/sources.list durch die Paketquellen ergänzt werden:

deb-src http://de.archive.ubuntu.com/ubuntu lunar main restricted universe multiverse
deb-src http://de.archive.ubuntu.com/ubuntu lunar-updates main restricted universe multiverse
deb-src http://de.archive.ubuntu.com/ubuntu lunar-security main restricted universe multiverse
deb-src http://de.archive.ubuntu.com/ubuntu lunar-backports main restricted universe multiverse

Dann wurde nach Vorgabe weiter verfahren:

shell> apt install build-essential bison
shell> apt build-dep mariadb-server

Der Entsprechende Branch wurde geclont:

shell> # git clone https://github.com/andremralves/server.git mariadb-MDEV-33782
shell> # git branch --all
shell> git clone --branch MDEV-33782 --single-branch https://github.com/andremralves/server.git mariadb-MDEV-33782
shell> cd mariadb-MDEV-33782
shell> # git checkout 11.5

und dann der Server gebaut. Dies hat auf meiner alten Maschine etwa 20 Minuten gedauert. CMake ist noch auf einen Fehler gelaufen, welcher mit dem Nachinstallieren des entsprechenden Pakets gelöst wurde (MDEV-33815):

shell> apt install libgnutls28-dev
shell> cmake . -DBUILD_CONFIG=mysql_release && make -j8

Die Tests wurden ausgeführt:

shell> cd mysql-test
shell> ./mtr rpl.rpl_create_drop_event

Und dann ein Binary-Tarball gebaut.

shell> make package
Run CPack packaging tool...
CPack: Create package using TGZ
CPack: Install projects
CPack: - Run preinstall target for: MariaDB
CPack: - Install project: MariaDB []
CPack: Create package
CPack: - package: /root/mariadb-MDEV-33782/mariadb-11.5.0-linux-x86_64.tar.gz generated.

MaxScale Konfigurations-Synchronisation

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 02 Apr 2024 17:43:29 +0000

Inhaltsverzeichnis

Übersicht

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

Es geht hier nicht primär um einen MariaDB Replikations-Cluster oder einen MariaDB Galera Cluster sondern um einen Cluster bestehend aus zwei oder mehreren MaxScale Knoten. Bzw. etwas genauer gesagt, den Austausch der Konfiguration unter diesen MaxScale Knoten.

Pon Suresh Pandian hat bereits 2022 einen Blog-Artikel über dieses Feature geschrieben, der noch etwas ausführlicher ist, als dieser Beitrag hier.

Vorbereitungen

Es wurde eine Incus Container-Umgebung vorbereitet, bestehend aus 3 Datenbank-Containern (deb12-n1 (10.139.158.33), deb12-n2 (10.139.158.178), deb12-n3(10.139.158.39)) und 2 MaxScale Containern (deb12-mxs1 (10.139.158.66), deb12-mxs2(10.139.158.174)). Die Datenbankversion ist eine MariaDB 10.11.6 aus dem Debian-Repository und MaxScale wurde in der Version 22.08.5 von der MariaDB plc Website heruntergeladen.

Die Datenbank-Konfiguration sieht für alle 3 Knoten analog aus:

#
# /etc/mysql/mariadb.conf.d/99-fromdual.cnf
#

[server]

server_id = 1
log_bin = deb12-n1-binlog
binlog_format = row
bind_address = *
proxy_protocol_networks = ::1, 10.139.158.0/24, localhost
gtid_strict_mode = on
log_slave_updates = on
skip_name_resolve = on

Die MaxScale Knoten wurden wie im Artikel Sharding mit MariaDB MaxScale beschrieben gebaut.

Der maxscale_admin User hat genau die selben Rechte wie dort beschrieben, der maxscale_monitor User hat folgende Rechte erhalten:

RELOAD, SUPER, REPLICATION SLAVE, READ_ONLY ADMIN

Siehe auch hier: Required Grants.

Die MaxScale Start-Konfiguration sieht wie folgt aus:

#
# /etc/maxscale.cnf
#

[maxscale]
threads = auto
admin_gui = false

[deb12-n1]
type = server
address = 10.139.158.33
port = 3306
proxy_protocol = true

[deb12-n2]
type = server
address = 10.139.158.178
port = 3306
proxy_protocol = true

[Replication-Monitor]
type = monitor
module = mariadbmon
servers = deb12-n1,deb12-n2
user = maxscale_monitor
password = secret
monitor_interval = 500ms
auto_failover = true
auto_rejoin = true
enforce_read_only_slaves = true
replication_user = replication
replication_password = secret
cooperative_monitoring_locks = majority_of_running

[WriteListener]
type = listener
service = WriteService
port = 3306

[WriteService]
type = service
router = readwritesplit
servers = deb12-n1,deb12-n2
user = maxscale_admin
password = secret
transaction_replay = true
transaction_replay_timeout = 30s

Wichtig: Die Konfiguration sollte auf allen MaxScale Knoten gleich aussehen!

Und dann noch ein paar Checks um sicher zu sein, dass alles stimmt:

shell> maxctrl list listeners
┌───────────────┬──────┬──────┬─────────┬──────────────┐
│ Name │ Port │ Host │ State │ Service │
├───────────────┼──────┼──────┼─────────┼──────────────┤
│ WriteListener │ 3306 │ :: │ Running │ WriteService │
└───────────────┴──────┴──────┴─────────┴──────────────┘

shell> maxctrl list services
┌──────────────┬────────────────┬─────────────┬───────────────────┬────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Targets │
├──────────────┼────────────────┼─────────────┼───────────────────┼────────────────────┤
│ WriteService │ readwritesplit │ 0 │ 0 │ deb12-n1, deb12-n2 │
└──────────────┴────────────────┴─────────────┴───────────────────┴────────────────────┘

shell> maxctrl list servers
┌──────────┬────────────────┬──────┬─────────────┬─────────────────┬────────┬─────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────┼─────────────────────┤
│ deb12-n1 │ 10.139.158.33 │ 3306 │ 0 │ Master, Running │ 0-1-19 │ Replication-Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────┼─────────────────────┤
│ deb12-n2 │ 10.139.158.178 │ 3306 │ 0 │ Slave, Running │ 0-1-19 │ Replication-Monitor │
└──────────┴────────────────┴──────┴─────────────┴─────────────────┴────────┴─────────────────────┘

SQL> SELECT @@hostname, test.* FROM test.test;
+------------+----+-----------+---------------------+
| @@hostname | id | data | ts |
+------------+----+-----------+---------------------+
| deb12-n2 | 1 | Some data | 2024-03-26 09:40:21 |
+------------+----+-----------+---------------------+

SQL> SELECT @@hostname, test.* FROM test.test FOR UPDATE;
+------------+----+-----------+---------------------+
| @@hostname | id | data | ts |
+------------+----+-----------+---------------------+
| deb12-n1 | 1 | Some data | 2024-03-26 09:40:21 |
+------------+----+-----------+---------------------+

Und noch ein weiterer Test ob MaxScale den Failover auch wirklich richtig ausführt:

shell> systemctl stop mariadb
2024-03-26 16:27:05 error : Monitor was unable to connect to server deb12-n2[10.139.158.178:3306] : 'Can't connect to server on '10.139.158.178' (115)'
2024-03-26 16:27:05 notice : Server changed state: deb12-n2[10.139.158.178:3306]: master_down. [Master, Running]→[Down]
2024-03-26 16:27:05 warning: [mariadbmon] Primary has failed. If primary does not return in 4 monitor tick(s), failover begins.
2024-03-26 16:27:07 notice : [mariadbmon] Selecting a server to promote and replace 'deb12-n2'. Candidates are: 'deb12-n1'.
2024-03-26 16:27:07 notice : [mariadbmon] Selected 'deb12-n1'.
2024-03-26 16:27:07 notice : [mariadbmon] Performing automatic failover to replace failed primary 'deb12-n2'.
2024-03-26 16:27:07 notice : [mariadbmon] Failover 'deb12-n2'→'deb12-n1' performed.
2024-03-26 16:27:07 notice : Server changed state: deb12-n1[10.139.158.33:3306]: new_master. [Slave, Running]→[Master, Running]

shell> systemctl start mariadb
2024-03-26 16:28:03 notice : Server changed state: deb12-n2[10.139.158.178:3306]: server_up. [Down]→[Running]
2024-03-26 16:28:03 notice : [mariadbmon] Directing standalone server 'deb12-n2' to replicate from 'deb12-n1'.
2024-03-26 16:28:03 notice : [mariadbmon] Replica connection from deb12-n2 to [10.139.158.33]:3306 created and started.
2024-03-26 16:28:03 notice : [mariadbmon] 1 server(s) redirected or rejoined the cluster.
2024-03-26 16:28:03 notice : Server changed state: deb12-n2[10.139.158.178:3306]: new_slave. [Running]→[Slave, Running]

Welcher MaxScale Knoten gerade für das Monitoring und Failover zuständig ist (cooperatve_monitoring) kann wir folgt eruiert werden:

shell> maxctrl show monitor Replication-Monitor | grep -e 'Diagnostics' -e '"primary"' -e 'lock_held' | uniq
│ Monitor Diagnostics │ { │
│ │ "primary": true, │
│ │ "lock_held": true, │

Es sollte sichergestellt sein, das bis hier hin alles sauber funktioniert. Ansonsten haben die weiteren Schritte keinen wirklichen Sinn.

MaxScale Konfigurations-Synchronisation aktivieren

Für die Konfigurations-Synchronisation braucht es einen eigenen Datenbank-User mit folgenden Rechten:

SQL> CREATE USER 'maxscale_confsync'@'%' IDENTIFIED BY 'secret';
SQL> GRANT SELECT, INSERT, UPDATE, CREATE ON `mysql`.`maxscale_config` TO maxscale_confsync@'%';

Anschliessend muss MaxScale entsprechend konfiguriert werden (auf beiden MaxScale Knoten), damit die Konfigurations-Synchronisation aktiviert wird. Diese Konfiguration erfolgt im globalen MaxScale Abschnitt:

#
# /etc/maxscale.cnf
#

[maxscale]
config_sync_cluster = Replication-Monitor
config_sync_user = maxscale_confsync
config_sync_password = secret

Dann erfolgt der Neustart der MaxScale Knoten:

shell> systemctl restart maxscale

Die MaxScale Konfigurations-Synchronisation kann auch dynamisch aktiviert und deaktiviert werden:

shell> maxctrl show maxscale | grep config_sync
│ │ "config_sync_cluster": null, │
│ │ "config_sync_db": "mysql", │
│ │ "config_sync_interval": "5000ms", │
│ │ "config_sync_password": null, │
│ │ "config_sync_timeout": "10000ms", │
│ │ "config_sync_user": null, │

Hier ist wichtig, die richtige Reihenfolge der 3 Befehle einzuhalten, da es sonst einen Fehler gibt:

shell> MAXCTRL_WARNINGS=0 maxctrl alter maxscale config_sync_user='maxscale_confsync'
shell> MAXCTRL_WARNINGS=0 maxctrl alter maxscale config_sync_password='secret'
shell> MAXCTRL_WARNINGS=0 maxctrl alter maxscale config_sync_cluster='Replication-Monitor'

MaxScale Parameter ändern

Als ersten Test haben wir die MaxScale Monitor Variable monitor_interval ins Auge gefasst, die in diesem Fall auf beiden MaxScale-Knoten sogar unterschiedlich ist:

shell> maxctrl show monitor Replication-Monitor | grep monitor_interval
│ │ "monitor_interval": "750ms",

shell> maxctrl show monitor Replication-Monitor | grep monitor_interval
│ │ "monitor_interval": "1000ms",

Mit dem alter monitor Befehl kann die Variable jetzt auf einem MaxScale Knoten gesetzt werden:

shell> MAXCTRL_WARNINGS=0 maxctrl alter monitor Replication-Monitor monitor_interval=500ms
OK

was einerseits im MaxScale Error Log ersichtlich ist:

2024-03-26 14:09:16 notice : (ConfigManager); Updating to configuration version 1

anderseits sollte der Wert innerhalb von 5 Sekunden (config_sync_interval) auf den zweiten MaxScale Knoten propagiert werden, was mit dem obigen Befehl überprüft werden kann.

Neuer Slave hinzufügen und MaxScale bekannt machen

Ein neuer Slave (deb12-n3) wird zuerst erstellt und dem MariaDB Replikations-Cluster von Hand hinzugefügt. Anschliessen wird der Slave einem MaxScale Knoten bekannt gemacht:

shell> maxctrl create server deb12-n3 10.139.158.39

shell> MAXCTRL_WARNINGS=0 maxctrl link monitor Replication-Monitor deb12-n3
OK

shell> MAXCTRL_WARNINGS=0 maxctrl link service WriteService deb12-n3
OK

shell> maxctrl list servers
┌──────────┬────────────────┬──────┬─────────────┬─────────────────┬────────────┬─────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────────┼─────────────────────┤
│ deb12-n1 │ 10.139.158.33 │ 3306 │ 3 │ Slave, Running │ 0-2-479618 │ Replication-Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────────┼─────────────────────┤
│ deb12-n2 │ 10.139.158.178 │ 3306 │ 3 │ Master, Running │ 0-2-479618 │ Replication-Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────────┼─────────────────────┤
│ deb12-n3 │ 10.139.158.39 │ 3306 │ 1 │ Slave, Running │ 0-2-479618 │ Replication-Monitor │
└──────────┴────────────────┴──────┴─────────────┴─────────────────┴────────────┴─────────────────────┘

Alter Slave entfernen und MaxScale bekannt machen

Bevor ein Slave gelöscht werden kann, sollte er bei einem MaxScale Knoten aus dem Replikations-Cluster entfernt werden:

shell> maxctrl destroy server deb12-n1 --force
OK

shell> maxctrl list servers
┌──────────┬────────────────┬──────┬─────────────┬─────────────────┬────────────┬─────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────────┼─────────────────────┤
│ deb12-n2 │ 10.139.158.178 │ 3306 │ 3 │ Master, Running │ 0-2-493034 │ Replication-Monitor │
├──────────┼────────────────┼──────┼─────────────┼─────────────────┼────────────┼─────────────────────┤
│ deb12-n3 │ 10.139.158.39 │ 3306 │ 1 │ Slave, Running │ 0-2-493032 │ Replication-Monitor │
└──────────┴────────────────┴──────┴─────────────┴─────────────────┴────────────┴─────────────────────┘

Anschliessend kann der Slave abgebaut werden.

Wie wird die Konfiguration synchronisiert?

Die Konfiguration der beiden MaxScale Knoten wird über die Datenbank synchronisiert, was ich persönlich als unglückliche Design-Entscheidung ansehe, da eine Konfigurationsänderung potentiell hackelt, wenn der Master kaputt geht oder Netzwerkprobleme zwischen den Datenbanknoten auftreten…

Die Konfiguration wird in der Tabelle mysql.maxscale_config abgespeichert, welche wie folgt aussieht:

CREATE TABLE `maxscale_config` (
 `cluster` varchar(256) NOT NULL,
 `version` bigint(20) NOT NULL,
 `config` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL CHECK (json_valid(`config`)),
 `origin` varchar(254) NOT NULL,
 `nodes` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL CHECK (json_valid(`nodes`)),
 PRIMARY KEY (`cluster`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

Diese Tabelle hat in etwa folgenden Inhalt:

SQL> SELECT cluster, version, CONCAT(SUBSTR(config, 1, 32), ' ... ', SUBSTR(config, -32)) AS config , origin, nodes FROM mysql.maxscale_config;
+---------------------+---------+-----------------------------------------------------------------------+------------+------------------------------------------+
| cluster | version | config | origin | nodes |
+---------------------+---------+-----------------------------------------------------------------------+------------+------------------------------------------+
| Replication-Monitor | 2 | {"config":[{"id":"deb12-n1","typ ... ter_name":"Replication-Monitor"} | deb12-mxs1 | {"deb12-mxs1": "OK", "deb12-mxs2": "OK"} |
+---------------------+---------+-----------------------------------------------------------------------+------------+------------------------------------------+

Eine lokale Kopie liegt zur Sicherheit auf jedem Knoten vor:

shell> cut -b-32 /var/lib/maxscale/maxscale-config.json
{"config":[{"id":"deb12-n2","typ

Was passiert im Konfliktfall?

Siehe hierzu auch: Error Handling in Configuration Synchronization

Wenn zeitgleich (innerhalb von config_sync_interval?) auf zwei unterschiedlichen MaxScale Knoten die Konfiguration geändert wird erhalten wir folgende Fehlermeldung:

Error: Server at http://127.0.0.1:8989 responded with 400 Bad Request to `PATCH monitors/Replication-Monitor`
{
 "errors": [
 {
 "detail": "Cannot start configuration change: Configuration conflict detected: version stored in the cluster (3) is not the same as the local version (2), MaxScale is out of sync."
 }
 ]
}

Folgender Befehl hilft allenfalls bei grösseren Störungen das Problem zu erkennen:

shell> maxctrl show maxscale | grep -A9 'Config Sync'
│ Config Sync │ { │
│ │ "checksum": "0052fe6f775168bf00778abbe37775f6f642adc7", │
│ │ "nodes": { │
│ │ "deb12-mxs1": "OK", │
│ │ "deb12-mxs2": "OK" │
│ │ }, │
│ │ "origin": "deb12-mxs2", │
│ │ "status": "OK", │
│ │ "version": 3 │
│ │ } │

Tests

Alle Tests wurden auch unter Last ausgeführt. Folgende Tests liefen parallel:

insert_test.php
insert_test.sh
mixed_test.php
while [ true ] ; do mariadb -s --user=app --host=10.139.158.174 --port=3306 --password=secret --execute='SELECT @@hostname, COUNT(*) FROM test.test GROUP BY @@hostname' ; sleep 0.5 ; done
while [ true ] ; do mariadb -s --user=app --host=10.139.158.174 --port=3306 --password=secret --execute='SELECT @@hostname, COUNT(*) FROM test.test GROUP BY @@hostname FOR UPDATE' ; sleep 0.5 ; done

Alle Tests sind bei allen Manipulationen einwandfrei und ohne Probleme durchgelaufen.

MaxScale Konfigurations-Synchronisation wieder deaktivieren

Auf beiden MaxScale Knoten ist folgender Befehl auszuführen und damit ist die Konfigurations-Synchronisation wieder beendet:

shell> MAXCTRL_WARNINGS=0 maxctrl alter maxscale config_sync_cluster=''

Literatur/Quellen

Sharding mit MariaDB MaxScale

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 18 Mar 2024 16:08:04 +0000

Inhaltsverzeichnis

Ü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).

shell> maxscale --version
MaxScale 23.08.5

Als Datenbank Backend (Shards) haben wir MariaDB 10.11 verwendet.

Weniger als ca 2% aller uns bekannten MariaDB Installationen sind das, was wir technische unter Multi-Mandanten-Systeme (multi-tenant systems) verstehen (jeder Mandant (Kunde) in einer eigenen Datenbank (auch Schema genannt)).

Daher wird dieses MariaDB MaxScale Feature relativ selten genutzt und es besteht die erhöhte Gefahr auf Bugs zu stossen, auf welche vorher noch niemand gestossen ist!

Dieses Feature wird bei MariadDB MaxScale: SchemaRouter genannt und wird immer noch als Beta-Qualität deklariert (MXS-5025):

maxctrl> show module schemarouter
┌─────────────┬────────────────────────────────────────────────┐
│ Module │ schemarouter │
├─────────────┼────────────────────────────────────────────────┤
│ Type │ Router │
├─────────────┼────────────────────────────────────────────────┤
│ Version │ V1.0.0 │
├─────────────┼────────────────────────────────────────────────┤
│ Maturity │ Beta │
├─────────────┼────────────────────────────────────────────────┤
│ Description │ A database sharding router for simple sharding │
├─────────────┼────────────────────────────────────────────────┤
│ ...

Die Ziel-Topologie soll wie folgt aussehen: Jeder Kunde (Mandant, Tenant) liegt in einer eigenen Datenbank (= Schema). Die Datenbanken sind über mehrere MariaDB Instanzen (Shards) verteilt. Damit die Applikation transparent auf die Datenbank zugreifen kann wird ein Pärchen MaxScale Load Balancer davor geschaltet, welches weiss, wo der Kunde liegt und den Traffic entsprechend an das Shard weiterleitet. Damit die MaxScale Load Balancer hochverfügbar ausgelegt sind, wird noch eine virtuelle IP (VIP) z.B. mittels Keepalived vorgeschaltet. Wem das noch zu einfach ist, der kann jedes einzelne Shard noch als Master/Slave- oder Galera Cluster-Konstrukt auslegen…

Vorbereitung der Shards (MariaDB Datenbank Instanzen)

Als erstes hatten wir bei diesem PoC Problem mit der test Datenbank. Durch das Löschen der test Datenbank auf allen Shards ist das Problem verschwunden. Alternativ dazu kann man mariadb-secure-installation ausführen, was man auf Produktionsystemen sowieso machen sollte, oder man nutzt die MaxScale Konfigurationsparameter: ignore_tables oder ignore_tables_regex um gleiche Tabellen in unterschiedlichen Shards zu erlauben (MXS-5027).

Siehe auch: MaxScale Router Parameters.

Testdaten erstellen

Damit wir was zum Spielen haben, haben wir uns Testdaten erstellt:

-- Auf Shard 1: 2 Kunden

SQL> CREATE DATABASE customer_0010;
SQL> CREATE TABLE customer_0010.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0010.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0010.address VALUES (1, 'Customer 10 GmbH');
SQL> INSERT INTO customer_0010.sales VALUES (1, 'Apples', 5, 1.2, 6), (2, 'Pears', 2, 0.9, 1.8), (3, 'Bread', 1, 2.5, 2.5);

SQL> CREATE DATABASE customer_0011;
SQL> CREATE TABLE customer_0011.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0011.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0011.address VALUES (1, 'Customer 11 SE');
SQL> INSERT INTO customer_0011.sales VALUES (1, 'Oranges', 2, 1.7, 3.4), (2, 'Salat', 5, 1.2, 6);

-- Auf Shard 2: 3 Kunden

SQL> CREATE DATABASE customer_0020;
SQL> CREATE TABLE customer_0020.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0020.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0020.address VALUES (1, 'Customer 20 AG');
SQL> INSERT INTO customer_0020.sales VALUES (1, 'Oranges', 2, 1.7, 3.4), (2, 'Salat', 5, 1.2, 6);

SQL> CREATE DATABASE customer_0021;
SQL> CREATE TABLE customer_0021.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0021.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0021.address VALUES (1, 'Customer 21 GmbH');
SQL> INSERT INTO customer_0021.sales VALUES (1, 'Oranges', 2, 1.7, 3.4), (2, 'Salat', 5, 1.2, 6);

SQL> CREATE DATABASE customer_0022;
SQL> CREATE TABLE customer_0022.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0022.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0022.address VALUES (1, 'Customer 22 Gebr.');
SQL> INSERT INTO customer_0022.sales VALUES (1, 'Oranges', 2, 1.7, 3.4), (2, 'Salat', 5, 1.2, 6);

-- Auf Shard 3: 1 Kunde

SQL> CREATE DATABASE customer_0030;
SQL> CREATE TABLE customer_0030.address (id INT UNSIGNED, name VARCHAR(255));
SQL> CREATE TABLE customer_0030.sales (id INT UNSIGNED, product VARCHAR(255), sales TINYINT, amount DECIMAL(6, 2), total_amount DECIMAL(6, 2));
SQL> INSERT INTO customer_0030.address VALUES (1, 'Customer 30 GmbH');
SQL> INSERT INTO customer_0030.sales VALUES (1, 'Pickles', 2, 2.2, 4.4), (2, 'Salat', 1, 3.1, 3.1), (3, 'Pudding', 5, 2.2, 11.0), (4, 'Asparagus', 12, .3, 3.6);

Rollen und User erstellen

Da in einem geshardeten System, im Unterschied zum Beispiel zu einem Galera Cluster, die einzelnen Datenbank-Instanzen nichts voneinander wissen und nicht miteinander kommunizieren, müssen wir die Rollen und User bzw. Accounts jeweils auf JEDEM Shard einzeln anlegen.

MariaDB MaxScale braucht jeweils für den SchemaRouter Service und den Monitor einen User (auf jedem Shard).

Der Monitor User ist, wie der Name sagt fürs Monitoring zuständig und der SchemaRouter Service User um die User Account Informationen aus den Sharding-Backends einzusammeln und die Queries an das richtige Shard weiterzuleiten.

Da in einem redundanten System typischerweise mit mindestens zwei MaxScale Routern gearbeitet wird und wir dem auseinanderlaufen der Privilegien der Accounts vorbeugen wollten arbeiten wir mit Rollen sowohl für die MaxScale User als auch die applikatorischen User.

MaxScale Monitor User

SQL> CREATE ROLE maxscale_monitor_role;

SQL> GRANT SELECT ON mysql.user TO 'maxscale_monitor_role';
SQL> GRANT REPLICATION CLIENT ON *.* TO 'maxscale_monitor_role';
SQL> GRANT SLAVE MONITOR ON *.* TO 'maxscale_monitor_role';
SQL> GRANT FILE ON *.* TO 'maxscale_monitor_role';
SQL> GRANT CONNECTION ADMIN ON *.* TO 'maxscale_monitor_role';

SQL> SHOW GRANTS FOR maxscale_monitor_role;
+-----------------------------------------------------------------------------------------------+
| Grants for maxscale_monitor_role |
+-----------------------------------------------------------------------------------------------+
| GRANT FILE, BINLOG MONITOR, CONNECTION ADMIN, SLAVE MONITOR ON *.* TO `maxscale_monitor_role` |
| GRANT SELECT ON `mysql`.`user` TO `maxscale_monitor_role` |
+-----------------------------------------------------------------------------------------------+

SQL> CREATE USER maxscale_monitor@'10.139.158.210' IDENTIFIED BY 'secret';
SQL> CREATE USER maxscale_monitor@'10.139.158.211' IDENTIFIED BY 'secret';

SQL> GRANT maxscale_monitor_role TO maxscale_monitor@'10.139.158.210';
SQL> GRANT maxscale_monitor_role TO maxscale_monitor@'10.139.158.211';

SQL> SET DEFAULT ROLE maxscale_monitor_role FOR maxscale_monitor@'10.139.158.210';
SQL> SET DEFAULT ROLE maxscale_monitor_role FOR maxscale_monitor@'10.139.158.211';

SQL> SELECT user, host, is_role, default_role FROM mysql.user WHERE user LIKE 'maxscale_monitor%';
+-----------------------+----------------+---------+-----------------------+
| User | Host | is_role | default_role |
+-----------------------+----------------+---------+-----------------------+
| maxscale_monitor_role | | Y | |
| maxscale_monitor | 10.139.158.210 | N | maxscale_monitor_role |
| maxscale_monitor | 10.139.158.211 | N | maxscale_monitor_role |
+-----------------------+----------------+---------+-----------------------+

SQL> SHOW GRANTS FOR maxscale_monitor@'10.139.158.211';
+------------------------------------------------------------------------------------------------------------------------------+
| Grants for maxscale_monitor@10.139.158.211 |
+------------------------------------------------------------------------------------------------------------------------------+
| GRANT `maxscale_monitor_role` TO `maxscale_monitor`@`10.139.158.211` |
| GRANT USAGE ON *.* TO `maxscale_monitor`@`10.139.158.211` IDENTIFIED BY PASSWORD '*14E65567ABDB5135D0CFD9A70B3032C179A49EE7' |
| SET DEFAULT ROLE `maxscale_monitor_role` FOR `maxscale_monitor`@`10.139.158.211` |
+------------------------------------------------------------------------------------------------------------------------------+

MaxScale Admin User

SQL> CREATE ROLE maxscale_admin_role;

SQL> GRANT SHOW DATABASES ON *.* TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.user TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.db TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.tables_priv TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.columns_priv TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.proxies_priv TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_admin_role';
SQL> GRANT SELECT ON mysql.procs_priv TO 'maxscale_admin_role';

SQL> SHOW GRANTS FOR maxscale_admin_role;
+------------------------------------------------------------------+
| Grants for maxscale_admin_role |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`user` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`roles_mapping` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`tables_priv` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`procs_priv` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`db` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`columns_priv` TO `maxscale_admin_role` |
| GRANT SELECT ON `mysql`.`proxies_priv` TO `maxscale_admin_role` |
+------------------------------------------------------------------+

SQL> CREATE USER maxscale_admin@'10.139.158.210' IDENTIFIED BY 'secret';
SQL> CREATE USER maxscale_admin@'10.139.158.211' IDENTIFIED BY 'secret';

SQL> GRANT maxscale_admin_role TO maxscale_admin@'10.139.158.210';
SQL> GRANT maxscale_admin_role TO maxscale_admin@'10.139.158.211';

SQL> SET DEFAULT ROLE maxscale_admin_role FOR maxscale_admin@'10.139.158.210';
SQL> SET DEFAULT ROLE maxscale_admin_role FOR maxscale_admin@'10.139.158.211';

SQL> SELECT user, host, is_role, default_role FROM mysql.user WHERE user LIKE 'maxscale_admin%';
+---------------------+----------------+---------+---------------------+
| User | Host | is_role | default_role |
+---------------------+----------------+---------+---------------------+
| maxscale_admin_role | | Y | |
| maxscale_admin | 10.139.158.210 | N | maxscale_admin_role |
| maxscale_admin | 10.139.158.211 | N | maxscale_admin_role |
+---------------------+----------------+---------+---------------------+

SQL> SHOW GRANTS FOR maxscale_admin@'10.139.158.211';
+----------------------------------------------------------------------------------------------------------------------------+
| Grants for maxscale_admin@10.139.158.211 |
+----------------------------------------------------------------------------------------------------------------------------+
| GRANT `maxscale_admin_role` TO `maxscale_admin`@`10.139.158.211` |
| GRANT USAGE ON *.* TO `maxscale_admin`@`10.139.158.211` IDENTIFIED BY PASSWORD '*14E65567ABDB5135D0CFD9A70B3032C179A49EE7' |
| SET DEFAULT ROLE `maxscale_admin_role` FOR `maxscale_admin`@`10.139.158.211` |
+----------------------------------------------------------------------------------------------------------------------------+

Siehe dazu auch: SchemaRouter Configuration

Applikationsrolle und Accounts erstellen

Für die Applikation braucht es ebenfalls einen User, den wir hier wie auf jedem Shard wie folgt erstellen:

SQL> CREATE ROLE app_role;
SQL> GRANT SELECT, INSERT, UPDATE, DELETE ON `customer_%`.* TO 'app_role';
SQL> GRANT SHOW DATABASES ON *.* TO 'app_role';
SQL> GRANT CREATE, DROP, ALTER ON *.* TO 'app_role'; -- For creating new tenant databases

SQL> SHOW GRANTS FOR app_role;
+----------------------------------------------------------------------+
| Grants for app_role |
+----------------------------------------------------------------------+
| GRANT SHOW DATABASES ON *.* TO `app_role` |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `customer_%`.* TO `app_role` |
+----------------------------------------------------------------------+

SQL> CREATE USER app@'10.139.158.%' IDENTIFIED BY 'secret';
SQL> GRANT app_role TO app@'10.139.158.%';
SQL> SET DEFAULT ROLE app_role FOR app@'10.139.158.%';

SQL> SELECT user, host, is_role, default_role FROM mysql.user WHERE user LIKE 'app%';
+----------+--------------+---------+--------------+
| User | Host | is_role | default_role |
+----------+--------------+---------+--------------+
| app_role | | Y | |
| app | 10.139.158.% | N | app_role |
+----------+--------------+---------+--------------+

SQL> SHOW GRANTS FOR app@'10.139.158.%';
+---------------------------------------------------------------------------------------------------------------+
| Grants for app@10.139.158.% |
+---------------------------------------------------------------------------------------------------------------+
| GRANT `app_role` TO `app`@`10.139.158.%` |
| GRANT USAGE ON *.* TO `app`@`10.139.158.%` IDENTIFIED BY PASSWORD '*14E65567ABDB5135D0CFD9A70B3032C179A49EE7' |
| SET DEFAULT ROLE `app_role` FOR `app`@`10.139.158.%` |
+---------------------------------------------------------------------------------------------------------------+

Proxy Protokoll

Load Balancer und Proxies haben die Eigenschaft, dass sie die IP Adressen der Clients durch ihre eigenen IP Adressen austauschen. Dies führt einerseits dazu, dass man auf der Datenbank nicht mehr sieht, woher der Client ursprünglich kommt, andererseits kann man die Zugriffsberechtigungen nicht mehr auf User und IP vergeben, da immer gegen die IP der Load Balancer geprüft wird.

Diese beiden Probleme können mittels des Proxy Protokolls gelöst werden.

Hierzu müssen einerseits die Datenbank und andererseits die Load Balancer, in diesem Fall der MaxScale, das Proxy Protokoll aktiviert haben.

Auf der Datenbank-Seite aktiviert man das Proxy Protokoll wie folgt:

#
# my.cnf
#

[mariadbd]

proxy_protocol_networks = ::1, 10.139.158.0/24, localhost

und auf MaxScale-Seite mit:

#
# /etc/maxscale.cnf
#

[shard<n>]
type = server
proxy_protocol = true

Überprüfen kann man die beiden Einstellungen mit:

SQL> SHOW GLOBAL VARIABLES LIKE 'proxy%';
+-------------------------+---------------------------------+
| Variable_name | Value |
+-------------------------+---------------------------------+
| proxy_protocol_networks | ::1, 10.139.158.0/24, localhost |
+-------------------------+---------------------------------+

shell> maxctrl show server shard1 | grep proxy
│ │ "proxy_protocol": true, │

Quellen:

MaxScale SchemaRouter Konfiguration

Als nächstes bereiten wir die MaxScale Konfiguration fürs Sharding vor. Die von MariaDB empfohlene Datei ist /etc/maxscale.cnf. Ob es sinnvoller ist eine eigene Konfigurations-Datei unter /etc/maxscale.cnf.d/ zu erstellen oder gar den ganze MaxScale dynamisch zu konfigurieren (/var/lib/maxscale/maxscale.cnf.d/*.cnf), wird sich langfristig zeigen. Siehe auch Warnungen weiter unten. Die Konfigurationsdatei für dieses Sharding PoC sieht wie folgt aus:

#
# /etc/maxscale.cnf
#

[maxscale]
threads = auto
admin_gui = false

[shard1]
type = server
address = 10.139.158.1
port = 3363
proxy_protocol = true

[shard2]
type=server
address=10.139.158.1
port=3364
proxy_protocol = true

[shard3]
type = server
address = 10.139.158.1
port = 3365
proxy_protocol = true

[Sharding-Monitor]
type = monitor
module = galeramon
servers = shard1,shard2,shard3
user = maxscale_monitor
password = secret
monitor_interval = 1s

[Sharded-Service-Listener]
type = listener
service = Sharded-Service
protocol = MariaDBClient
port = 3306

[Sharded-Service]
type = service
router = schemarouter
servers = shard1,shard2,shard3
user = maxscale_admin
password = secret
auth_all_servers = true

Hinweis: Empfehlung des MaxScale Entwicklers: “One workaround might be to actually use galeramon to monitor the nodes instead of mariadbmon.”

Starten und Stoppen des MaxScale Load Balancers

Starten und Stoppen von MaxScale erfolgt wie üblich über SystemD:

shell> systemctl restart maxscale

shell> systemctl status maxscale
● maxscale.service - MariaDB MaxScale Database Proxy
 Loaded: loaded (/lib/systemd/system/maxscale.service; enabled; vendor preset: enabled)
 Drop-In: /run/systemd/system/service.d
 └─zzz-lxc-service.conf
 Active: active (running) since Tue 2024-02-27 09:52:57 UTC; 39s ago
 Process: 187 ExecStart=/usr/bin/maxscale (code=exited, status=0/SUCCESS)
 Main PID: 188 (maxscale)
 Tasks: 10 (limit: 18663)
 Memory: 4.6M
 CPU: 150ms
 CGroup: /system.slice/maxscale.service
 └─188 /usr/bin/maxscale

systemd[1]: Starting MariaDB MaxScale Database Proxy...
maxscale[188]: Module 'galeramon' loaded from '/usr/lib/x86_64-linux-gnu/maxscale/libgaleramon.so'.
maxscale[188]: Module 'schemarouter' loaded from '/usr/lib/x86_64-linux-gnu/maxscale/libschemarouter.so'.
maxscale[188]: Using up to 2.3GiB of memory for query classifier cache
systemd[1]: Started MariaDB MaxScale Database Proxy.

Falls es Fehler oder Warnungen gegeben hat, kann man diese im MaxScale Error Log sehen:

shell> grep -v notice /var/log/maxscale/maxscale.log
2024-02-13 16:47:22 MariaDB MaxScale is shut down.
----------------------------------------------------


MariaDB MaxScale /var/log/maxscale/maxscale.log Tue Feb 13 16:47:22 2024
----------------------------------------------------------------------------
2024-02-27 09:52:56 warning: Discarding journal file '/var/lib/maxscale/Sharding-Monitor_journal.json'. File is for module 'mariadbmon'. Current module is 'galeramon'.
2024-02-27 09:52:56 warning: [galeramon] Invalid 'wsrep_local_index' on server 'shard1': 18446744073709551615

Applikations-Tests

Einfache Applikations-Tests

shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 --execute='show databases'
+--------------------+
| Database |
+--------------------+
| customer_0010 |
| customer_0011 |
| customer_0020 |
| customer_0021 |
| customer_0022 |
| customer_0030 |
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+

Neuer Befehl `show shards`

shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 customer_0030 --execute='show shards' | grep customer_00.* | sort | column -t
customer_0010.address shard1
customer_0010.sales shard1
customer_0010. shard1
customer_0011.address shard1
customer_0011.sales shard1
customer_0011. shard1
customer_0020.address shard2
customer_0020.sales shard2
customer_0020. shard2
customer_0021.address shard2
customer_0021.sales shard2
customer_0021. shard2
customer_0022.address shard2
customer_0022.sales shard2
customer_0022. shard2
customer_0030.address shard3
customer_0030.sales shard3
customer_0030. shard3

Neue Datenbanken werden nicht sofort angezeigt, sondern erst wenn die gecachten Daten upgedatet wurden (refresh_interval (300s / 5 min)).

Siehe hierzu auch: Custom SQL commands

Allgemeinere Test

Zur Erinnerung:

Shard	Port	Customer	State
#1	3363	customer_001<n>	Running
#2	3364	customer_002<n>	Running
#3	3365	customer_003<n>	Running
#4	3366	customer_004<n>	Running

shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3363 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 --database=customer_0010 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3363 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 --database=customer_0020 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3364 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 --execute='use customer_0020; SELECT @@port'
+--------+
| @@port |
+--------+
| 3364 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 customer_0010 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3363 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 customer_0020 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3364 |
+--------+
shell> mariadb --user=app --password=secret --host=10.139.158.211 --port=3306 customer_0030 --execute='SELECT @@port'
+--------+
| @@port |
+--------+
| 3365 |
+--------+

Weniger einfache (Backup-) Test

shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction customer_0010 > /tmp/customer_0010.sql
shell> echo $?
0
shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction customer_0020 > /tmp/customer_0020.sql
shell> echo $?
0
shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction customer_0030 > /tmp/customer_0030.sql
shell> echo $?
0
shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction --databases customer_0011 > /tmp/customer_0011.sql
shell> echo $?
0
shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction --databases customer_0021 > /tmp/customer_0021.sql
shell> echo $?
0
shell> mariadb-dump --user=app --password=secret --host=10.139.158.211 --port=3306 --single-transaction --databases customer_0030 > /tmp/customer_0030.sql
shell> echo $?
0

shell> ll /tmp/customer_00*sql
-rw-rw-r-- 1 oli oli 2738 Mar 18 12:07 /tmp/customer_0010.sql
-rw-rw-r-- 1 oli oli 2904 Mar 18 12:08 /tmp/customer_0011.sql
-rw-rw-r-- 1 oli oli 2712 Mar 18 12:08 /tmp/customer_0020.sql
-rw-rw-r-- 1 oli oli 2906 Mar 18 12:08 /tmp/customer_0021.sql
-rw-rw-r-- 1 oli oli 2964 Mar 18 12:08 /tmp/customer_0030.sql

shell> tail -n 1 /tmp/customer_*.sql
==> /tmp/customer_0010.sql <==
-- Dump completed on 2024-02-13 14:39:21

==> /tmp/customer_0011.sql <==
-- Dump completed on 2024-02-13 14:39:35

==> /tmp/customer_0020.sql <==
-- Dump completed on 2024-02-13 14:40:15

==> /tmp/customer_0021.sql <==
-- Dump completed on 2024-02-13 14:40:42

==> /tmp/customer_0030.sql <==
-- Dump completed on 2024-02-13 14:40:52

shell> cat /tmp/customer_00*sql | grep -A1 -i insert
INSERT INTO `address` VALUES
(1,'Customer 10 GmbH');
--
INSERT INTO `sales` VALUES
(1,'Apples',5,1.20,6.00),
--
INSERT INTO `address` VALUES
(1,'Customer 11 SE');
--
INSERT INTO `sales` VALUES
(1,'Oranges',2,1.70,3.40),
--
INSERT INTO `address` VALUES
(1,'Customer 20 AG');
--
INSERT INTO `sales` VALUES
(1,'Oranges',2,1.70,3.40),
--
INSERT INTO `address` VALUES
(1,'Customer 21 GmbH');
--
INSERT INTO `sales` VALUES
(1,'Oranges',2,1.70,3.40),
--
INSERT INTO `address` VALUES
(1,'Customer 30 GmbH');
--
INSERT INTO `sales` VALUES
(1,'Pickles',2,2.20,4.40),

In MaxScale 23.08.4 war ein ziemlich übler Bug drin: Ein Rückgabewert von 0 aber keine Daten im Backup!!! Siehe dazu auch die Tickets: MXS-4966: mariadb-dump gets an error dumping schemas und MXS-4947: Tables in information_schema are treated as a normal tables. Symptome des Bugs sehen wie folgt aus:

Error: Couldn't read status information for table address ()
Error: Couldn't read status information for table sales ()

Daher empfiehlt sich dringend ein Upgrade auf MaxScale 23.08.5.

Komplexere Applikations-Tests

Wir haben noch einen etwas komplexeren Test erstellt (./sharding_test.php), der folgen Queries abarbeitet:

SET NAMES utf8mb4
SHOW DATABASES
use customer_<nnnn>
START TRANSACTION;
SELECT MIN(id) AS first, MAX(id) AS last FROM `sales`
INSERT INTO sales (id, product, sales, amount, total_amount) VALUES (%d, '%s', %f, %f, %f)
INSERT INTO sales (id, product, sales, amount, total_amount) VALUES (%d, '%s', %f, %f, %f)
UPDATE sales SET product = 'Prepare to delete' WHERE id = %d
DELETE FROM sales WHERE id = %d
COMMIT

Dieser Test lief einwandfrei durch. Die dazu gehörende Kontroll-Abfrage:

SQL> SELECT * FROM customer_0021.sales WHERE id >= (SELECT MAX(id) - 10 FROM customer_0021.sales);

Verschiedene Last-Szenarien können zusätzlich mit db_bench oder dem Acronis perfkit getestet werden. Weitere Informationen dazu siehe hier.

Cross-Shard-Tests

Allensfalls könnte man auf die Idee kommen, Cross-Shard-Queries auszuführen. Dies wird NICHT funktionieren, was ja nicht wirklich erstaunen sollte, da erstens nicht ganz einfach zu implementieren und zweites hier beschrieben:

“Note: As the sharding solution in MaxScale is relatively simple, cross-database queries between two or more shards are not supported.”

Quelle: Simple Sharding with Two Servers

und

“USE db1 is routed to the server with db1. If the database is divided to multiple servers, only one server will get the command.”

Quelle: SchemaRouter

Hier ein Test mit UNION:

SQL> use customer_0030
Database changed
SQL> SELECT * FROM customer_0020.sales UNION SELECT * FROM customer_0030.sales;
ERROR 1146 (42S02): Table 'customer_0020.sales' doesn't exist

Und hier noch der Gegenbeweis:

SQL> use customer_0020
Database changed
SQL> SELECT * FROM customer_0020.sales UNION SELECT * FROM customer_0030.sales;
ERROR 1146 (42S02): Table 'customer_0030.sales' doesn't exist

Und hier noch den Test mit JOIN:

SQL> use customer_0020
SQL> SELECT *
 FROM customer_0020.sales a
 JOIN customer_0030.sales b ON a.id = b.id
WHERE a.sales > 1
;
ERROR 1146 (42S02): Table 'customer_0030.sales' doesn't exist

SQL> use customer_0030
SQL> SELECT *
 FROM customer_0020.sales a
 JOIN customer_0030.sales b ON a.id = b.id
WHERE a.sales > 1
;
ERROR 1146 (42S02): Table 'customer_0020.sales' doesn't exist

Betrieb eines MaxScale Sharding-Systems

In diesem Kapitel besprechen wir einige Punkte die für den Betrieb eines MariaDB MaxScale Sharding-Systems nützlich sein können.

Do-on-all-shards

Da es immer wieder vorkommen kann, dass O/S oder Datenbank Operationen auf allen Shards ausgeführt werden müssen, wäre es sicher sinnvoll ein Skript zu erstellen, welches reihum, auf allen Shards, den selben Befehl ausführt:

shell> ./do-on-all-shards.sh --sql='SHOW DATABASES'

Ein so geartetes Skript dürfte die Fehlerrate im Betrieb stark reduzieren. Auch Operationen wie das Re-sharding eines Mandanten, wie weiter unten beschrieben, werden sinnvollerweise geskriptet und zentral ausgeführt (MXS-5029).

Invalidieren des Database Map Caches

Mit dem Befehlt invalidate kann man den Database Map Cache des MariaDB MaxScale SchemaRouters invalidieren. Dies gibt uns die Möglichkeit, nach dem Hinzufügen oder dem Entfernen von Mandanten den Cache schnell wieder auf einen aktuellen Stand zu bringen.

shell> maxctrl call command schemarouter invalidate Sharded-Service
OK

Im unterschied zum Befehl invalidate, bei welchem die Einträge nach dem nächsten refresh_intervall auf den neusten Stand gebracht werden, löscht der Befehl clear die Einträge und ein Remap wird sofort ausgeführt.

Wenn man den Database Map Cache von remote mit einem REST API Call invalidieren möchte, geht das wie folgt:

shell> curl -i -X POST -u api_admin:secret http://10.139.158.211:8989/v1/maxscale/modules/schemarouter/clear?Sharded-Service
HTTP/1.1 204 No Content
Connection: close
Date: Mon, 18 Mar 24 11:49:58 GMT
X-Frame-Options: Deny
X-XSS-Protection: 1
Referrer-Policy: same-origin
Cache-Control: no-cache

Quellen:

Wie ändert man SchemaRouter Variablen dynamisch?

Das refresh_interval spezifiziert die Lebensdauer der Einträge im SchemaRouter Database Map Cache. Der default Wert ist 300 s (5 min). Refresh Interval ist daher, meiner Meinung nach, ein unglücklicher Begriff da es nicht das Intervall zwischen zwei Mappings definiert sondern die Lebzeit der Cache-Einträge (livetime?, timeout?). Sobald der Eintrag gelöscht wurde wir ein neuer Refresh der “Database Map” auf jedem Shard getriggert. Der Befehl sieht aktuell wie folgt aus:

SELECT LOWER(t.table_schema), LOWER(t.table_name) FROM information_schema.tables t
 UNION ALL
SELECT LOWER(s.schema_name), '' FROM information_schema.schemata s

So wie es aussieht reicht ein simpler Connect um den Refresh der Database Map zu triggern.

Der aktuelle Wert für refresh_intervall kann wie folgt abgefragt werden.

shell> maxctrl show service Sharded-Service | grep refresh_interval | awk -F'│' '{ print $3 }'
 "refresh_interval": "300000ms",

Um den Wert dynamisch zu ändern hilft folgender Befehl:

shell> MAXCTRL_WARNINGS=0 maxctrl alter service Sharded-Service refresh_interval=10s
OK

Der Wert sollte nicht zu klein eingestellt werden, da während des Mapping Vorgangs alle anderen Connections angehalten werden.

Quellen:

Hinzufügen und Entfernen eines Mandanten

Das Hinzufügen eines neuen Mandanten zu einem Shard stellt kein grosses Problem dar:

SQL> CREATE DATABASE customer_0029;
SQL> use customer_0029
SQL> CREATE TABLE address LIKE customer_template.address;
SQL> CREATE TABLE sales LIKE customer_template.sales;

shell> maxctrl call command schemarouter invalidate Sharded-Service
OK

Das Entfernen eines Mandanten von einem Shard ist hingegen etwas komplizierter und muss in Absprache mit der Applikation erfolgen:

SQL> DROP DATABASE customer_0011;

shell> ./sharding_test.php
.....ERROR: Table 'customer_0011.sales' doesn't exist...ERROR: Unknown database 'customer_0011'.ERROR: Unknown database 'customer_0011'......ERROR: Unknown database 'customer_0011'...

shell> maxctrl call command schemarouter clear Sharded-Service
OK

Zumindest ist mir bisher noch keine schlauere Variante eingefallen. Siehe auch Umziehen eines Mandanten weiter unten.

Umziehen eines Mandanten

Die Kombination von Hinzufügen und Entfernen wäre dann das Umziehen eines Mandanten von einem Shard auf ein anderes Shard, auch re-sharding genannt. Hierzu muss ebenfalls wieder mit der Applikation zusammen eine konzertierte Aktion geplant werden.

Falls dies nicht möglich ist, kann zumindest die Zeit, welche die Applikation Fehler erhält reduziert werden… Folgendes Vorgehen kann verwendet werden um einen Mandanten von Shard 2 auf Shard 3 umzuziehen:

SQL> use customer_0020; LOCK TABLES address READ, sales READ; -- Auf Shard 2, Applikation wir allenfalls blockiert!

shell> mariadb-dump --user=app --password=secret --host=10.139.158.1 --port=3364 --single-transaction --skip-add-locks --databases customer_0020 | mariadb --user=app --password=secret --host=10.139.158.1 --port=3365 # Kopieren des Mandanten 20 von Shard 2 auf Shard 3

SQL> DROP DATABASE customer_0020; -- Löschen von Mandant 20 geht nicht!
ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction

SQL> UNLOCK TABLES; DROP DATABASE customer_0020; # So geht das Löschen von Mandant 20.

shell> maxctrl call command schemarouter clear Sharded-Service # MaxScale Database Map aktualisieren. Schnell machen!!!

Bis zum Refresh der Database Map kann es zu folgenden Fehlern kommen:

error : (47621) [schemarouter] (Sharded-Service); 'customer_0020.' found on servers 'shard2','shard3' for user 'app'@'10.139.158.1'.
error : (47621) [schemarouter] (Sharded-Service); 'customer_0020.address' found on servers 'shard2','shard3' for user 'app'@'10.139.158.1'.
error : (47621) [schemarouter] (Sharded-Service); 'customer_0020.sales' found on servers 'shard2','shard3' for user 'app'@'10.139.158.1'.
error : (47621) [schemarouter] (Sharded-Service); Duplicate tables found, closing session.

Und applikationsseitig zu:

ERROR: Error: duplicate tables found on two different shards

Hinzufügen oder entfernen eines Shards

Das Umziehen eines Mandanten von einem Shard auf ein anderes Shard ist das kleine re-sharding. Etwas komplexer wird es, wenn man neue Shards hinzufügen oder alte Shards entfernen möchte. Im Anschluss daran (nach dem Hinzufügen bzw. vor dem Entfernen) würde dann ein grosses re-sharding erfolgen. Zuerst das Erweitern des Clusters um ein Shard:

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬───────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard1 │ 10.139.158.1 │ 3363 │ 0 │ Running │ 0-3363-26014 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 0 │ Running │ 0-3364-240612 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 0 │ Running │ 0-3365-289873 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴───────────────┴──────────────────┘

Das vorbereitete Shard wird MaxScale bekannt gemacht:

shell> maxctrl create server shard4 10.139.158.1 3366
OK

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard1 │ 10.139.158.1 │ 3363 │ 1 │ Running │ 0-3363-23676 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-52321 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-39751 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 0 │ Down │ │ │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

Dann wird des neue Shard mit dem MaxScale Monitor und dem Service verknüpft:

shell> MAXCTRL_WARNINGS=0 maxctrl link monitor Sharding-Monitor shard4
OK

shell> MAXCTRL_WARNINGS=0 maxctrl link service Sharded-Service shard4
OK

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard1 │ 10.139.158.1 │ 3363 │ 1 │ Running │ 0-3363-24961 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-56215 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-45177 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 1 │ Running │ 0-3366-32 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

Ob dieser zweite Schritt ebenfalls zwingend notwendig ist, wurde nicht untersucht.

Im MariaDB MaxScale Error Log kann man den ganzen Ablauf mitverfolgen:

warning: Discarding journal file '/var/lib/maxscale/Sharding-Monitor_journal.json'. Servers described in the journal are different from the ones configured on the current monitor.
warning: Saving runtime modifications to 'Sharding-Monitor' in '/var/lib/maxscale/maxscale.cnf.d/Sharding-Monitor.cnf'. The modified values will override the values found in the static configuration files.
notice : shard4 sent version string '10.11.7-MariaDB-log'. Detected type: MariaDB, version: 10.11.7.
notice : Server 'shard4' charset: latin1_swedish_ci
notice : Server changed state: shard4[10.139.158.1:3366]: server_up. [Down]→[Running]
warning: Saving runtime modifications to 'Sharded-Service' in '/var/lib/maxscale/maxscale.cnf.d/Sharded-Service.cnf'. The modified values will override the values found in the static configuration files.
notice : Added 'shard4' to 'Sharded-Service'

Was wir hier nicht vergessen dürfen, ist das neue Shard ebenfalls mit dem Proxy Protokoll auszustatten:

shell> maxctrl show server shard4 | grep proxy
│ │ "proxy_protocol": false, │

MAXCTRL_WARNINGS=0 maxctrl alter server shard4 proxy_protocol=true
OK

Und jetzt können neue Mandanten auf dem neuen Shard hinzugefügt oder alte Mandanten auf das neue Shard umgezogen werden… In unserem Set-up wollen wir alle Mandanten vom Shard 1 auf Shard 4 umziehen und zudem einen neuen Mandanten customer_0040 auf Shard 4 erstellen. Die dazu benötigten Einzelschritte sind oben aufgeführt.

Nachdem das Shard 1 leergeräumt wurde, kann es abgebaut werden:

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard1 │ 10.139.158.1 │ 3363 │ 1 │ Running │ 0-3363-25916 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-62887 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-54035 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 1 │ Running │ 0-3366-2247 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

Mit dem Befehl destroy server wir ein Shard gelöscht. Bevor das aber funktioniert muss ein Shard aus dem Monitor und dem Service entfernt werden:

shell> MAXCTRL_WARNINGS=0 maxctrl unlink service Sharded-Service shard1
OK

shell> MAXCTRL_WARNINGS=0 maxctrl unlink monitor Sharding-Monitor shard1
OK

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard1 │ 10.139.158.1 │ 3363 │ 0 │ Running │ │ │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-64394 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-56072 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 1 │ Running │ 0-3366-3267 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

Wenn das Shard aus dem Monitor und dem Service herausgelöst ist, kann es anschliessend gelöscht werden:

shell> maxctrl destroy server shard1
Warning: Object 'shard1' is defined in a static configuration file and cannot be permanently deleted. If MaxScale is restarted, the object will appear again.
To hide these warnings, run:

 export MAXCTRL_WARNINGS=0

OK
shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-65018 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-56886 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 1 │ Running │ 0-3366-3648 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

Und im MaxScale Error Log kann man die Änderungen schön mitverfolgen:

notice : Removed 'shard1' from 'Sharded-Service'
warning: Discarding journal file '/var/lib/maxscale/Sharding-Monitor_journal.json'. Servers described in the journal are different from the ones configured on the current monitor.
notice : Destroyed server 'shard1' at 10.139.158.1:3363

Wichtig: Mir wurde mitgeteilt, dass mit destroy server --force die unlink service und unlink monitor Befehle durch MaxScale automatisch ausgeführt werden.

Quelle:

MariaDB MaxScale Administration Tutorial - Managing servers

Anpassen der Konfigurationsdateien

Bei den oben beschriebenen Shard Operationen habe wir einige Warnungen erhalten:

Warning: Object 'shard1' is defined in a static configuration file and cannot be permanently deleted. If MaxScale is restarted, the object will appear again.

und

Warning: Saving runtime modifications to 'Sharding-Monitor' in '/var/lib/maxscale/maxscale.cnf.d/Sharding-Monitor.cnf'. The modified values will override the values found in the static configuration files.

Die entsprechenden Konfigurationsdateien werden von MaxScale automatisch bei dynamischen System-Änderungen erstellt:

shell> ll /var/lib/maxscale/maxscale.cnf.d/ /etc/maxscale.cnf
-rw-r--r-- 1 root root 612 Feb 13 14:23 /etc/maxscale.cnf

/var/lib/maxscale/maxscale.cnf.d/:
total 12
-rw------- 1 maxscale maxscale 187 Feb 13 16:08 Sharding-Monitor.cnf
-rw------- 1 maxscale maxscale 150 Feb 13 16:07 Sharded-Service.cnf
-rw------- 1 maxscale maxscale 52 Feb 13 15:46 shard4.cnf

cat /var/lib/maxscale/maxscale.cnf.d/*
[Sharded-Service]
debug=true
refresh_interval=10000ms
auth_all_servers=true
log_debug=true
password=secret
router=schemarouter
type=service
user=maxscale_admin
targets=shard2,shard3,shard4

[Sharding-Monitor]
module=galeramon
monitor_interval=1000ms
password=secret
servers=shard2,shard3,shard4
type=monitor
user=maxscale_monitor

[shard4]
address=10.139.158.1
port=3366
type=server

Es müssen also noch entsprechende Nachbesserungen an den Konfigurationsdateien vorgenommen werden. Man müsste sich allgemein überlegen ob man bei einem hochdynamischen System nicht alles dynamisch über Befehle konfigurieren sollte…

Wartungsarbeiten am Shard

Wenn für Wartungsarbeiten ein Shard offline genommen werden soll, hier im Beispiel shard2, kann dies wie folgt bewerkstelligt werden:

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬──────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 1 │ Running │ 0-3364-69817 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 1 │ Running │ 0-3365-63166 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼──────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 1 │ Running │ 0-3366-6902 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴──────────────┴──────────────────┘

shell> maxctrl set server shard2 drain
OK

shell> maxctrl set server shard2 maintenance
OK

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────┬───────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼──────────────────────┼───────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 0 │ Maintenance, Running │ 0-3364-240612 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼──────────────────────┼───────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 0 │ Running │ 0-3365-289873 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼──────────────────────┼───────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 0 │ Running │ 0-3366-119848 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴──────────────────────┴───────────────┴──────────────────┘

Zu diesem Zeitpunkt können die Wartungsarbeiten an der Maschine oder der Datenbank vorgenommen werden…

Anschliessend müssen BEIDE Stati wieder gecleared werden, sofern beide gesetzt wurden (MXS-5028):

shell> maxctrl clear server shard2 maintenance
OK

shell> maxctrl clear server shard2 drain
OK

maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬───────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 0 │ Running │ 0-3364-240612 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 0 │ Running │ 0-3365-289873 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 0 │ Running │ 0-3366-119848 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴───────────────┴──────────────────┘

Der Unterschied zwischen drain und maintenance besteht darin, dass bei drain keinen neuen Verbindungen mehr auf das Shard zugelassen werden aber bei bestehenden Verbindungen wird gewartet, bis sie geschlossen werden. Bei maintenance werden die Verbindungen sofort zwangsweise terminiert.

Beobachtung / Observierung eines MariaDB MaxScale Sharding-Systems

Mit dem MaxScale CLI Client maxtrl kann man den Zustand des MariaDB MaxScale Load Balancers abfragen hierzu gibt es zahlreiche Befehle, hauptsächlich list und show:

shell> maxctrl show module schemarouter | head -n 12
┌─────────────┬────────────────────────────────────────────────┐
│ Module │ schemarouter │
├─────────────┼────────────────────────────────────────────────┤
│ Type │ Router │
├─────────────┼────────────────────────────────────────────────┤
│ Version │ V1.0.0 │
├─────────────┼────────────────────────────────────────────────┤
│ Maturity │ Beta │
├─────────────┼────────────────────────────────────────────────┤
│ Description │ A database sharding router for simple sharding │
├─────────────┼────────────────────────────────────────────────┤
│ Parameters │ ... │

shell> maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬─────────┬───────────────┬──────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard2 │ 10.139.158.1 │ 3364 │ 4 │ Running │ 0-3364-290859 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard3 │ 10.139.158.1 │ 3365 │ 4 │ Running │ 0-3365-322671 │ Sharding-Monitor │
├────────┼──────────────┼──────┼─────────────┼─────────┼───────────────┼──────────────────┤
│ shard4 │ 10.139.158.1 │ 3366 │ 4 │ Running │ 0-3366-140018 │ Sharding-Monitor │
└────────┴──────────────┴──────┴─────────────┴─────────┴───────────────┴──────────────────┘

Die Information für die Spalte Connections ist verwirrend, da wir bei diesem Sharding-System in diesem Fall auf jedem Shard nur 1, 1 und 2 Verbindungen offen haben.

Wenn man sich mit SHOW PROCESSLIST die Situation aber auf dem jeweiligen Shard anschaut, sieht man, dass MaxScale auf JEDEM Shard für jede eingehende Verbindung auch eine Verbindung auf jedes Shard aufbaut. Somit ist die Anzeige oben eigentlich technisch korrekt, nur nicht, was man erwarten würde:

SQL> SHOW PROCESSLIST;
+--------+------------------+----------------------+---------------+---------+------+----------+-----------------------------------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+------------------+----------------------+---------------+---------+------+----------+-----------------------------------------------------------------+----------+
| 123 | root | localhost | customer_0021 | Query | 0 | starting | show processlist | 0.000 |
| 68107 | maxscale_monitor | 10.139.158.211:35418 | NULL | Sleep | 0 | | NULL | 0.000 |
| 113372 | app | 10.139.158.1:47548 | NULL | Sleep | 47 | | NULL | 0.000 |
| 113538 | app | 10.139.158.1:49058 | NULL | Sleep | 41 | | NULL | 0.000 |
| 113662 | app | 10.139.158.1:47072 | NULL | Sleep | 37 | | NULL | 0.000 |
| 114789 | app | 10.139.158.1:39574 | customer_0022 | Query | 0 | Updating | UPDATE sales SET product = 'Prepare to delete' WHERE id = 15622 | 0.000 |
+--------+------------------+----------------------+---------------+---------+------+----------+-----------------------------------------------------------------+----------+

Das skaliert so nicht bei grossen Systemen mit hunderten oder tausenden von Mandanten! Ev. kommt in diesem Fall das MariaDB Thread Pool Feature zum Einsatz.

Laut dem MaxScale Entwickler ist dies erwartetes Verhalten… (MXS-4977)

shell> maxctrl list services
┌─────────────────┬──────────────┬─────────────┬───────────────────┬────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Targets │
├─────────────────┼──────────────┼─────────────┼───────────────────┼────────────────────────┤
│ Sharded-Service │ schemarouter │ 4 │ 82776 │ shard2, shard3, shard4 │
└─────────────────┴──────────────┴─────────────┴───────────────────┴────────────────────────┘

shell> maxctrl list listeners
┌──────────────────────────┬──────┬──────┬─────────┬─────────────────┐
│ Name │ Port │ Host │ State │ Service │
├──────────────────────────┼──────┼──────┼─────────┼─────────────────┤
│ Sharded-Service-Listener │ 3306 │ :: │ Running │ Sharded-Service │
└──────────────────────────┴──────┴──────┴─────────┴─────────────────┘

shell> maxctrl list monitors
┌──────────────────┬─────────┬────────────────────────┐
│ Monitor │ State │ Servers │
├──────────────────┼─────────┼────────────────────────┤
│ Sharding-Monitor │ Running │ shard2, shard3, shard4 │
└──────────────────┴─────────┴────────────────────────┘

shell> maxctrl show server shard2 | head -n 20
┌─────────────────────┬──────────────────────────────────────────────┐
│ Server │ shard2 │
├─────────────────────┼──────────────────────────────────────────────┤
│ Source │ /etc/maxscale.cnf │
├─────────────────────┼──────────────────────────────────────────────┤
│ Address │ 10.139.158.1 │
├─────────────────────┼──────────────────────────────────────────────┤
│ Port │ 3364 │
├─────────────────────┼──────────────────────────────────────────────┤
│ State │ Running │
├─────────────────────┼──────────────────────────────────────────────┤
│ Version │ 10.11.7-MariaDB-log │
├─────────────────────┼──────────────────────────────────────────────┤
│ Uptime │ 178960 │
├─────────────────────┼──────────────────────────────────────────────┤
│ Last Event │ server_down │
├─────────────────────┼──────────────────────────────────────────────┤
│ Triggered At │ Sun, 04 Feb 2024 07:37:17 GMT │
├─────────────────────┼──────────────────────────────────────────────┤
│ Services │ Sharded-Service │
├─────────────────────┼──────────────────────────────────────────────┤
│ Monitors │ Sharding-Monitor │
├─────────────────────┼──────────────────────────────────────────────┤
...
├─────────────────────┼──────────────────────────────────────────────┤
│ Current Connections │ 5 │
├─────────────────────┼──────────────────────────────────────────────┤
│ Total Connections │ 27 │
├─────────────────────┼──────────────────────────────────────────────┤
│ Max Connections │ 5 │

shell> maxctrl show service Sharded-Service
┌─────────────────────┬──────────────────────────────────────────────────────┐
│ Service │ Sharded-Service │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Source │ /var/lib/maxscale/maxscale.cnf.d/Sharded-Service.cnf │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Router │ schemarouter │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ State │ Started │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Started At │ 3/18/2024, 1:52:30 PM │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Users Loaded At │ 3/18/2024, 1:52:30 PM │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Current Connections │ 4 │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Total Connections │ 84590 │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Max Connections │ 5 │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Cluster │ │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Servers │ shard2 │
│ │ shard3 │
│ │ shard4 │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Services │ │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Filters │ │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Parameters │ { │
│ │ "auth_all_servers": true, │
│ │ "connection_keepalive": "300000ms", │
│ │ "debug": true, │
│ │ "disable_sescmd_history": false, │
│ │ "enable_root_user": false, │
│ │ "force_connection_keepalive": false, │
│ │ "idle_session_pool_time": "-1ms", │
│ │ "ignore_tables": [], │
│ │ "ignore_tables_regex": null, │
│ │ "localhost_match_wildcard_host": true, │
│ │ "log_auth_warnings": true, │
│ │ "log_debug": true, │
│ │ "log_info": false, │
│ │ "log_notice": false, │
│ │ "log_warning": false, │
│ │ "max_connections": 0, │
│ │ "max_sescmd_history": 50, │
│ │ "max_staleness": "150000ms", │
│ │ "multiplex_timeout": "60000ms", │
│ │ "net_write_timeout": "0ms", │
│ │ "password": "*****", │
│ │ "prune_sescmd_history": true, │
│ │ "rank": "primary", │
│ │ "refresh_databases": false, │
│ │ "refresh_interval": "10000ms", │
│ │ "retain_last_statements": -1, │
│ │ "router": "schemarouter", │
│ │ "session_trace": false, │
│ │ "strip_db_esc": true, │
│ │ "type": "service", │
│ │ "user": "maxscale_admin", │
│ │ "user_accounts_file": null, │
│ │ "user_accounts_file_usage": "add_when_load_ok", │
│ │ "version_string": null, │
│ │ "wait_timeout": "0ms" │
│ │ } │
├─────────────────────┼──────────────────────────────────────────────────────┤
│ Router Diagnostics │ { │
│ │ "average_session": 0.028822357131634554, │
│ │ "longest_sescmd_chain": 4, │
│ │ "longest_session": 50, │
│ │ "queries": 761134, │
│ │ "sescmd_percentage": 44.44342257736483, │
│ │ "shard_map_hits": 84356, │
│ │ "shard_map_misses": 5, │
│ │ "shard_map_stale": 229, │
│ │ "shard_map_updates": 216, │
│ │ "shortest_session": 0, │
│ │ "times_sescmd_limit_exceeded": 0 │
│ │ } │
└─────────────────────┴──────────────────────────────────────────────────────┘

Siehe hierzu auch MaxScale SchemaRouter Router diagnostics.

shell> maxctrl show monitor Sharding-Monitor
┌─────────────────────┬──────────────────────────────────────────────────────────┐
│ Monitor │ Sharding-Monitor │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ Source │ /etc/maxscale.cnf │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ Module │ galeramon │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ State │ Running │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ Servers │ shard1 │
│ │ shard2 │
│ │ shard3 │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ Parameters │ { │
│ │ "available_when_donor": false, │
│ │ "backend_connect_attempts": 1, │
│ │ "backend_connect_timeout": "3000ms", │
│ │ "backend_read_timeout": "3000ms", │
│ │ "backend_write_timeout": "3000ms", │
│ │ "disable_master_failback": false, │
│ │ "disable_master_role_setting": false, │
│ │ "disk_space_check_interval": "0ms", │
│ │ "disk_space_threshold": null, │
│ │ "events": "all,master_down,master_up,...,new_donor", │
│ │ "journal_max_age": "28800000ms", │
│ │ "module": "galeramon", │
│ │ "monitor_interval": "1000ms", │
│ │ "password": "*****", │
│ │ "root_node_as_master": false, │
│ │ "script": null, │
│ │ "script_timeout": "90000ms", │
│ │ "set_donor_nodes": false, │
│ │ "type": "monitor", │
│ │ "use_priority": false, │
│ │ "user": "maxscale_monitor" │
│ │ } │
├─────────────────────┼──────────────────────────────────────────────────────────┤
│ Monitor Diagnostics │ { │
│ │ "disable_master_failback": false, │
│ │ "disable_master_role_setting": false, │
│ │ "root_node_as_master": false, │
│ │ "server_info": [ │
│ │ { │
│ │ "gtid_binlog_pos": "0-3363-26014", │
│ │ "gtid_current_pos": "0-3363-26014", │
│ │ "master_id": 0, │
│ │ "name": "shard1", │
│ │ "read_only": false, │
│ │ "server_id": 3363 │
│ │ }, │
│ │ { │
│ │ "gtid_binlog_pos": "0-3364-240612", │
│ │ "gtid_current_pos": "0-3364-240612", │
│ │ "master_id": 0, │
│ │ "name": "shard2", │
│ │ "read_only": false, │
│ │ "server_id": 3364 │
│ │ }, │
│ │ { │
│ │ "gtid_binlog_pos": "0-3365-289873", │
│ │ "gtid_current_pos": "0-3365-289873", │
│ │ "master_id": 0, │
│ │ "name": "shard3", │
│ │ "read_only": false, │
│ │ "server_id": 3365 │
│ │ } │
│ │ ], │
│ │ "set_donor_nodes": false, │
│ │ "use_priority": false │
│ │ } │
└─────────────────────┴──────────────────────────────────────────────────────────┘

shell> maxctrl list sessions;
┌───────┬──────┬──────────────┬───────────────────────┬───────┬─────────────────┬────────┬──────────────┐
│ Id │ User │ Host │ Connected │ Idle │ Service │ Memory │ I/O-Activity │
├───────┼──────┼──────────────┼───────────────────────┼───────┼─────────────────┼────────┼──────────────┤
│ 87240 │ app │ 10.139.158.1 │ 3/18/2024, 2:33:54 PM │ 0 │ Sharded-Service │ 68644 │ 33 │
├───────┼──────┼──────────────┼───────────────────────┼───────┼─────────────────┼────────┼──────────────┤
│ 72654 │ app │ 10.139.158.1 │ 3/18/2024, 2:25:27 PM │ 506.3 │ Sharded-Service │ 199328 │ 0 │
├───────┼──────┼──────────────┼───────────────────────┼───────┼─────────────────┼────────┼──────────────┤
│ 72364 │ app │ 10.139.158.1 │ 3/18/2024, 2:25:18 PM │ 516 │ Sharded-Service │ 199328 │ 0 │
├───────┼──────┼──────────────┼───────────────────────┼───────┼─────────────────┼────────┼──────────────┤
│ 72530 │ app │ 10.139.158.1 │ 3/18/2024, 2:25:23 PM │ 510.5 │ Sharded-Service │ 199328 │ 0 │
└───────┴──────┴──────────────┴───────────────────────┴───────┴─────────────────┴────────┴──────────────┘

shell> maxctrl show session 26
┌───────────────────────┬───────────────────────────────────────┐
│ Id │ 26 │
├───────────────────────┼───────────────────────────────────────┤
│ Service │ Sharded-Service │
├───────────────────────┼───────────────────────────────────────┤
│ State │ Session started │
├───────────────────────┼───────────────────────────────────────┤
│ User │ app │
├───────────────────────┼───────────────────────────────────────┤
│ Host │ 10.139.158.1 │
├───────────────────────┼───────────────────────────────────────┤
│ Port │ 42854 │
├───────────────────────┼───────────────────────────────────────┤
│ Database │ │
├───────────────────────┼───────────────────────────────────────┤
│ Connected │ 2/4/2024, 9:31:12 AM │
├───────────────────────┼───────────────────────────────────────┤
│ Idle │ 610.4 │
├───────────────────────┼───────────────────────────────────────┤
│ Parameters │ { │
│ │ "log_error": false, │
│ │ "log_info": false, │
│ │ "log_notice": false, │
│ │ "log_warning": false │
│ │ } │
├───────────────────────┼───────────────────────────────────────┤
│ Client TLS Cipher │ │
├───────────────────────┼───────────────────────────────────────┤
│ Connection attributes │ { │
│ │ "_client_name": "libmariadb", │
│ │ "_client_version": "3.3.8", │
│ │ "_os": "Linux", │
│ │ "_pid": "251037", │
│ │ "_platform": "x86_64", │
│ │ "_server_host": "10.139.158.211", │
│ │ "program_name": "mysql" │
│ │ } │
├───────────────────────┼───────────────────────────────────────┤
│ Connections │ shard1 │
│ │ shard2 │
│ │ shard3 │
├───────────────────────┼───────────────────────────────────────┤
│ Connection IDs │ 666 │
│ │ 139 │
│ │ 138 │
├───────────────────────┼───────────────────────────────────────┤
│ Queries │ │
├───────────────────────┼───────────────────────────────────────┤
│ Log │ │
├───────────────────────┼───────────────────────────────────────┤
│ Memory │ { │
│ │ "connection_buffers": { │
│ │ "backends": { │
│ │ "shard1": { │
│ │ "misc": 678, │
│ │ "readq": 65536, │
│ │ "total": 66214, │
│ │ "writeq": 0 │
│ │ }, │
│ │ "shard2": { │
│ │ "misc": 662, │
│ │ "readq": 0, │
│ │ "total": 662, │
│ │ "writeq": 0 │
│ │ }, │
│ │ "shard3": { │
│ │ "misc": 678, │
│ │ "readq": 65536, │
│ │ "total": 66214, │
│ │ "writeq": 0 │
│ │ } │
│ │ }, │
│ │ "client": { │
│ │ "misc": 654, │
│ │ "readq": 65536, │
│ │ "total": 66190, │
│ │ "writeq": 0 │
│ │ }, │
│ │ "total": 199280 │
│ │ }, │
│ │ "exec_metadata": 0, │
│ │ "last_queries": 0, │
│ │ "sescmd_history": 48, │
│ │ "total": 199328, │
│ │ "variables": 0 │
│ │ } │
├───────────────────────┼───────────────────────────────────────┤
│ I/O Activity │ 0 │
└───────────────────────┴───────────────────────────────────────┘

shell> maxctrl show listener Sharded-Service-Listener
┌────────────┬───────────────────────────────────────────┐
│ Name │ Sharded-Service-Listener │
├────────────┼───────────────────────────────────────────┤
│ Source │ /etc/maxscale.cnf │
├────────────┼───────────────────────────────────────────┤
│ Service │ Sharded-Service │
├────────────┼───────────────────────────────────────────┤
│ Parameters │ { │
│ │ "MariaDBProtocol": { │
│ │ "allow_replication": true │
│ │ }, │
│ │ "address": "::", │
│ │ "authenticator": null, │
│ │ "authenticator_options": null, │
│ │ "connection_init_sql_file": null, │
│ │ "connection_metadata": [ │
│ │ "character_set_client=auto", │
│ │ "character_set_connection=auto", │
│ │ "character_set_results=auto", │
│ │ "max_allowed_packet=auto", │
│ │ "system_time_zone=auto", │
│ │ "time_zone=auto", │
│ │ "tx_isolation=auto" │
│ │ ], │
│ │ "port": 3306, │
│ │ "protocol": "MariaDBProtocol", │
│ │ "proxy_protocol_networks": null, │
│ │ "service": "Sharded-Service", │
│ │ "socket": null, │
│ │ "sql_mode": "default", │
│ │ "ssl": false, │
│ │ "ssl_ca": null, │
│ │ "ssl_cert": null, │
│ │ "ssl_cert_verify_depth": 9, │
│ │ "ssl_cipher": null, │
│ │ "ssl_crl": null, │
│ │ "ssl_key": null, │
│ │ "ssl_verify_peer_certificate": false, │
│ │ "ssl_verify_peer_host": false, │
│ │ "ssl_version": "MAX", │
│ │ "type": "listener", │
│ │ "user_mapping_file": null │
│ │ } │
└────────────┴───────────────────────────────────────────┘

shell> maxctrl show module schemarouter
┌─────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Module │ schemarouter │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Type │ Router │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ V1.0.0 │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Maturity │ Beta │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Description │ A database sharding router for simple sharding │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Parameters │ [ │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Enable debug mode", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "debug", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": [], │
│ │ "description": "List of tables to ignore when checking for duplicates", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "ignore_tables", │
│ │ "type": "stringlist" │
│ │ }, │
│ │ { │
│ │ "description": "Regex of tables to ignore when checking for duplicates", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "ignore_tables_regex", │
│ │ "type": "regex" │
│ │ }, │
│ │ { │
│ │ "default_value": "150000ms", │
│ │ "description": "Maximum allowed staleness of a database map entry before clients block and wait for an update", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "max_staleness", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Refresh database mapping information", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "refresh_databases", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": "300000ms", │
│ │ "description": "How often to refresh the database mapping information", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "refresh_interval", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Retrieve users from all backend servers instead of only one", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "auth_all_servers", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": "300000ms", │
│ │ "description": "How ofted idle connections are pinged", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "connection_keepalive", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "deprecated": true, │
│ │ "description": "Alias for 'wait_timeout'", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "connection_timeout", │
│ │ "type": "duration" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Disable session command history", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "disable_sescmd_history", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Allow the root user to connect to this service", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "enable_root_user", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Ping connections unconditionally", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "force_connection_keepalive", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": "-1ms", │
│ │ "description": "Put connections into pool after session has been idle for this long", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "idle_session_pool_time", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "default_value": true, │
│ │ "description": "Match localhost to wildcard host", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "localhost_match_wildcard_host", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": true, │
│ │ "description": "Log a warning when client authentication fails", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "log_auth_warnings", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Log debug messages for this service (debug builds only)", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "log_debug", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Log info messages for this service", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "log_info", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Log notice messages for this service", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "log_notice", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Log warning messages for this service", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "log_warning", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": 0, │
│ │ "description": "Maximum number of connections", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "max_connections", │
│ │ "type": "count" │
│ │ }, │
│ │ { │
│ │ "default_value": 50, │
│ │ "description": "Session command history size", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "max_sescmd_history", │
│ │ "type": "count" │
│ │ }, │
│ │ { │
│ │ "default_value": "60000ms", │
│ │ "description": "How long a session can wait for a connection to become available", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "multiplex_timeout", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "default_value": "0ms", │
│ │ "description": "Network write timeout", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "net_write_timeout", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ }, │
│ │ { │
│ │ "description": "Password for the user used to retrieve database users", │
│ │ "mandatory": true, │
│ │ "modifiable": true, │
│ │ "name": "password", │
│ │ "type": "password" │
│ │ }, │
│ │ { │
│ │ "default_value": true, │
│ │ "description": "Prune old session command history if the limit is exceeded", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "prune_sescmd_history", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": "primary", │
│ │ "description": "Service rank", │
│ │ "enum_values": [ │
│ │ "primary", │
│ │ "secondary" │
│ │ ], │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "rank", │
│ │ "type": "enum" │
│ │ }, │
│ │ { │
│ │ "default_value": -1, │
│ │ "description": "Number of statements kept in memory", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "retain_last_statements", │
│ │ "type": "int" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "description": "Enable session tracing for this service", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "session_trace", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": false, │
│ │ "deprecated": true, │
│ │ "description": "Track session state using server responses", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "session_track_trx_state", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "default_value": true, │
│ │ "deprecated": true, │
│ │ "description": "Strip escape characters from database names", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "strip_db_esc", │
│ │ "type": "bool" │
│ │ }, │
│ │ { │
│ │ "description": "Username used to retrieve database users", │
│ │ "mandatory": true, │
│ │ "modifiable": true, │
│ │ "name": "user", │
│ │ "type": "string" │
│ │ }, │
│ │ { │
│ │ "description": "Load additional users from a file", │
│ │ "mandatory": false, │
│ │ "modifiable": false, │
│ │ "name": "user_accounts_file", │
│ │ "type": "path" │
│ │ }, │
│ │ { │
│ │ "default_value": "add_when_load_ok", │
│ │ "description": "When and how the user accounts file is used", │
│ │ "enum_values": [ │
│ │ "add_when_load_ok", │
│ │ "file_only_always" │
│ │ ], │
│ │ "mandatory": false, │
│ │ "modifiable": false, │
│ │ "name": "user_accounts_file_usage", │
│ │ "type": "enum" │
│ │ }, │
│ │ { │
│ │ "description": "Custom version string to use", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "version_string", │
│ │ "type": "string" │
│ │ }, │
│ │ { │
│ │ "default_value": "0ms", │
│ │ "description": "Connection idle timeout", │
│ │ "mandatory": false, │
│ │ "modifiable": true, │
│ │ "name": "wait_timeout", │
│ │ "type": "duration", │
│ │ "unit": "ms" │
│ │ } │
│ │ ] │
├─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Commands │ [ │
│ │ { │
│ │ "attributes": { │
│ │ "arg_max": 1, │
│ │ "arg_min": 1, │
│ │ "description": "Clear schemarouter shard map cache", │
│ │ "method": "POST", │
│ │ "parameters": [ │
│ │ { │
│ │ "description": "The schemarouter service", │
│ │ "required": true, │
│ │ "type": "SERVICE" │
│ │ } │
│ │ ] │
│ │ }, │
│ │ "id": "clear", │
│ │ "links": { │
│ │ "self": "http://127.0.0.1:8989/v1/modules/schemarouter/clear/" │
│ │ }, │
│ │ "type": "module_command" │
│ │ }, │
│ │ { │
│ │ "attributes": { │
│ │ "arg_max": 1, │
│ │ "arg_min": 1, │
│ │ "description": "Invalidate schemarouter shard map cache", │
│ │ "method": "POST", │
│ │ "parameters": [ │
│ │ { │
│ │ "description": "The schemarouter service", │
│ │ "required": true, │
│ │ "type": "SERVICE" │
│ │ } │
│ │ ] │
│ │ }, │
│ │ "id": "invalidate", │
│ │ "links": { │
│ │ "self": "http://127.0.0.1:8989/v1/modules/schemarouter/invalidate/" │
│ │ }, │
│ │ "type": "module_command" │
│ │ } │
│ │ ] │
└─────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

shell> maxctrl show commands schemarouter
┌────────────┬────────────┬──────────────────────────┐
│ Command │ Parameters │ Descriptions │
├────────────┼────────────┼──────────────────────────┤
│ clear │ SERVICE │ The schemarouter service │
├────────────┼────────────┼──────────────────────────┤
│ invalidate │ SERVICE │ The schemarouter service │
└────────────┴────────────┴──────────────────────────┘

shell> maxctrl show dbusers Sharded-Service
┌───────────────────────┬────────────────┬───────────────────────┬───────┬───────┬────────┬───────┬──────┐
│ User │ Host │ Plugin │ TLS │ Super │ Global │ Proxy │ Role │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ PUBLIC │ │ │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ app │ 10.139.158.% │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ app_role │ │ │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ mariadb.sys │ localhost │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_admin │ 10.139.158.210 │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_admin │ 10.139.158.211 │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_admin_role │ │ │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_monitor │ 10.139.158.210 │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_monitor │ 10.139.158.211 │ mysql_native_password │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ maxscale_monitor_role │ │ │ false │ false │ false │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ mysql │ localhost │ mysql_native_password │ false │ true │ true │ false │ │
├───────────────────────┼────────────────┼───────────────────────┼───────┼───────┼────────┼───────┼──────┤
│ root │ localhost │ mysql_native_password │ false │ true │ true │ false │ │
└───────────────────────┴────────────────┴───────────────────────┴───────┴───────┴────────┴───────┴──────┘

shell> maxctrl show commands mariadbmon
┌───────────────────────────┬─────────────────────────────┬───────────────────────────────────────────────────────────────────────────────┐
│ Command │ Parameters │ Descriptions │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ switchover │ MONITOR, [SERVER], [SERVER] │ Monitor name, New primary (optional), Current primary (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ switchover-force │ MONITOR, [SERVER], [SERVER] │ Monitor name, New primary (optional), Current primary (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-switchover │ MONITOR, [SERVER], [SERVER] │ Monitor name, New primary (optional), Current primary (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ failover │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-failover │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ rejoin │ MONITOR, SERVER │ Monitor name, Joining server │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-rejoin │ MONITOR, SERVER │ Monitor name, Joining server │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ reset-replication │ MONITOR, [SERVER] │ Monitor name, Primary server (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-reset-replication │ MONITOR, [SERVER] │ Monitor name, Primary server (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ release-locks │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-release-locks │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ fetch-cmd-result │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ cancel-cmd │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-add-node │ MONITOR, STRING, STRING │ Monitor name, Hostname/IP of node to add to ColumnStore cluster, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-remove-node │ MONITOR, STRING, STRING │ Monitor name, Hostname/IP of node to remove from ColumnStore cluster, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ cs-get-status │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-get-status │ MONITOR │ Monitor name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-start-cluster │ MONITOR, STRING │ Monitor name, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-stop-cluster │ MONITOR, STRING │ Monitor name, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-set-readonly │ MONITOR, STRING │ Monitor name, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-cs-set-readwrite │ MONITOR, STRING │ Monitor name, Timeout │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-rebuild-server │ MONITOR, SERVER, [SERVER] │ Monitor name, Target server, Source server (optional) │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-create-backup │ MONITOR, SERVER, STRING │ Monitor name, Source server, Backup name │
├───────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ async-restore-from-backup │ MONITOR, SERVER, STRING │ Monitor name, Target server, Backup name │
└───────────────────────────┴─────────────────────────────┴───────────────────────────────────────────────────────────────────────────────┘

Literatur / Quellen

MaxScale: Simple Sharding with Two Servers
MaxScale: SchemaRouter

dbstat für MariaDB (und MySQL)

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 14 Mar 2024 11:33:42 +0000

Inhaltsverzeichnis

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:

sar - Collect, report, or save system activity information.

und Oracle Statspack:

Statspack is a performance tuning tool … to quickly gather detailed analysis of the performance of that database instance.

Funktionalität

Zwar haben wir seit längerem das Performance Schema, aber dieses deckt einige Punkte nicht ab, die wir in der Praxis als Problem sehen und von Kunden gewünscht werden:

Das Modul table_size sammelt Daten über das Wachstum von Tabellen. Somit können Aussagen über das Wachstum einzelner Tabellen, Datenbanken, die zukünftigen MariaDB Kataloge oder die ganze Instanz gemacht werden. Dies ist interessant für Nutzer welche Multi-Mandanten-Systeme (multi-tenant) im Einsatz oder sonst wie mit unkontrolliertem Wachstum zu kämpfen haben.
Das Modul processlist macht in regelmässigen Abständen einen Snapshot der Prozessliste und speichert diese ab. Diese Informationen sind nützlich bei post-mortem Analysen wenn der Nutzer zu langsam war, seine Prozessliste wegzuspeichern oder um zu verstehen, wie sich ein Problem aufgebaut hat.
Oft baut sich das Problem durch langlaufende Transaktion, Row Locks oder Metadata Locks auf. Diese werden durch die Module trx_and_lck sowie metadata_lock festgehalten und abgespeichert. Somit können wir Probleme sehen, die wir vorher gar nicht gespürt haben oder wird sehen nach dem Unglück, was zum Problem geführt hat (analog zu einem Fahrtenschreiber im Fahrzeug).
Eine weitere Fragestellung, die wir in der Praxis manchmal antreffen, ist: Wann wurde welche Datenbankvariable geändert und wie sah sie vorher aus. Dies wird durch das Modul global_variables abgedeckt. Wer oder warum die Variable geändert hat, kann leider datenbankseitig nicht eruiert werden. Dazu sind betriebliche Prozesse notwendig.
Das letzte Modul, global_status deckt eigentlich das ab, was sar/sysstat tut. Es sammelt die Werte von SHOW GLOBAL STATUS; ein und speichert sie ab für spätere Analysezwecke oder um damit einfach Graphen erstellen zu können.

Wie funktioniert `dbstat`

dbstat nutzt als Scheduler den Datenbank Event Scheduler. Dieser muss bei MariaDB zuerst eingeschaltet werden (event_scheduler = ON). Bei MySQL ist er bereits per default eingeschaltet. Der Event Scheduler hat den Vorteil, dass wir die Jobs feingranularer aktivieren können, zum Beispiel 10 s, was mit der Crontab nicht möglich wäre.

Der Event Scheduler führt dann SQL/PSM Code aus um einerseits die Daten zu sammeln und andererseits die Daten auch wieder zu löschen, damit die dbstat Datenbank nicht ins unermessliche wächst.

Aktuell sind folgende Jobs vorgesehen:

Modul	Sammeln	Löschen	Mengengerüst	Bemerkungen
`table_size`	1/d um 02:04	12/h, 1000 rows, > 31 d	1000 tab x 31 d = 31k rows	Sollte bis 288k Tabellen funktionieren.
`processlist`	1/min	1/min, 1000 rows, > 7 d	1000 con x 1440 min x 7 d = 10M rows	Sollte bis 1000 Concurrent Connections funktionieren.
`trx_and_lck`	1/min	1/min, 1000 rows, > 7 d	100 lck x 1440 min x 7 d = 1M rows	Hängt sehr stark von der Anwendung ab.
`metadata_lock`	1/min	12/h, 1000 rows, > 30 d	100 mdl x 1440 x 30 d = 4M rows	Hängt sehr stark von der Anwendung ab.
`global_variables`	1/min	nie	1000 rows	Im Normalfall sollte diese Tabelle nicht anwachsen.
`global_status`	1/min	1/min, 1000 rows, > 30 d	1000 rows x 1440 x 30 d = 40M rows	Kann gross werden?

Installation

dbstat kann von Github heruntergeladen werden und steht unter der GPLv2.

Die Installation ist einfach: Als erstes die SQL Datei create_user_and_db.sql ausführen. Dann in der Datenbank dbstat die entsprechenden create_*.sql Dateien für die jeweiligen Module ausführen. Es gibt zur Zeit keine direkten Abhängigkeiten zwischen den Modulen. Wenn ein anderer User oder eine andere Datenbank als dbstat verwendet werden soll, muss man sich selber drum kümmern.

Abfrage

Einige mögliche Abfragen auf die Daten wurden bereits vorbereitet. Sie sind zu finden in den Dateien query_*.sql. Hier ein paar Beispiele:

`table_size`

SELECT `table_schema`, `table_name`, `ts`, `table_rows`, `data_length`, `index_length`
 FROM `table_size`
 WHERE `table_catalog` = 'def'
 AND `table_schema` = 'dbstat'
 AND `table_name` = 'table_size'
ORDER BY `ts` ASC
;
+--------------+------------+---------------------+------------+-------------+--------------+
| table_schema | table_name | ts | table_rows | data_length | index_length |
+--------------+------------+---------------------+------------+-------------+--------------+
| dbstat | table_size | 2024-03-09 20:01:00 | 0 | 16384 | 16384 |
| dbstat | table_size | 2024-03-10 17:26:33 | 310 | 65536 | 16384 |
| dbstat | table_size | 2024-03-11 08:28:12 | 622 | 114688 | 49152 |
| dbstat | table_size | 2024-03-12 08:02:38 | 934 | 114688 | 49152 |
| dbstat | table_size | 2024-03-13 08:08:55 | 1247 | 278528 | 81920 |
+--------------+------------+---------------------+------------+-------------+--------------+

`processlist`

SELECT connection_id, ts, time, state, SUBSTR(REGEXP_REPLACE(REPLACE(query, "<br>n", ' '), '<br> +', ' '), 1, 64) AS query
 FROM processlist
 WHERE command != 'Sleep'
 AND connection_id = @connection_id
 ORDER BY ts ASC
 LIMIT 5
;
+---------------+---------------------+---------+---------------------------------+---------------------------------------------+
| connection_id | ts | time | state | query |
+---------------+---------------------+---------+---------------------------------+---------------------------------------------+
| 14956 | 2024-03-09 20:21:12 | 13.042 | Waiting for table metadata lock | update test set data = 'bla' where id = 100 |
| 14956 | 2024-03-09 20:22:12 | 73.045 | Waiting for table metadata lock | update test set data = 'bla' where id = 100 |
| 14956 | 2024-03-09 20:23:12 | 133.044 | Waiting for table metadata lock | update test set data = 'bla' where id = 100 |
| 14956 | 2024-03-09 20:24:12 | 193.044 | Waiting for table metadata lock | update test set data = 'bla' where id = 100 |
| 14956 | 2024-03-09 20:25:12 | 253.041 | Waiting for table metadata lock | update test set data = 'bla' where id = 100 |
+---------------+---------------------+---------+---------------------------------+---------------------------------------------+

`trx_and_lck`

SELECT * FROM trx_and_lck<br>G
*************************** 1. row ***************************
 machine_name:
 connection_id: 14815
 trx_id: 269766
 ts: 2024-03-09 20:05:57
 user: root
 host: localhost
 db: test
 command: Query
 time: 41.000
 running_since: 2024-03-09 20:05:16
 state: Statistics
 info: select * from test where id = 6 for update
 trx_state: LOCK WAIT
 trx_started: 2024-03-09 20:05:15
trx_requested_lock_id: 269766:821:5:7
 trx_tables_in_use: 1
 trx_tables_locked: 1
 trx_lock_structs: 2
 trx_rows_locked: 1
 trx_rows_modified: 0
 lock_mode: X
 lock_type: RECORD
 lock_table_schema: test
 lock_table_name: test
 lock_index: PRIMARY
 lock_space: 821
 lock_page: 5
 lock_rec: 7
 lock_data: 6
*************************** 2. row ***************************
 machine_name:
 connection_id: 14817
 trx_id: 269760
 ts: 2024-03-09 20:05:57
 user: root
 host: localhost
 db: test
 command: Sleep
 time: 60.000
 running_since: 2024-03-09 20:04:57
 state:
 info:
 trx_state: RUNNING
 trx_started: 2024-03-09 20:04:56
trx_requested_lock_id: NULL
 trx_tables_in_use: 0
 trx_tables_locked: 1
 trx_lock_structs: 2
 trx_rows_locked: 1
 trx_rows_modified: 1
 lock_mode: X
 lock_type: RECORD
 lock_table_schema: test
 lock_table_name: test
 lock_index: PRIMARY
 lock_space: 821
 lock_page: 5
 lock_rec: 7
 lock_data: 6

`metadata_lock`

SELECT lock_mode, ts, user, host, lock_type, table_schema, table_name, time, started, state, query
 FROM metadata_lock
 WHERE connection_id = 14347
 ORDER BY started DESC
 LIMIT 5
;
+-------------------------+---------------------+------+-----------+----------------------+--------------+------------+-------+---------------------+----------------+------------------------------------------------------+
| lock_mode | ts | user | host | lock_type | table_schema | table_name | time | started | state | query |
+-------------------------+---------------------+------+-----------+----------------------+--------------+------------+-------+---------------------+----------------+------------------------------------------------------+
| MDL_SHARED_WRITE | 2024-03-13 10:27:33 | root | localhost | Table metadata lock | test | test | 1.000 | 2024-03-13 10:27:32 | Updating | UPDATE test set data3 = MD5(id) |
| MDL_BACKUP_TRANS_DML | 2024-03-13 10:27:33 | root | localhost | Backup lock | | | 1.000 | 2024-03-13 10:27:32 | Updating | UPDATE test set data3 = MD5(id) |
| MDL_BACKUP_ALTER_COPY | 2024-03-13 10:22:33 | root | localhost | Backup lock | | | 0.000 | 2024-03-13 10:22:33 | altering table | ALTER TABLE test DROP INDEX ts, ADD INDEX (ts, data) |
| MDL_SHARED_UPGRADABLE | 2024-03-13 10:22:33 | root | localhost | Table metadata lock | test | test | 0.000 | 2024-03-13 10:22:33 | altering table | ALTER TABLE test DROP INDEX ts, ADD INDEX (ts, data) |
| MDL_INTENTION_EXCLUSIVE | 2024-03-13 10:22:33 | root | localhost | Schema metadata lock | test | | 0.000 | 2024-03-13 10:22:33 | altering table | ALTER TABLE test DROP INDEX ts, ADD INDEX (ts, data) |
+-------------------------+---------------------+------+-----------+----------------------+--------------+------------+-------+---------------------+----------------+------------------------------------------------------+

`global_variables`

SELECT variable_name, COUNT(*) AS cnt
 FROM global_variables
 GROUP BY variable_name
 HAVING COUNT(*) > 1
;
+-------------------------+-----+
| variable_name | cnt |
+-------------------------+-----+
| innodb_buffer_pool_size | 7 |
+-------------------------+-----+

SELECT variable_name, ts, variable_value
 FROM global_variables
 WHERE variable_name = 'innodb_buffer_pool_size'
;
+-------------------------+---------------------+----------------+
| variable_name | ts | variable_value |
+-------------------------+---------------------+----------------+
| innodb_buffer_pool_size | 2024-03-09 21:36:28 | 134217728 |
| innodb_buffer_pool_size | 2024-03-09 21:40:25 | 268435456 |
| innodb_buffer_pool_size | 2024-03-09 21:41:25 | 268435456 |
| innodb_buffer_pool_size | 2024-03-09 21:42:25 | 268435456 |
| innodb_buffer_pool_size | 2024-03-09 21:43:25 | 268435456 |
| innodb_buffer_pool_size | 2024-03-09 21:44:25 | 268435456 |
| innodb_buffer_pool_size | 2024-03-09 21:48:14 | 134217728 |
+-------------------------+---------------------+----------------+

`global_status`

SELECT s1.ts
 , s1.variable_value AS 'table_open_cache_misses'
 , s2.variable_value AS 'table_open_cache_hits'
 FROM global_status AS s1
 JOIN global_status AS s2 ON s1.ts = s2.ts
 WHERE s1.variable_name = 'table_open_cache_misses'
 AND s2.variable_name = 'table_open_cache_hits'
 AND s1.ts BETWEEN '2024-03-13 11:55:00' AND '2024-03-13 12:05:00'
 ORDER BY ts ASC
;
+---------------------+-------------------------+-----------------------+
| ts | table_open_cache_misses | table_open_cache_hits |
+---------------------+-------------------------+-----------------------+
| 2024-03-13 11:55:47 | 1001 | 60711 |
| 2024-03-13 11:56:47 | 1008 | 61418 |
| 2024-03-13 11:57:47 | 1015 | 62125 |
| 2024-03-13 11:58:47 | 1022 | 62829 |
| 2024-03-13 11:59:47 | 1029 | 63533 |
| 2024-03-13 12:00:47 | 1036 | 64237 |
| 2024-03-13 12:01:47 | 1043 | 64944 |
| 2024-03-13 12:02:47 | 1050 | 65651 |
| 2024-03-13 12:03:47 | 1057 | 66355 |
| 2024-03-13 12:04:47 | 1064 | 67059 |
+---------------------+-------------------------+-----------------------+

Testen

Zur Zeit haben wir dbstat auf unseren Test- und Produktionssystemen ausgerollt um es zu testen und zu sehen ob unsere Annahmen bezüglich Stabilität und Berechnungen des Mengengerüsts zutreffen. Zudem stellen wir beim selber nutzen am besten fest, wenn es noch was fehlt oder die Handhabung unpraktisch ist (Eat your own dog food).

Quellen

Wir bauen uns ein Data Warehouse aus dem General Query Log

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 30 Jan 2024 16:17:31 +0000

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

Üblicherweise zäumt man beim Bau eines Data Warehouses das Pferd von hinten auf:

Welche Fragen soll mein Data Warehouse beantworten können?
Wie muss ich mein Modell designen damit sich meine Fragen einfach beantworten lassen?
Woher kriege ich die Daten um das Modell zu befüllen?
Wie befülle ich mein Model mit den Daten?

Zu Übungszwecken sind wir hier einer Fragestellung nachgegangen, welche ab und zu bei unserem Support auftaucht: Das System fängt plötzlich und unerwartet an sich ungewöhnlich zu verhalten, niemand hat was gemacht und niemand weiss warum. Beispiel bei einem Kunden letzte Woche: Um 15 Uhr fängt das System an instabil zu werden, wird anschliessend hart neu gestartet und stabilisiert sich dann ab 16 Uhr wieder…

Das einfachste wäre es, in einem solchen Fall, schnell mit dem Befehl SHOW PROCESSLIST auf die Datenbank zu schauen und dann wird oft sofort klar, wo das Problem liegt. Aber oft vergessen das die Kunden oder sie sind nicht schnell genug. Bei diesem Kunden war das General Query Log bereits eingeschaltet, das wäre also ein prima Fall für unser General Query Log Data Warehouse!

Welche Fragen soll mein Data Warehouse beantworten können?

Die generische Fragestellung für dieses Problem müsste in etwa lauten: “Wer oder was hat mein System dazu veranlasst, sich ungewöhnlich zu verhalten.”

Technisch ausgedrückt würde die Frage in etwa lauten:

Wer: Welcher User oder Account war zur fraglichen Zeit mit wie vielen Connections auf der Datenbank drauf? Was war daran ungewöhnlich?
Was: Welche Abfragen liefen zur fraglichen Zeit in welchem Schema auf dem System? Welche dieser Abfragen waren ungewöhnlich?

Wie soll mein Modell aussehen?

Aus der Fragestellung können wir bereits einige Fakten und Dimensionen ableiten:

User oder Account (User + Host)
Zeit
Connections
Schema
Abfragen

Und daraus ergeben sich auch bereit 4 Dimensionen und die Fact-Tabelle:

Datenquelle

Woher die Daten kommen ist in diesem Fall relativ einfach zu beantworten: Der Kunde stellt seine General Query Logs zur Verfügung oder zu Testzwecken kann man auch die General Query Logs unserer eigenen Systeme verwenden.

Wie wird das Modell befüllt?

Technisch geht das unter dem Begriff ETL-Prozess (Extract-Transform-Load). In unserem Fall haben wir einen General Query Log Parser gebaut, der das General Query Log einliest, die Daten entsprechend aufbereitet und im Modell abspeichert.

Überprüfung des Modells

Und dann kommen wir auch schon zur Überprüfung des Modells. Wir haben dazu Testdaten eines unserer Systeme verwendet:

Welcher User war zur fraglichen Zeit auf dem System drauf?
Welcher User hatte zur fraglichen Zeit wie viel Connections offen?

SELECT td.time, cd.user, COUNT(*) AS count
 FROM connection_dim cd
 JOIN query_fact AS qf ON qf.connection_id = cd.connection_id
 JOIN time_dim AS td ON td.time_id = qf.time_id
 JOIN date_dim AS dd ON dd.date_id = qf.date_id
 WHERE td.time BETWEEN '17:00' AND '18:30'
 AND dd.date = '2019-08-02'
 GROUP BY td.time, cd.user
 ORDER BY td.time ASC, cd.user
;
+----------+---------------+-------+
| time | user | count |
+----------+---------------+-------+
| 17:58:00 | UNKNOWN USER | 1 |
| 17:59:00 | brman | 58 |
| 17:59:00 | brman_catalog | 18 |
| 17:59:00 | root | 5 |
| 18:00:00 | brman | 296 |
| 18:00:00 | brman_catalog | 7 |
| 18:00:00 | root | 3 |
| 18:01:00 | brman_catalog | 18 |
| 18:01:00 | root | 3 |
| 18:06:00 | brman | 266 |
| 18:06:00 | brman_catalog | 6 |
| 18:07:00 | brman | 88 |
| 18:07:00 | brman_catalog | 7 |
| 18:10:00 | brman | 211 |
| 18:10:00 | brman_catalog | 18 |
| 18:10:00 | root | 4 |
| 18:11:00 | brman | 141 |
| 18:11:00 | root | 3 |
| 18:13:00 | brman | 4 |
| 18:14:00 | brman | 348 |
| 18:17:00 | brman | 354 |
| 18:17:00 | brman_catalog | 12 |
| 18:17:00 | root | 1 |
+----------+---------------+-------+

Welcher Account war zur fraglichen Zeit auf dem System drauf?
Welcher Account hatte zur fraglichen Zeit wie viel Connections offen?

SELECT td.time, cd.user, cd.hostname, COUNT(*) AS count
 FROM connection_dim cd
 JOIN query_fact AS qf ON qf.connection_id = cd.connection_id
 JOIN time_dim AS td ON td.time_id = qf.time_id
 JOIN date_dim AS dd ON dd.date_id = qf.date_id
 WHERE td.time BETWEEN '17:00' AND '18:30'
 AND dd.date = '2019-08-02'
 GROUP BY td.time, cd.user, cd.hostname
 ORDER BY td.time ASC, cd.user
;
+----------+---------------+--------------+-------+
| time | user | hostname | count |
+----------+---------------+--------------+-------+
| 17:58:00 | UNKNOWN USER | UNKNOWN HOST | 1 |
| 17:59:00 | brman | localhost | 58 |
| 17:59:00 | brman_catalog | localhost | 18 |
| 17:59:00 | root | localhost | 5 |
| 18:00:00 | brman | localhost | 296 |
| 18:00:00 | brman_catalog | localhost | 7 |
| 18:00:00 | root | localhost | 3 |
| 18:01:00 | brman_catalog | localhost | 18 |
| 18:01:00 | root | localhost | 3 |
| 18:06:00 | brman | localhost | 266 |
| 18:06:00 | brman_catalog | localhost | 6 |
| 18:07:00 | brman | localhost | 88 |
| 18:07:00 | brman_catalog | localhost | 7 |
| 18:10:00 | brman | localhost | 211 |
| 18:10:00 | brman_catalog | localhost | 18 |
| 18:10:00 | root | localhost | 4 |
| 18:11:00 | brman | localhost | 141 |
| 18:11:00 | root | localhost | 3 |
| 18:13:00 | brman | localhost | 4 |
| 18:14:00 | brman | localhost | 348 |
| 18:17:00 | brman | localhost | 354 |
| 18:17:00 | brman_catalog | localhost | 12 |
| 18:17:00 | root | localhost | 1 |
+----------+---------------+--------------+-------+

Was war daran ungewöhnlich?

SELECT cd.user, td.time, COUNT(*) AS count
 FROM connection_dim cd
 JOIN query_fact AS qf ON qf.connection_id = cd.connection_id
 JOIN time_dim AS td ON td.time_id = qf.time_id
 JOIN date_dim AS dd ON dd.date_id = qf.date_id
 WHERE td.time BETWEEN '17:00' AND '18:30'
 AND dd.date = '2019-08-02'
 GROUP BY td.time, cd.user
 ORDER BY cd.user ASC, td.time ASC
;
+---------------+----------+-------+
| user | time | count |
+---------------+----------+-------+
| brman | 17:59:00 | 58 |
| brman | 18:00:00 | 296 |
| brman | 18:06:00 | 266 |
| brman | 18:07:00 | 88 |
| brman | 18:10:00 | 211 |
| brman | 18:11:00 | 141 |
| brman | 18:13:00 | 4 |
| brman | 18:14:00 | 348 |
| brman | 18:17:00 | 354 |
| brman_catalog | 17:59:00 | 18 |
| brman_catalog | 18:00:00 | 7 |
| brman_catalog | 18:01:00 | 18 |
| brman_catalog | 18:06:00 | 6 |
| brman_catalog | 18:07:00 | 7 |
| brman_catalog | 18:10:00 | 18 |
| brman_catalog | 18:17:00 | 12 |
| root | 17:59:00 | 5 |
| root | 18:00:00 | 3 |
| root | 18:01:00 | 3 |
| root | 18:10:00 | 4 |
| root | 18:11:00 | 3 |
| root | 18:17:00 | 1 |
| UNKNOWN USER | 17:58:00 | 1 |
+---------------+----------+-------+

Man könnte hier z.B. ableiten, dass der User brman relativ viele Verbindung in der fraglichen Zeit offen hatte. Ob das ungewöhnlich ist, dazu haben wir zu wenige Daten bzw. dazu ist der Zeitraum zu klein.

Welche Abfragen liefen zur fraglichen Zeit in welchem Schema auf dem System?
Welche dieser Abfragen waren ungewöhnlich?

SELECT sd.schema_name, td.time, SUBSTR(std.statement_text, 1, 128) AS query
 FROM query_fact AS qf
 JOIN time_dim AS td ON td.time_id = qf.time_id
 JOIN schema_dim AS sd ON sd.schema_id = qf.schema_id
 JOIN statement_dim AS std ON std.statement_id = qf.statement_id
 WHERE td.time BETWEEN '17:00' AND '18:30'
 AND sd.schema_name = 'brman_catalog'
 AND std.command = 'Query'
 ORDER BY td.time, qf.statement_id
 LIMIT 10
;
+---------------+----------+----------------------------------------------------------------------------------------------------------------------------------+
| schema_name | time | query |
+---------------+----------+----------------------------------------------------------------------------------------------------------------------------------+
| brman_catalog | 17:59:00 | SET NAMES `utf8` |
| brman_catalog | 17:59:00 | SELECT COUNT ( * ) AS `cnt` FROM `information_schema` . `tables` WHERE `table_schema` = ? AND TABLE_NAME = ? |
| brman_catalog | 17:59:00 | SELECT COUNT ( * ) AS `cnt` FROM `information_schema` . `tables` WHERE `table_schema` = ? AND TABLE_NAME = ? |
| brman_catalog | 17:59:00 | CREATE TABLE `metadata` ( `id` TINYINT UNSIGNED NOT NULL AUTO_INCREMENT , `key` VARCHARACTER (?) NOT NULL , `value` VARCHARACTER |
| brman_catalog | 17:59:00 | INSERT INTO `metadata` ( `key` , `value` ) VALUES (...) |
| brman_catalog | 17:59:00 | INSERT INTO `metadata` ( `key` , `value` ) VALUES (...) |
| brman_catalog | 17:59:00 | CREATE TABLE `backups` ( `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT , `instance_name` VARCHARACTER (?) NOT NULL , `start_ts` |
| brman_catalog | 17:59:00 | CREATE TABLE `backup_details` ( `backup_id` INTEGER UNSIGNED NOT NULL , `hostname` VARCHARACTER (?) NULL , `binlog_file` VARCHAR |
| brman_catalog | 17:59:00 | CREATE TABLE `files` ( `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT , `schema_name` VARCHARACTER (?) NULL , `original_name` VAR |
| brman_catalog | 17:59:00 | CREATE TABLE `binary_logs` ( `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT , `filename` VARCHARACTER (?) NOT NULL , `begin_ts` I |
+---------------+----------+----------------------------------------------------------------------------------------------------------------------------------+

Verbesserungsvorschläge

Anhand dieser ersten Iteration des Modells sieht man auch schon, welche Fragen das Modell noch nicht beantworten kann oder wo das Modell zu ungenau ist. Dies kann dann in einer zweiten Rund nachgebessert werden….

Beispiele hierzu sind:

Die Granulariät der Dimension time ist mit Minutengenauigkeit möglicherweise zu grob. Sekundengenauigkeit wäre sinnvoller?

Die Frage, wie lange eine Connection offen war lässt sich nich so einfach beantworten. Ev. wäre hier eine weiter Fact Tabelle angebracht?

SELECT cd.connection_number, cd.user, cd.hostname, tdf.time AS time_from, tdt.time AS time_to, (UNIX_TIMESTAMP(tdt.time) - UNIX_TIMESTAMP(tdf.time)) AS duration
 FROM connection_dim AS cd
 JOIN query_fact AS qf1 ON cd.connection_id = qf1.connection_id
 JOIN time_dim AS tdf ON tdf.time_id = qf1.time_id
 JOIN statement_dim AS sdf ON sdf.statement_id = qf1.statement_id
 JOIN query_fact AS qf2 ON cd.connection_id = qf2.connection_id
 JOIN time_dim AS tdt ON tdt.time_id = qf2.time_id
 JOIN statement_dim AS sdt ON sdt.statement_id = qf2.statement_id
 WHERE tdf.time BETWEEN '17:00' AND '18:30'
 AND sdf.command = 'Connect'
 AND sdt.command = 'Quit'
 AND (UNIX_TIMESTAMP(tdt.time) - UNIX_TIMESTAMP(tdf.time)) > 0
 ORDER BY tdf.time
;
+-------------------+-------+-----------+-----------+----------+----------+
| connection_number | user | hostname | time_from | time_to | duration |
+-------------------+-------+-----------+-----------+----------+----------+
| 211 | brman | localhost | 17:59:00 | 18:00:00 | 60 |
| 215 | root | localhost | 18:00:00 | 18:17:00 | 1020 |
| 219 | brman | localhost | 18:06:00 | 18:07:00 | 60 |
| 225 | brman | localhost | 18:10:00 | 18:11:00 | 60 |
| 226 | brman | localhost | 18:13:00 | 18:14:00 | 60 |
+-------------------+-------+-----------+-----------+----------+----------+

Spannend wäre natürlich jetzt noch, wenn man eine KI auf das Problem ansetzt. Wie traniert man sie richtig und findet sie das Problem, wenn sie trainiert wurde?

Soweit die kleine Spielerei zum Bau eines Data Warehouses…

InnoDB Deadlock bei SELECT? Nicht möglich! Oder doch?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 19 Nov 2023 16:18:11 +0100

Einleitung

Kurz vorab zwei Punkte:

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:
```
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
```
Im MariaDB Ökosystem gilt allgemein das Mantra, dass ein SELECT keine Locks verursacht (Ausnahme: FOR UPDATE oder LOCK IN SHARE MODE) und somit auch nicht Teil eines Deadlocks sein kann.

Das Problem

Ein langjähriger Kunde kommt zum FromDual remote-DBA Team mit der Bitte, eine Deadlock-Situation zu erklären:

Hallo FromDual Team, ich brauche mal wieder euer Fachwissen zum Thema Deadlocks. Wann würde es Euch passen?

Die Situation ist folgende: Transaktion 1 besteht aus einem simplen INSERT. Transaktion 2 besteht aus einem SELECT. Das dürfte eigentlich KEINEN Deadlock verursachen!

Zuerst prüfen wir folgende Punkte ab:

Sind alle Tabellen, die durch diese Abfragen betroffen sind, sauber indexiert? Jawohl sind sie. Die Queries laufen alle perfekt!
Ist die SELECT Abfragen eventuell Teil einer grösseren Transaktion (NICHT Auto-Commit Transaktion) und daher nicht die eigentlich Ursache für den Deadlock? Nein, ist sie nicht. Es handelt sich um Auto-Commit Transaktionen.

Was nun? Was man zur Erläuterung noch sagen muss: Das SELECT wird mit einer sehr hohen Kadenz, also so ca. alle 5 ms abgesetzt!

Dass der INSERT Locks erzeugt ist klar. Wird ja auch angezeigt. Aber warum erzeugt der SELECT Befehl Locks? Diese werden ebenfalls angezeigt!

Also versuchen wir das Problem in Einzelschritte runter zu brechen.

Der Lösungsweg

Das Query sieht wie folgt aus:

SQL> SET @id = (SELECT id FROM test WHERE id = 3);

Wenn wir dieses Query in eine explizite Transaktion packen, können wir die Locks sogar sehen:

SQL> START TRANSACTION;
SQL> SET @id = (SELECT id FROM test WHERE id = 3);

und in einer zweiten Session:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:27:09
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 2
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 1
 trx_lock_structs: 2
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 1
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Leider sehen wir nicht welche Art von Lock (IS) es ist, da die View INNODB_LOCKS leer ist.

Die Lösung

Wenn wir den selben Versuch mit “normalen” SELECTs machen:

SQL> START TRANSACTION; SELECT id FROM test WHERE id = 3;

oder

SQL> START TRANSACTION; SELECT id INTO @id FROM test WHERE id = 3;

sehen wir KEINE Locks:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:31:35
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 0
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 0
 trx_lock_structs: 0
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 0
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Es scheint also so zu sein, dass das Konstrukt SET @id = (...) diesen IS Lock verursacht. Der Kunde schreibt seine Applikation um und kurz darauf erhalten wir folgende Meldung:

Hallo FromDual Team, Euer Tipp war goldrichtig. Seit Freitag Mittag keine Deadlocks mehr. Danke und schönes Wochenende.

Weitere geklärte Fragen

MySQL 8.0 verhält sich gleich? Ja, genau gleich.

Nachtrag

Mein lieber Kollege Matthias hat mich noch auf eine Folgeidee gebracht: Wie sieht das Ganze aus mit MariaDB Stored Procedures und Stored Functions?

Die beiden Tests hier:

DELIMITER //

CREATE OR REPLACE PROCEDURE locktestsp (INOUT id INT)
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
END;
//

DELIMITER ;

SET @id = 3;
START TRANSACTION;
CALL locktestsp(@id);
SELECT @id;

SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

und hier:

DELIMITER //

CREATE OR REPLACE FUNCTION locktestsf (IN id INT)
RETURNS CHAR(50) DETERMINISTIC
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
 RETURN id;
END;
//

DELIMITER ;

START TRANSACTION;
SELECT locktestsf(3);

 SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

Webinar: Upgrade Ihres MySQL 5.7 Galera Clusters auf MySQL 8.0 ohne Ausfallzeiten

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 16 Nov 2023 11:34:22 +0000

Sie haben sicher schon davon gehört, dass MySQL 5.7 im Oktober 2023 das End of Life (EOL) erreicht hat. In diesem Webinar zeigen wir Ihnen, dass die Migration von MySQL 5.7 Galera Cluster nicht schwierig ist. MySQL 8.0 ist seit 5 Jahren allgemein verfügbar, und das Galera Cluster für MySQL 8.0 hat sich seit über 3 Jahren im Markt bewährt. Es ist also wirklich an der Zeit, sich auf die Migration vorzubereiten.

Im ersten Webinar dieser Reihe werden wir uns mit den neuen Funktionen von Galera Cluster mit MySQL 8 befassen:

Die neuen Funktionen von Galera Cluster für MySQL 8, von denen Sie profitieren können, einschliesslich der in der Galera Cluster Enterprise Edition (EE) verfügbaren Funktionen
Wie man eine Migration von MySQL 5.7 auf MySQL 8.0 plant
Dinge, die vor der Migration getestet werden sollten
Häufige Fallstricke bei einer solchen Migration
Wie Sie sicherstellen, dass Ihr Galera Cluster während der Migration ohne Ausfallzeiten weiterläuft

Das Webinar findet am Freitag, 17. November 2023, 9:00 - 10:00 MEZ statt.

Für das Webinar können Sie sich hier registrieren.

Präsentatoren:
Oli Sennhauser, Fromdual
Sakari Keskitalo, Codership, the developers of Galera Cluster

Über Galera Cluster Support Subskriptionen und Migrations-Support informieren wir sie gerne persönlich. Bitte wenden Sie sich an uns, wir helfen Ihnen gerne weiter.

Bitte senden Sie Ihre Fragen, Anmerkungen und Ihr Feedback an: contact@fromdual.com

Mit freundlichen Grüssen,
Ihr FromDual Team

MariaDB und MySQL Schulungsprogramm 2023

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 17 Jan 2023 16:24:10 +0000

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.

Folgende Termine können wir Ihnen für das Jahr 2023 schon jetzt anbieten:

30
. Januar bis 3. Februar 2023: MariaDB/MySQL für Fortgeschrittene, GFU Schulungszentrum, Köln
27
. Februar bis 3. März 2023: MariaDB/MySQL für Fortgeschrittene, Heinlein Akademie, Berlin
20
. bis 24. März 2023: MariaDB/MySQL für Fortgeschrittene, Linuxhotel, Essen
27
. bis 29. März 2023: Galera Cluster für MariaDB/MySQL, GFU Schulungszentrum, Köln
24
. bis 28. April 2023: MariaDB/MySQL für Fortgeschrittene, GFU Schulungszentrum, Köln
3
. bis 5. Mai 2023: Galera Cluster für MariaDB/MySQL, Linuxhotel, Essen
15
. bis 17. Mai 2023: Galera Cluster für MariaDB/MySQL, Heinlein Akademie, Berlin
5
. bis 7. Juni 2023: Galera Cluster für MariaDB/MySQL, GFU Schulungszentrum, Köln
24
. bis 28. Juli 2023: MariaDB/MySQL für Fortgeschrittene, GFU Schulungszentrum, Köln
11
. bis 15. September 2023: MariaDB/MySQL für Fortgeschrittene, Heinlein Akademie, Berlin
25
. bis 27. September 2023: Galera Cluster für MariaDB/MySQL, GFU Schulungszentrum, Köln
23
. bis 27. Oktober 2023: MariaDB/MySQL für Fortgeschrittene, GFU Schulungszentrum, Köln
6
. bis 8. November 2023: Galera Cluster für MariaDB/MySQL, Linuxhotel, Essen
13
. bis 15. November 2023: Galera Cluster für MariaDB/MySQL, Heinlein Akademie, Berlin
27
. November bis 1. Dezember 2023: MariaDB/MySQL für Fortgeschrittene, Linuxhotel, Essen
4
. bis 6. Dezember 2023: Galera Cluster für MariaDB/MySQL, GFU Schulungszentrum, Köln

Diese Schulungen können online gebucht werden.

Weitere Termine können während des Jahres noch hinzukommen.

Bei Fragen, oder wenn Sie Spezialwünsche haben, stehen wir Ihnen gerne mit Rat und Tat zur Seite! Zögern Sie nicht, uns zu kontaktieren, wir helfen Ihnen gerne per eMail weiter.

Bei allen weiteren Galera, MariaDB und MySQL Problemen oder Fragen unterstützen wir Sie natürlich ebenfalls gerne!

Mit freundlichen Grüssen,
Ihr FromDual Team

Quellen: Bild von StartupStockPhotos auf Pixabay

Zusätzliche Galera Cluster Schulung im Dezember 2022

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 10 Oct 2022 16:40:32 +0000

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.

Dieses Seminar wird remote durchgeführt. Sie können an diesem Seminar also bequem von zuhause aus teilnehmen…

Eine Seminarübersicht finden Sie hier.

Sie können das Seminar einfach online buchen.

Falls Sie an diesen Terminen verhindert sind, haben wir bereits einige Termine für das Jahr 2023 für Sie in Planung.

Ihr FromDual Schulungsteam

FromDual Seminarprogramm 2022 für MariaDB und MySQL ist online

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 15 Oct 2021 10:27:48 +0000

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:

Im Seminar für Fortgeschrittene nehmen wir uns Themen wie Backup/Restore, Master/Slave Replikation, Galera Cluster sowie Datenbank-Konfigurations-Tuning und SQL Query Tuning vor und üben die einzelnen Punkte praktisch.

Im Galera Cluster Seminar nehmen wir alle Aspekte des Aufbaus und des Betriebs eines Galera Clusters durch und praktizieren das Ganz anschliessend ausführlich.

Den Umständen entsprechend werden die Seminare entweder vor Ort, remote oder hybrid durchgeführt.

Bei allfälligen Fragen bitten wir Sie, mit uns oder unseren Schulungspartnern Kontakt aufzunehmen und diese zu klären.

MariaDB und MySQL Schulungsprogramm 2021

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 03 Feb 2021 09:40:24 +0000

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

Die Schulungen werden remote oder auch vor Ort bei unseren drei Schulungspartnern in Essen, Köln und Berlin angeboten. Oder ein Seminar, ganz persönlich, remote oder vor Ort, bei Ihnen in der Firma.

Wer neu in der Thematik MariaDB oder MySQL ist, für den ist das Seminar MariaDB/MySQL für Einsteiger vorgesehen. Falls Sie sich mit MariaDB oder MySQL schon auskennen empfehlen wir Ihnen das Seminar MariaDB/MySQL für Fortgeschrittene. Wenn Sie Entwickler und nicht Administrator sind, dann ist das Seminar MariaDB/MySQL für Entwickler genau das richtige für Sie. Und sollten Sie mit dem Gedanken spielen, sich einen Galera Cluster anzulachen, dann zeigen wir Ihnen im Seminar Galera Cluster für MariaDB/MySQL wie man das richtig macht und wo Sie dabei aufpassen sollten.

Die geplanten Schulungstermine für das Jahr 2021 finden Sie, immer auf dem neusten Stand, auf unserer Website: MariaDB und MySQL Schulungstermine.

MariaDB/MySQL Datenbank-Administrator/in gesucht

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 19 Nov 2020 15:48:16 +0100

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

Einer unserer Kunden sucht eine/n erfahrene/n MariaDB/MySQL Datenbank-Administrator/in. Arbeitspensum: 80 bis 100% in Festanstellung. Arbeitsort: Hauptstadt Bern (Schweiz). Erfahrung im Betrieb von MariaDB/MySQL Datenbanken im Enterprise-Umfeld sind erforderlich sowie gute MariaDB/MySQL sowie Galera Cluster Kenntnisse notwendig. Einsatzfeld hochkritische, produktive MariaDB Galera Cluster.

Auszug aus der Original-Stellenausschreibung:

Aufgaben:

Aufsetzen, Testen, Betreiben, Warten und Dokumentieren von Datenbanken und Datenbankservern im Entwicklungs-, Abnahme- und Produktivumfeld inkl. Log und Backup
Überwachen und Optimieren der Datenbanken und Datenbankservern hinsichtlich Sicherheit und Performance
Unterhalten der Dokumentationen im DB-Umfeld
Unterstützung des 3rd-Level-Supports für die von uns betriebenen Webanwendungen, Services und Datenbanken
Unterstützen der Softwareentwicklerinnen/ Softwareentwickler bei datenbankbezogenen Fragen und Problemen

Kompetenzen:

Hochschulausbildung im Bereich IT oder grosse Praxiserfahrung in der Datenbankadministration
Fundierte Erfahrungen im Konzipieren, Optimieren, Administrieren und Betreiben (überwachen, absichern, testen) von SQL und NoSQL-Datenbanken und Datenbankclustern im Webumfeld
Freude an neuen Technologien und Bereitschaft, sich in neue Themen einzuarbeiten und nach agilen Vorgehensweisen zu arbeiten
Sehr gute Ausdrucksfähigkeit in Wort und Schrift sowie gute Englischkenntnisse

Wer Interesse hat, soll sich bei mir (Oli Sennhauser) melden, damit ich ihn/sie mit unserem Kunden kurzschliessen kann. FromDual hat kein direktes finanzielles Interesse an dieser Stellenausschreibung!

Programm des Vorarlberger LinuxDay 2020 wurde veröffentlicht

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 18 Sep 2020 10:00:27 +0000

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

Die Vorträge decken Themen querbeet aus dem Opensource Umfeld ab: Linux Mint, Smart Home, Bootloader, Regolith Linux, LibreOffice, MariaDB/MySQL, Forensik, PostgreSQL, Patch-Management, Softwareverteilung, Backup und Videokonferenzdienste.

Im Unterschied zu anderen Jahren findet dieses Jahr die Konferenz am 10. Oktober 2020 rein virtuell statt. Die Teilnahme lohnt sich!

Für MariaDB/MySQL Enthusiasten können wir den Vortrag MariaDB/MySQL Stolperfallen und wie komme ich da wieder raus empfehlen.

Programm der DOAG 2020 Konferenz veröffentlicht

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 11 Sep 2020 10:56:19 +0000

Das diesjährige Programm der DOAG 2020 Konferenz + Ausstellung ist veröffentlicht!

Das Programm ist abwechslungsreich und interessant, wenn auch etwas kleiner als andere Jahre. Die Teilnahme lohnt sich!

Aus MariaDB/MySQL Sicht ist vor allem der Mittwoch, im Raum Kiew (55 Plätze), mit den üblichen Verdächtigen, interessant:

09:00 - 09:45	Sessionkeynote: The new MySQL Database and MySQL Analytics Service - Extreme Performance, Cloud Scale, Significant Cost Savings	Nipun Agarwal
10:00 - 10:45	MariaDB/MySQL Stolperfallen und wie komme ich da wieder raus	Oliver Sennhauser
11:00 - 11:45	Wie ein Ei dem anderen... MySQL ReplicaSets	Matthias Jung
12:00 - 12:45	MySQL 8: Ein Statusbericht 3 Jahre nach dem ersten Release	Carsten Thalheimer

Die Konferenz findet dieses Jahr von Dienstag, dem 17. November 2020 bis Donnerstag, dem 19. November 2020 in Nürnberg und in Teilen auch als online Veranstaltung statt. Mehr dazu auf der Website der Konferenz.

FromDual Schulungen trotz Corona - einfach online und remote

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 23 Mar 2020 15:43:41 +0000

Aufgrund der aktuellen Corona-Pandemie sind sämtliche FromDual vor Ort Schulungen, Schulungen bei unseren Schulungspartnern sowie FromDual Beratungseinsätze bis auf weiteres sistiert.

Damit Sie diesen Frühling aber nicht ganz ohne Weiterbildung auskommen müssen, sind wir bereits seit letzter Woche daran, alternative Möglichkeiten mittels online Schulungen zu testen. Erste Testschulungen wurden bereits Ende letzter Woche und anfangs dieser Woche durchgeführt.

Möglicherweise bietet sich Ihnen in den nächsten Wochen die Möglichkeit, aus dem Homeoffice die eine oder andere unserer online-Schulungen zu besuchen. Voraussichtlich betroffen sind die folgenden Schulungstermine:

2
. bis 4. April: Galera Cluster für MariaDB/MySQL im Linuxhotel in Essen
23
. bis 24. April: Galera Cluster für MariaDB/MySQL in der Heinlein Academy in Berlin
4
. bis 8. Mai: MariaDB/MySQL für Fortgeschrittene bei der GfU Cyrus in Köln
11
. bis 15. Mai: MariaDB/MySQL für Fortgeschrittene in der Heinlein Academy in Berlin

Ob es auch noch spätere Schulungstermine betrifft werden wir sehen…

Remote geht es besser - FromDual remote-DBA Dienstleistungen

Die Corona-Pandemie verursacht möglicherweise auch ein anderes oder neues Lastmuster auf Ihrer Datenbank.

Buchungen werden storniert (Reiseportale),
Rabatt-Aktionen gestartet (Outdoor-Aktivitäten),
es wird vermehrt online eingekauft (Webshops),
es wird vermehrt kommuniziert (VoIP, Video-Conferencing, Screen Sharing) oder auch
die Plattformen des Gesundheitswesen werden heftiger als sonst in Anspruch genommen.
etc.

Falls diese Situation bei Ihnen zu betrieblichen Problemen oder Performance-Engpässen führt, helfen wir Ihnen auch gerne mit einem remote-DBA Einsatz anstelle eines vor Ort Beratungseinsatzes weiter. Wir haben diese Technologien bereits seit Jahren im Einsatz und zeigen Ihnen auch gerne remote, wie Sie Ihre Probleme in den Griff kriegen.

Eher Finger weg: innodb_deadlock_detect

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 06 Mar 2020 15:27:58 +0000

Kürzlich haben wir bei einem unserer Kunden, der gelegentlich massive Datenbankprobleme hat, bei der Durchsicht der MySQL Konfigurationsdatei (my.cnf) festgestellt, dass er die InnoDB Deadlock-Erkennung (innodb_deadlock_detect) deaktiviert hatte.

Da wir davon bisher immer abgeraten haben, ich aber noch nie konkret über dieses Problem gestolpert bin, bin ich der Sache noch etwas nachgegangen und habe zur Variable innodb_deadlock_detect recherchiert.

Die MySQL Dokumentation sagt dazu folgendes
[1
]:

Disabling Deadlock Detection On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. Deadlock detection can be disabled using the innodb_deadlock_detect configuration option.

Und zum Parameter innodb_deadlock_detect selbst
[2
]:

This option is used to disable deadlock detection. On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs.

Das Problem ist, dass jedes mal, wenn MySQL einen (Row) Lock oder Table Lock macht, überprüft wird, ob dieser Lock einen Deadlock verursacht. Was entsprechend teuer ist. Diese Feature wurde übrigens von Facebook entwickelt
[3
].

Die entsprechenden Funktionen sind in
[4
] zu finden:

class DeadlockChecker, method check_and_resolve (DeadlockChecker::check_and_resolve)

Every InnoDB (row) Lock (for mode LOCK_S or LOCK_X) and type ORed with LOCK_GAP or
LOCK_REC_NOT_GAP, ORed with LOCK_INSERT_INTENTION

Enqueue a waiting request for a lock which cannot be granted immediately.

lock_rec_enqueue_waiting()

und

Every (InnoDB) Table Lock

Enqueues a waiting request for a table lock which cannot be granted immediately. Checks for deadlocks.

lock_table_enqueue_waiting()

Das heisst jetzt, wenn die Variable innodb_deadlock_detect eingeschaltet ist (= default) wird bei jedem Lock (Row oder Table) überprüft, ob dadurch ein Deadlock entsteht. Wenn die Variable ausgeschaltet ist, wird diese Überprüfung NICHT ausgeführt (was schneller ist) und die Transaktion bleibt im (Dead-)Lock hängen bis der Lock frei gegeben wird oder die Zeit innodb_lock_wait_timeout (default 50 Sekunden) überschritten ist. Dann schlägt der InnoDB Lock Wait Timeout (Detektor?) zu.

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50 |
+--------------------------+-------+

Das bedeutet, das Deaktivieren der InnoDB Deadlock Detektion ist interessant, wenn Sie sehr viele (wie Facebook!?!) kurze/kleine Transaktionen haben, bei welchen wenig bis keine Konflikte auftreten. Im Weiteren wird empfohlen, gleichzeitig die innodb_lock_wait_timeout auf einen sehr geringen Wert (wenige Sekunden) einzustellen.

Da die meisten unserer Kunden aber nicht in die Kragenweite Facebook passen und tendenziell eher nicht viele gleichzeitige kurze/kleine Transaktionen haben sondern wenig lange Transaktionen (mit wahrscheinlich vielen Locks und daher einer grossen Deadlock-Wahrscheinlichkeit), kann ich mir durchaus vorstellen, dass das deaktivieren diese Parameters für das Verschlucken (Locks stauen auf) des Kundensystems verantwortlich ist, was anschliessen dazu führt, dass max_connections erreicht wird und schliesslich gar nichts mehr geht.

Daher würde ich dringend empfehlen, die InnoDB Deadlock Detektierung aktiviert zu lassen. Ausser man weiss genau, was man tut (nach ca. 2 Wochen testen und messen).

Literatur

[1
] Deadlock Detection and Rollback
[2
] InnoDB Startup Options and System Variables: innodb_deadlock_detect
[3
] Einführung der Variable innodb_deadlock_detect in WebScaleSQL von Facebook auf Github
[4
] MariaDB/MySQL Quellcode: storage/innobase/lock/lock0lock.cc
[5
] MariaDB InnoDB System Variables: innodb_deadlock_detect

FromDual ist 10 Jahre alt

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 02 Mar 2020 10:01:36 +0000

Am 1. März 2020 wurde die FromDual GmbH 10 Jahre alt! Wir möchten allen Kunden, Partnern und Interessenten herzlich für die Unterstützung und gute Zusammenarbeit in den vergangenen 10 Jahren danken. Es würde uns freuen, Euch auch in den kommenden 10 Jahren kompetent beraten und betreuen zu dürfen.

Euer FromDual Team

Bild von kalhh auf Pixabay

FromDual mit Galera Cluster und SQL Query Tuning an den Chemnitzer Linux-Tagen 2020

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 11 Feb 2020 09:55:49 +0000

Zum 22. mal finden am 14. und 15. März 2020 die Chemnitzer Linux-Tage an der Technische Universität Chemnitz statt.

FromDual ist am Samstag, 14. März das erste mal mit einem Workshop “MariaDB Galera Cluster ganz einfach” und am Sonntag, 15. März wieder einmal mit einem Vortrag, diesmal zum Thema MariaDB Performance Tuning: “MariaDB SQL Query Tuning für Applikations-Entwickler”, präsent.

Falls Sie also einmal unter Anleitung einen MariaDB Galera Cluster aufsetzen oder sich mit SQL Query Tuning unter MariaDB vertraut machen wollen, besuchen Sie doch einfach die Chemnitzer Linux-Tage 2020 und sitzen Sie in unseren Vortrag rein oder melden Sie sich für unseren Workshop an.

Bild von Génesis Gabriella auf Pixabay

FromDual wird offizieller MariaDB Partner

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 11 Feb 2020 08:51:05 +0000

Nach Jahren der losen Zusammenarbeit wird FromDual jetzt, im Frühjahr 2020, offizieller MariaDB Partner.

Schon seit Beginn der MariaDB Erfolgsgeschichte befasst sich FromDual mit der Open Source Datenbank MariaDB und hat ihre Kunden mit Rat und Tat beim Betrieb der Datenbank unterstützt.

Da die Nachfrage nach MariaDB in den letzten Jahren laufend zu nahm, bietet FromDual schon seit längerem Schulungen, vor Ort Beratungen (Consulting), und remote-DBA Dienstleistungen für die MariaDB Datenbank an.

Der nächste Schritt, die offizielle Zusammenarbeit, ist somit schon längst fällig: Daher ist FromDual nun offizieller MariaDB Partner geworden.

Dieser Schritt ermöglicht es FromDual ihren Kunden auch beim Erwerb, der Nutzung und der Implementierung der MariaDB Enterprise Edition Subskription tatkräftig zu unterstützen um den grössten Nutzen aus dieser Datenbank zu ziehen.

Zudem wurden sämtliche FromDual Tools und die Monitoring-as-a-Service Dienstleistung für die MariaDB Datenbank funktionsfähig gemacht und werden schon seit einiger Zeit vollständig unterstützt.

FromDual Performance Monitor 1.1.0 für MariaDB und MySQL freigegeben

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 06 Feb 2020 14:19:01 +0000

FromDual hat die Version 1.1.0 des Performance Monitors für MariaDB, MySQL und Galera Cluster (fpmmm) freigegeben.

Dieser Performance Monitor ermöglicht es DBAs und Systemadministratoren einen tiefen Einblick in das Innenleben der Datenbank und des Servers, auf dem sich die Datenbank befindet, zu erhalten.

Die neue Version steht hier zum Download bereit.

Falls Sie sich die Mühe sparen wollen, eine eigene Monitoring-Infrastruktur aufzubauen, nutzen Sie doch einfach unsere kostengünstige Monitoring-as-a-Service Lösung. Gerne schicken wir Ihnen ein Angebot.

Wichtige Neuerungen

fpmmm steht jetzt paketiert für CentOS mit RPM und Ubuntu mit DEB Paketen zur Verfügung.
MariaDB 10.4 wird ab sofort offiziell durch fpmmm unterstützt.
fpmmm unterstützt ab sofort ausschliesslich PHP Version 7+.
Sämtliche Zabbix Templates wurden auf die Version 4.0 upgegraded.
Ein Backup-Hook wurde eingeführt. Sie können somit Ihr eigenes Backup-System oder den FromDual Backup Manager in fpmmm einbinden.
Graphen für InnoDB Buffer Pool flushing und InnoDB Files wurden hinzugefügt.
MariaDB Thread Pool Monitoring, für Anwendungen welche extrem viele Verbindungen zu Datenbank aufbauen, wurde hinzugefügt.
Die Graphen für den Aria Pagecache wurde verbessert.

Eine vollständige Liste der Verbesserungen finden Sie hier.

Eine detaillierte Anleitung zum fpmmm finden Sie im fpmmm Installation Guide.

Viel Spass beim Überwachen Ihrer MariaDB/MySQL Datenbank,
Ihr FromDual Team

MariaDB und MySQL Schulungsprogramm 2020

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 13 Dec 2019 16:02:24 +0000

Hiermit präsentieren wir Ihnen das FromDual Schulungsprogramm 2020 für MariaDB und MySQL. Auch nächstes Jahr führen wir wieder zahlreiche MariaDB und MySQL Schulungen für Anfänger und Fortgeschrittene bei unseren 3 Partnern in Essen, Köln und Berlin durch.

Die Liste mit Schulungsterminen 2020 finden Sie hier.

Welches für Sie das richtige Schulungsmodul ist, erläutern wir unter der Seite Schulungsmodule.

Gleich richtig los geht es anfangs Januar mit MariaDB und MySQL für Einsteiger. Dieser Kurs ist schon fast ausgebucht und findet daher sicher statt. Sichern Sie sich also noch die letzten Plätze!

FromDual Technik-Blog

Im FromDual Blog berichten wir regelmässig darüber, mit welchen Themen wir unser Wissen erweitert haben. Diese Artikel sind frei verfügbar und somit auch Ihnen zugänglich:

Mit MySQL 8.0 wird utf8mb4 das neue Default Character Set. Was Sie hierzu beachten sollten, haben wir im Artikel: MariaDB and MySQL Character Set Conversion beschrieben.
Wie Sie den Progress Indicator des Backup und Recovery Managers nutzen, finden Sie im Artikel: FromDual Recovery Manager (rman) with progress indicator.
Falls Sie sich entscheiden sollten, die Seite zu wechseln, gibt es im Artikel Migration from MySQL 5.7 to MariaDB 10.4 einige nützliche Tipps hierzu.
Wenn Sie genauer wissen wollen, wo Ihr RAM geblieben ist gibt Ihnen der Artikel: Who else is using my memory - File System Cache analysis möglicherweise neue Denkanstösse.
Bei der Untersuchung von Problemen nutzen wir immer wieder das General Query Log. Wie man es aber nur für eine bestimmte Verbindung aktiviert, finden Sie hier beschrieben: Enable General Query Log per Connection in MariaDB.
Auch wir sind (leider) nicht ganz fehlerfrei. Wie wir unser CRM kaputt und anschliessend wieder heile gemacht haben beschreiben wir in: Oops! - That SQL Query was not intended… Flashback.
Falls Sie sich das Swappen auf Ihrem System nicht erklären können, empfehlen wir Ihnen folgenden Artikel: Do not underestimate performance impacts of swapping on NUMA database systems.

Werkzeuge für den täglichen Datenbankbetrieb

FromDual bietet Ihnen auch eine breite Palette von nützlichen Werkzeuge für den täglichen Betrieb und die Pflege Ihrer MariaDB und MySQL Datenbanken an:

Das überaus nützliche sys Schema haben wir von MySQL nach MariaDB portiert. Das sys Schema können Sie jetzt von Github beziehen. Wie sie dazu vorgehen müssen beschreiben wir im Artikel MariaDB sys Schema.

Im Sommer haben wir einen weiteren Release des FromDual Ops Centers für MariaDB und MySQL freigegeben. Point-in-Time Recovery ist jetzt ebenfalls über das Ops Center möglich.

Ebenfalls im August ist die neuste Version des FromDual Backup und Recovery Managers (brman) für MariaDB und MySQL erschienen.

Hoffentlich noch dieses Jahr releasen wir die nächste Version des FromDual Performance Monitors für MariaDB und MySQL (fpmmm).

Sämtliche FromDual Software kann von FromDual Servern unter Download heruntergeladen werden.

Monitoring as a Service

Falls Sie sich keine eigene Monitoring Lösung antun wollen, bieten wir Ihnen auch gerne unsere preiswerte Monitoring-as-a-Service (MaaS) Lösung an. Nehmen Sie hierzu einfach mit uns Kontakt auf. Wir unterbreiten Ihnen gerne ein Angebot.

Ich denke, hiermit haben Sie genügend zu tun, damit Ihnen über die Feiertag nicht langweilig wird… :-)

Schöne Weihnachten und einen gute Rutsch ins neue Jahr wünscht Ihnen
Ihr FromDual Schulungsteam

FromDual: FromDual TechFeed (de)

Percona gibt Galera Cluster für Version 9.7 frei

Was bisher geschah

Perconas Ankündigung von gestern

Installation

Quellen

PostgreSQL Daten retten bei korrupten Blocks

Interpretation der Informationen

Zur “relation”

Kaputt machen

Korruption eingrenzen

Daten retten

Mehr Daten retten

Quellen

PostgreSQL Dokumentation noch besser machen

PostgreSQL Dokumentation verbessern

Qualitätssicherung

Patch einreichen

Künstlich verzögerte Replikation mit PostgreSQL

Anwendungsfälle

Aufsetzen der Primary Instanz

Aufsetzen der Standby Instanz

Das Ups-Query

Stoppen der Replikation

Aufholen bis zum Ups-Query

Backups mit der MySQL Clone Operation

Vorbereitungen

Lokales Backup mittels Clone

Remote Backup mittels Clone

Fazit

Quellen

PostgreSQL Point-in-Time-Recovery bei Ups-Queries

Die Testumgebung

Der Alarm

Vorbereitungen

Recovery zur XID

Recovery zur LSN

Nacharbeiten

Datenbank Index Optimierer

MariaDB, MySQL und Percona Server

Tabellen ohne Primary Key

Doppelte Indices

Teilweise redundante Indices

Ungenutzte Indices

Und jetzt mit PostgreSQL

Tabellen ohne Primary Key

Doppelte Indices

Teilweise redundante Indices

Ungenutzte Indices

PG Assistant

Intallation von PG Assistant

Nachtrag

MariaDB verkürzt Wartungszeitraum von 5 auf 3 Jahre

MariaDB Server LTS Release Wartungszeiträume

Debian

Ubuntu

Rocky Linux

Oracle / MySQL Releases

Percona

OurSQL / VillageSQL

PostgreSQL

Weitere Quellen

Wie lädt man Daten am schnellsten in die Datenbank?

Variante 1: INSERT und DELETE (einfachste Form)

Variante 2: START TRANSACTION und INSERT und DELETE

Variante 3: START TRANSACTION und optimiertes INSERT und DELETE

Test Set-up

Vorbereitung und Ausführung mit MariaDB/MySQL

Vorbereitung und Ausführung mit PostgreSQL

Resultate

Bemerkungen

Weitere Beiträge

MariaDB hat das Konzept des dynamisch konfigurierbaren Buffer Pools kaputt gemacht!

Problembeschreibung

Wie ging es früher?

Was macht MariaDB heute?

Wie macht das PostgreSQL?

Kommentare

Wie viel Platz braucht NULL?

Versuch mit MariaDB/MySQL

Variante 1: `INSERT` und `DELETE` (einfachste Form)

Variante 2: `START TRANSACTION` und `INSERT` und `DELETE`

Variante 3: `START TRANSACTION` und optimiertes `INSERT` und `DELETE`

Einfache Variante: Ändern von `SYS_UID_MAX` und `SYS_GID_MAX` auf 1001

Kompliziertere Variante: Ändern der `UID` von 1001 auf 990