MySQL Queries taggen on FromDual GmbH

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; …

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 |
+-------------------------------+-----------+
| …

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 …

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

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 | …

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: …

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, …

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 …

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 …

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 …

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

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 …

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 | ... |
+--------+-------------+- ... -+-----------+------+-----------------------------------------------+- …

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 …

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 …

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 …

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 …

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 …

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 …

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: …

Linux Container, Incus Spickliste

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 17 Oct 2022 10:10:49 +0200

Seitenübersicht

Container kopieren
Container clonen
Container als tarball exportieren und importieren
Autostart eines Containers deaktivieren
Launch new Container from Image server
Container umbenennen
File von Host in Container kopieren/pushen
Wo liegen die Container rum?
Quellen

Container kopieren

Noch zu testen:

$ incus remote add
$ incus copy CONTAINER_NAME/SNAPSHOT_NAME target:CONTAINER_NAME"

Container clonen

$ incus copy ubuntu-container qa-mariadb118-r

Container als tarball exportieren und importieren

$ incus stop qa-glb
$ incus publish qa-glb --alias my-export
Container published with fingerprint: 9f8410af601eb238224919943d146bc1bcd86429c2dcd5332b7d1bcf271d598d
$ incus image export my-export .
Image exported successfully!
$ incus start qa-glb
$ ls -ltr *.tar.gz
-rw-rw-r-- 1 oli oli 193735169 Oct 17 09:54 9f8410af601eb238224919943d146bc1bcd86429c2dcd5332b7d1bcf271d598d.tar.gz
$ scp 9f8410af601eb238224919943d146bc1bcd86429c2dcd5332b7d1bcf271d598d.tar.gz root@othermachine:

$ incus image import 9f8410af601eb238224919943d146bc1bcd86429c2dcd5332b7d1bcf271d598d.tar.gz --alias my-export
Image imported with fingerprint: 9f8410af601eb238224919943d146bc1bcd86429c2dcd5332b7d1bcf271d598d
$ incus init my-export qa-glb
Creating qa-glb
$ incus start qa-glb
$ incus list
+----------------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+----------------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| qa-glb | RUNNING | 10.153.125.95 (eth0) | | CONTAINER | 0 |
+----------------+---------+----------------------+-----------------------------------------------+-----------+-----------+

Autostart eines Containers deaktivieren

Wichtig: Wenn nichts gesetzt ist, bleibt die Ausgabe leer!

CONTAINER_NAME="qa-glb" …

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

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

Datenschutzerklärung der FromDual GmbH

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 30 May 2018 16:55:56 +0000

Version vom 2019-07-29, basierend auf DSAT.ch

In dieser Datenschutzerklärung erläutern wir, die FromDual GmbH (nachfolgend FromDual, wir oder uns), wie wir Personendaten erheben und sonst bearbeiten. Das ist keine abschliessende Beschreibung; allenfalls regeln andere Datenschutzerklärungen spezifische Sachverhalte. Unter Personendaten werden alle Angaben verstanden, die sich auf eine bestimmte oder bestimmbare Person beziehen.

Wenn Sie uns Personendaten anderer Personen (z.B. Familienmitglieder, Daten von Arbeitskollegen) zur Verfügung stellen, stellen Sie bitte sicher, dass diese Personen die vorliegende Datenschutzerklärung kennen und teilen Sie uns deren Personendaten nur mit, wenn Sie dies dürfen und wenn diese Personendaten korrekt sind.

Diese Datenschutzerklärung ist auf die EU Datenschutz-Grundverordnung (DSGVO) ausgerichtet. Obwohl die DSGVO eine Regulierung der Europäischen Union ist, ist sie für uns von Bedeutung. Das schweizerische Datenschutzgesetz (DSG) ist vom EU-Recht stark beeinflusst, und Unternehmen ausserhalb der Europäischen Union bzw. des EWR haben die DSGVO unter bestimmten Umständen einzuhalten.

Inhaltsverzeichnis

1. Verantwortlicher / Datenschutzbeauftrager / Vertreter

Verantwortlich für die Datenbearbeitungen, die wir hier betreiben, ist FromDual GmbH, Rebenweg 6, CH - 8610 Uster. Wenn Sie datenschutzrechtliche Anliegen haben, können Sie uns diese an folgende Kontaktadresse mitteilen: FromDual GmbH, Datenschutz, Rebenweg 6, CH - 8610 Uster, datenschutz@fromdual.com.

Unseren Datenschutzbeauftragten gemäss Art. 37 DSGVO …

MySQL Enterprise Schulung für Fortgeschrittene von FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 06 Feb 2018 15:33:51 +0000

Aufgrund der gestiegen Nachfrage hat FromDual eine MySQL Enterprise Schulung für Fortgeschrittene MySQL DBAs und DevOps entwickelt. Nachdem wir diese Schulung im letzten Jahr zusammen mit ausgewählten Kunden ausführlich getestet haben bieten wir sie 2018 für eine breite Kundschaft an.

Die MySQL Enterprise Schulung richtet sich an MySQL DBA’s und DevOps, welche bereits mit MySQL vertraut sind und nun vor der Herausforderung stehen, eine ernsthafte MySQL Enterprise Infrastruktur zu betreiben.

Die Liste der Themen, welche während der dreitägigen Schulung behandelt werden finden sie hier.

Es bietet sich zudem die Möglichkeit, 2 Tage MySQL Performance Tuning aus der MySQL für Fortgeschrittene Schulung anzuhängen.

Gerne führen wir diese Schulung bei ihnen vor Ort oder bei einem unserer Schulungspartner in Essen, Berlin oder Köln durch.

Bei Fragen stehen wir Ihnen auch gerne per eMail zur Verfügung.

Schulung MySQL und MariaDB für Fortgeschrittene in Köln 2018

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 17 Jan 2018 16:02:56 +0000

Ende Februar, genauer vom 26. Februar bis 2. März (5 Tage), bietet FromDual eine weitere Schulung für DBAs und DevOps an, unsere häufigst besuchte Schulung: MySQL und MariaDB für Fortgeschrittene.

Diese MySQL/MariaDB Schulung findet in den Räumlichkeiten des FromDual Schulungspartners der GFU Cyrus GmbH in Köln-Deutz statt.

Es haben sich bereits genügend Teilnehmer angemeldet, sodass diese Schulung sicher statt findet. Es hat aber noch Platz für mindestens 3 weitere Teilnehmer.

Die Schulung findet in deutscher Sprache statt.

Den Inhalt dieser fünftägigen MySQL/MariaDB Schulung finden Sie hier.

Bei weiteren Fragen nehmen Sie bitte mit uns <span “mailto:contact@fromdual.com”="">Kontakt auf.

MySQL Enterprise Schulung für Fortgeschrittene

oli.sennhauser@fromdual.com (Oli Sennhauser) — Thu, 04 Jan 2018 12:27:03 +0000

Wenn Sie bereits mit MySQL vertraut sind und nun vor der Herausforderung stehen, eine ernsthafte MySQL Enterprise Infrastruktur zu betreiben, ist diese Schulung die richtige für Sie.

Voraussetzungen

Sie kennen die MySQL Grundlagen und haben bereits erste Erfahrungen mit MySQL gesammelt. SQL ist für Sie kein Fremdwort mehr. Zudem sind Sie vertraut mit der Linux Konsole und beherrschen die wichtigsten UNIX-Kommandos.

Zielgruppe

MySQL Enterprise Anwendungsentwickler und DevOps
MySQL Enterprise Datenbankadministratoren und DevOps
Systemadministratoren mit Datenbankverantwortung

Inhalt

MySQL Enterprise Betrieb (1 Tag)

Installation und Konfiguration von MySQL Enterprise
Backup und Restore mittels mysqldump und mysqlbackup (MySQL Enterprise Backup (MEB))
Point-in-Time-Recovery (PiTR)
Sicherheit

MySQL Enterprise Hochverfügbarkeit (1.5 Tage)

MySQL Enterprise Architekturen
Master/Slave Replikation
Master/Master Replikation
Weiterführende MySQL Replikationsthemen
GTID basierte MySQL Replikation
MySQL Group Replikation (GR)
InnoDB Cluster (Group Replication, MySQL Router, MySQL Shell)

MySQL Enterprise Edition (0.5 Tage)

MySQL Cloud Services
MySQL Enterprise Transparent Data Encryption (TDE)
MySQL Enterprise Scalability (MySQL thread pool)
MySQL Enterprise Authentication (PAM, Windows, Active Directory)
MySQL Enterprise Firewall
MySQL Enterprise Audit
MySQL Enterprise Monitor
OEM für MySQL

Dauer

3 Tage (1 + 1.5 + 0.5) mit der Möglichkeit 2 Tage MySQL Performance Tuning aus der MySQL für Fortgeschrittene Schulung anzuhängen.

Schulung buchen

Schulungen für Deutschland können sie online buchen. Gerne führen wir diese Schulung auch bei ihnen inhaus durch. Mindestteilnehmerzahl ist 4 Personen oder finanzielles Äquivalent.

Weiterführende Schulungen

Abbrechende MariaDB/MySQL Verbindungen

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 23 Apr 2017 14:48:32 +0000

Translate to your preferred language:

Wer sich etwas vertieft mit den MariaDB Status Zählern (SHOW GLOBAL STATUS;) auseinander setzt, wird früher oder später auf den Zähler Aborted_clients stossen:

mariadb> SHOW GLOBAL STATUS LIKE 'aborted_clients';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Aborted_clients | 5392 |
+-----------------+-------+

Wenn man sich dann die MariaDB Dokumentation anschaut, steht da folgendes:

Number of aborted client connections. This can be due to the client not calling mysql_close() before exiting, the client sleeping without issuing a request to the server for more seconds than specified by wait_timeout or interactive_timeout, or by the client program ending in the midst of transferring data.

Also:

Vergessener Aufruf von mysql_close().
Inaktive Verbindung (Sleep) für mehr als wait_timeout oder interactive_timeout Sekunden.
Unerwartete Beendigung der Applikation.

Der erste Punkt geht unter die Kategorie: Unsauber programmiert und somit ein Fehler in der Anwendung.

Der zweite Punkt ist eher ein Konfigurationsproblem sei es auf Datenbankseite oder auf Applikationsseite.

Hier stellt sich die Frage: Warum sind die Timeouts so eingestellt, wenn die Timeouts kurz sind? Default für beide Timeouts ist 28800 Sekunden, also 8 Stunden.

mariadb> SHOW GLOBAL VARIABLES LIKE '%timeout';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| interactive_timeout | 28800 |
| wait_timeout | 28800 |
+---------------------------+-------+

Oder aber: Warum schickt die Anwendung so lange keine Daten über eine geöffnete Verbindung (hat die Anwendung die Verbindung verloren)?

Der zweite Fall trifft üblicherweise dann ein, wenn persistente Verbindungen verwendet werden (Java Connection Pool, Ruby on Rails, PHP Persistent Database Connections, etc.). Dann sollten die Entwickler den Connector so konfigurieren, dass er alle paar Sekunden einen Ping über die Verbindung schickt.

Der …

Oli's Spickliste / Cheat sheet

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 10 Feb 2017 18:37:34 +0100

My brain is getting old and mushy, so I am starting to write stuff down…

File Limit für MySQL hoch setzen
Entropie auf virtuellen Maschinen (VM guests)
Unleserliche Firefox Tooltips unter KDE/Kubuntu
Apache mod_rewrite Beispiele
Historische Performance-Daten mittels sar
Debian Pakete mit Abhängigkeiten installieren
Linux Filesystem Cache flushen
MySQL/MariaDB CLI mini-Benchmark mit Microsekunden Präzision
Bilder auf 1200x900 skalieren
StarOffice Dokumente nach LibreOffice ODF konvertieren
HPLIP Farbdruckproblem-Workaround
ISO Image aus CD/DVD bauen
Pile of Poo Emoji
echo before cat
File download from Xiaomi Mi Mix 2 on Linux
Pretty Print MariaDB output
List Listeners with lsof
SystemD Notizen
Cutting and manipulating PDF
Stopping Baloo
Distribution independent PHP configuration
Check if a Linux reboot is required
Vim Cheat Sheet
Create Swap File and set Swappiness
Teamviewer hacks
Ersatz für ifconfig Statistiken
xtrabackup 2.4 - wichtigste Befehle
CentOS boot device full
Convert LibreOffice Spreadsheet to CSV file format
Compare LibreOffice Presentations
DHCP client handling
Excise Baloo
Cat from STDIN to file for fpmmm test
Remote Syslog Server
Show passwords hidden with mysql_config_editor
List of most recent installed packages
Upgrade only specific packages
GLIBC version
InnoDB NUMA interleave with MariaDB
Extracting and inspecting packages
Taking a node out of Galera Cluster
Make Linux fast again
Checking Galera Cluster SST timeout with Systemd
MariaDB persistent statistics
Find recently modified files
Change timestamps of files
Trick to Simulate a Linux Server with less RAM
MySQL Repository Key expired
Lengths of lines
Debian 11 vim Copy/Paste broken
Kill MariaDB Galera node under SystemD
Audio is broken
Powershell cheat sheet
ssh tunnel for port forwarding
Cutting lines out of a huge file
Colorize a tag with tail
Which GLIBC version is required?
Backtrace when MariaDB hangs
tar with pigz
AppArmor on Ubuntu 24.04 and MySQL 8.0
Find columns with non-central-european-characters …

DOAG Datenbank Konferenz 2016

oli.sennhauser@fromdual.com (Oli Sennhauser) — Tue, 10 May 2016 19:43:09 +0000

Heute war ich auf der DOAG Datenbank 2016 Konferenz in Düsseldorf. Der einzige Vortrag zum Thema MySQL war mein eigener: MySQL für Oracle DBAs. Daher hatte ich die Möglichkeit wieder mal etwas über den Zaun zu linsen. Hier meine Notizen:

Oracle Database in-Memory - What’s new and what’s comming

Von Andy Rivenes, Senior Principal Product Manager, Oracle Corporation

Ist NICHT eine one size fits all Lösung.
Für Analytics-Abfragen (Data Warehouse (DWH), Datamart, BI).
Beschleunigt OLTP Workload NICHT.
Ist ein Column-Store.
In-Memory heisst: weiteren Cache (RAM). Mehr Speicher (RAM) hinzufügen. Column-Store Size. Daten werden partiell doppelt vorgehalten.
Beide Formate Row und Column sind vorhanden.
Optimizer entscheidet ob Row-Store oder Column-Store verwendet wird.
Wird vom DBA pro Tabelle, Partition, Subpartition oder Materialized View festgelegt. 2 - 20 x Kompression.
Column-Store wird on demand aufgebaut. Wenn nicht verfügbar, fallback auf Row-Store.
Column-Store Advisor.
Jeder Core scannt eine Spalte aus dem Column-Store.
Geschwindigkeit: Mia rows/s. Wenn man bedenkt, dass ein Core nur ca. 3 Mia CPU Zyklen pro Sekunde hat, frage ich mich, wie das gerechnet wird…
Eliminiere Indices und nutze Column-Store für grosse OLAP Tabellen.
Schreiben ist langsam. Wie kriegt man denn die Daten schnell in die DB bei grossen Datenmengen?
Scale-out und Scale-Up: Parallelisieren über mehrere Server hinweg.
Spiegeln von Duplikaten über Server hinweg. Somit können Joins lokal gemacht werden.
In-Memory Workload on (Oracle) Chips möglich: DAX, Database Accelleration Engine.
JSON BLOB.
Heatmap: Schlaue Guestimates (in der Zukunft).
When not to use Oracle in-Memory Database: Siehe Slides.

Die Folien muss ich mir noch organisieren. Klingt total cool. Ich frage mich nur, wie gross/breit ist dieser Anwendungsfall? Ich werde mich wohl bald mal mit dem MariaDB Column Store befassen müssen/wollen.

Oracle ACFS / CloudFS zuverlässig nutzbar?

Ralf Appelbaum und Claudia Gabriel, TEAM GmbH

CFS im ASM
ACFS = ASM CFS
für RAC …

MySQL Queries taggen on FromDual GmbH

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

Variante 1: INSERT und DELETE (einfachste Form)

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

Problembeschreibung

Wie ging es früher?

Wie viel Platz braucht NULL?

Jemand löscht meine Shared Memory Segmente!

Linux System User

CSV Dateien in die Datenbank laden

Laden der Daten mit MariaDB/MySQL

Attribute Promotion und Demotion im MariaDB Galera Cluster

Use case des Kunden

Was sagt die MariaDB Dokumentation dazu?

MariaDB Honeypot

Vorbereiten des Honeypots

Wie verhält sich Galera Cluster mit vielen Knoten?

Durchsatz in Abhängigkeit der Anzahl Galera Knoten

Durchsatz in Abhängigkeit der Anzahl Verbindungen

Spielen mit MariaDB Vector für erste KI-Tests

Herunterladen der MariaDB Datenbank mit Vektor Funktionalität

Das Modell

Partieller physischer Datenbank-Restore für MariaDB und MySQL

Um was geht es?

Anwendungsfall

Verkleinern des InnoDB-System-Tablespaces

Wie kann das Problem provoziert werden?

dbstat für MariaDB nach einem Monat produktiver Nutzung

Inhaltsverzeichnis

Rückblick

Einen Monat später

MariaDBs parallele Replikation zum Aufholen

MariaDB Server aus den Quellen bauen

MaxScale Konfigurations-Synchronisation

Inhaltsverzeichnis

Übersicht

Vorbereitungen

Sharding mit MariaDB MaxScale

Inhaltsverzeichnis

Übersicht

dbstat für MariaDB (und MySQL)

Inhaltsverzeichnis

Funktionalität

Wir bauen uns ein Data Warehouse aus dem General Query Log

Welche Fragen soll mein Data Warehouse beantworten können?

Wie soll mein Modell aussehen?

InnoDB Deadlock bei SELECT? Nicht möglich! Oder doch?

Einleitung

Das Problem

Webinar: Upgrade Ihres MySQL 5.7 Galera Clusters auf MySQL 8.0 ohne Ausfallzeiten

MariaDB und MySQL Schulungsprogramm 2023

Linux Container, Incus Spickliste

Seitenübersicht

Container kopieren

Container clonen

Container als tarball exportieren und importieren

Autostart eines Containers deaktivieren

Zusätzliche Galera Cluster Schulung im Dezember 2022

FromDual Seminarprogramm 2022 für MariaDB und MySQL ist online

MariaDB und MySQL Schulungsprogramm 2021

MariaDB/MySQL Datenbank-Administrator/in gesucht

Aufgaben:

Kompetenzen:

Programm des Vorarlberger LinuxDay 2020 wurde veröffentlicht

Programm der DOAG 2020 Konferenz veröffentlicht

FromDual Schulungen trotz Corona - einfach online und remote

Remote geht es besser - FromDual remote-DBA Dienstleistungen

Eher Finger weg: innodb_deadlock_detect

FromDual ist 10 Jahre alt

FromDual mit Galera Cluster und SQL Query Tuning an den Chemnitzer Linux-Tagen 2020

FromDual wird offizieller MariaDB Partner

FromDual Performance Monitor 1.1.0 für MariaDB und MySQL freigegeben

MariaDB und MySQL Schulungsprogramm 2020

FromDual Technik-Blog

Datenschutzerklärung der FromDual GmbH

Inhaltsverzeichnis

1. Verantwortlicher / Datenschutzbeauftrager / Vertreter

MySQL Enterprise Schulung für Fortgeschrittene von FromDual

Schulung MySQL und MariaDB für Fortgeschrittene in Köln 2018

MySQL Enterprise Schulung für Fortgeschrittene

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