MySQL Workbench 8

Kleines Ratespiel: Wurde für diese Meldung eine SQL-Datenbank benutzt oder nicht? 🙂 Wenig überraschend lautet die Antwort: „Ja“. Das könnte an der weiten Verbreitung und den vielfältigen Anwendungsmöglichkeiten liegen. Es folgt übrigens keine SQL Einführung oder gar ein SQL Lehrgang 😉

Desktop-App: MySQL Workbench 8

Wenn man mit einer SQL-Datenbank arbeiten möchte, braucht man i.d.R. drei Dinge: Einen SQL-Server, einen SQL-Clienten und ein Programm, daß mit den Daten in der SQL-Datenbank etwas machen möchte.

Der im FOSS vermutlich am häufigsten eingesetzt wird, ist MariaDB. Dieser Fork von MySQL entstand, weil Oracle, die die Firma hinter MySQL gekauft hatten, der Meinung war, mal die Regel zu ändern. Das hat einem Teil der Gemeinde, die bislang MySQL mit entwickelt hatten nicht gefallen und so zogen/forkten Sie in eine eigene Trägergesellschaft „The MariaDB Foundation“ um. Zu den größten Sponsoren zählen Booking.com ( die mit den dicken Spamproblem ), Alibaba Cloud und Microsoft (die mit dem eigenen Closed Source MSQL-Server {Wieso eigentlich Microsoft!?!?!?!}), aber auch WordPress Hersteller Automattic, IBM und ein paar Andere.

Bei MariaDB handelt es sich also um den Serverteil, der verschiedene Datenbank Engines unter ein Dach bringt, so daß man diese mit dem SQL-Clienten der Wahl ansprechen kann. Im MariaDB Paket ist ein einfacher Kommandozeilen Client namens „mysql“ mit dabei. Ja, der heißt nicht „mariadb“ sondern „mysql“, weil das ein Fork von MySQL ist, der eine möglichst große Rückwärtskompatibilität anstrebt. Mit anderen Worten, für den Endbenutzer sollte sich nichts ändern. Möglich ist das, weil MySQL eine FOSS Entwicklung ist, die jeder clonen und weiterentwicklen kann, solange er sich an die Lizenzregeln hält.

Jetzt mag nicht jeder in der Konsole rumschrauben, auch wenn das nicht wirklich schwierig ist, und möchte vielleicht eine Desktop-Anwendung benutzen. Hier kommt die MySQL Workbench ins Spiel:

man sieht ein Startfenster mit der Auswahl in welche Datenbank man einloggen möchte.Wenn man das Fedora Paket MariaDB-Server installiert ( dnf install mariadb-server mariadb ), dann kann man direkt mit der Workbench mit der Arbeit anfangen, da der ROOT Zugang zu dem Datenbankserver nicht beschränkt ist. Das ist natürlich auf Dauer eine völlig untragbare Situation, aber irgendwie muß man erstmal in den Datenbankserver rein kommen, um dann dort die Zugangsdaten für den Rootzugang zusetzen 🙂 In meinem Beispiel ist das erst einmal kein Problem, da die spätere App auf einem abgesicherten Server neu aufgesetzt wird. Aber sobald Eurer Server übers Netz erreichbar ist, ist ein Passwortschutz unumgänglich.

Mein drittes Problem, das welches mit den Daten arbeiten soll, gibts noch nicht, aber das wird dann in PHP oder JAVA geschrieben sein. Beide Sprachen bringen einen kompletten Support für MySQL(und Forks) Datenbankserver  mit.

Mit dem SQL-Clienten kann man jetzt die eigentlichen Datenbanken, Tabellen, Views, Indexe und in letzter Konsequenz auch die Datensätze anlegen und bearbeiten:

Im Beispiel oben die Datenbank namens „census“ und darin die Datenbanktabelle „users“.

Der eine oder andere könnte an der Tabellenbeschreibung erkennen, um was für ein Projekt es sich handelt, aber laßt Euch sagen, es funktioniert leider nicht sauber…{ PAM_MYSQL Frustanflug niederkämpf}.. Wie man hier sehen kann, ist die Ansicht der Datenzeile(n) reicht ansehnlich. Für einfache Bearbeitungen ist der Client gut zu benutzen, aber ehrlich gesagt ist PHPMyAdmin weitaus besser!

Also wenn Ihr mal ein Desktopprogramm sucht, mit dem Ihr in einer SQL Datenbank arbeiten könnte, das wäre ein brauchbares.

Für Fedora herunterladen könnt Ihr das hier: https://dev.mysql.com/downloads/workbench/#downloads Ihr müßt aber erstmal das passende OS ( hier Fedora ) auswählen, damit Euch die Downloadlinks angeboten werden. Das klappt sogar erfreulicherweise ohne Javascript 🙂 Die Fedora RPM-Pakete gibt es nur für 64Bit Versionen, aber das dürfte einen heutzutage nicht mehr wirklich stören.

 

The Revenge of Mariadb IV

Es ist mal wieder Zeit für eine MariaDB Geschichte. Keine Panik, die wird nicht wieder biblisch werden 🙂

Es war mal wieder Zeit für ein OS-Upgrade

Mittlerweile waren drei OS-Releases ins Land gegangen und eine sich anbahnende Sicherheitslücke im Exim .. PSSST! Ich habe sie Euch nicht verraten. Tut so, also wenn Ihr nächste Woche das erste mal davon gelesen habt, ja? 😉 .. zwang zu einem schnellen Update auf eine nicht betroffene Version. Fedora 29 sollte es sein 😉

Nun, glücklicherweise war auch ein anderer Testserver noch auf der gleichen alten OS Release, so daß er als Testlauf herhalten durfte. Dieser Test lief ausgesprochen positiv ab, um genau zu sein, makellos. Daher wurde kürzestfristig entschieden, auch den eigentlichen Kandidaten auf die gleiche Art zu updaten. Ein Snapshot der VM und 30 Minuten später  war das Update komplett und der Server startete wieder.

Mailserver, Webserver, IMAP-Server, diverse Dienste liefen. Was natürlich nicht lief war die MariaDB .. Ätzzz. N I C H T  S C  H O N  W I E D E R!   Auch gutes Zureden, energisches Nachtreten mit systemctl änderte nichts an diesem Status, der Datenbankserver startete nicht.

Same procedure als last year, Miss Sophie?

Leider nein. Letztes mal hatte sich bekanntlich ein Konfigfile des Systemd geändert, so daß die zum Start nötigen Limits nicht gesetzt wurden. Natürlich wurde der DIFF Test vom letzten mal auch wieder angewendet, zeigte aber keinen Unterschied an. Also mußte die gute alte Methode „Start den Dienst von Hand, dann bekommst Du Infos“ herhalten.

Wie macht man das?

Wir schauen uns mal an, was der Systemd so starten wollen würde:

cat /usr/lib/systemd/system/mariadb.service

Da findet dann das hier:

ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf
# Note: we set –basedir to prevent probes that might trigger SELinux alarms,
# per bug #547485
ExecStart=/usr/libexec/mysqld –basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
ExecStartPost=/usr/libexec/mysql-check-upgrade

Das POST können wir ignorieren, soweit kommen wir nicht, bleiben nur Pre und der eigentliche Dienststart.

Das in den einschlägigen Envfiles  unter /etc/sysconfig/ nichts steht, reicht also ein :

/usr/libexec/mysqld –basedir=/usr

für den Test aus. Ja super.. eine Fehlermeldung:   Can’t set requested open_files (1024) to 2000 …

Das lag an dem ulimit hier:

# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32088
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 32088
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Damit kann nicht mal die minimale Version der Datenbank starten 😉 Ergo geben wir ein: „ulimit -n 99999“ und starten es nochmal und siehe da, es hat sich doch wieder was geändert:

2019-06-04 23:13:41 0 [ERROR] /usr/libexec/mysqld: unknown variable ‚innodb_additional_mem_pool_size=50M‘
2019-06-04 23:13:41 0 [ERROR] Aborting

Wenn man denn endlich mal in Logfile schaut, sieht man dort auch die Warnung, daß sich das ja mal ändern könnte. Wer rechnet schon mit damit, daß da jemand mal Ernst macht 😉

2019-05-26 09:18:16 b753fd80 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB’s internal memory allocator.
2019-05-26 9:18:16 3075734912 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

Merke, erst ins Datenbank Log schauen, dann Server updaten!

Drei OS-Versionen sind dann vielleicht doch etwas happig bei einem Update. Diese Option findet man, so man sie gesetzt hat, in der Datei /etc/my.cnf . Anweisung auskommentieren, diesmal Datenbank über systemctl starten und läuft wieder 🙂

Und hier dachte ich eigentlich, ist die Story zu ende… war sie aber nicht!

Der an diesem Master angeschlossene Replications Elf ( Sklave sagt man im PCSG nicht mehr 😉 ) mochte die Replikationsblöcke vom Master nicht mehr lesen, weil Checksumme unbekannt! Das lag daran, daß der Replikations Elfe eine ältere Datenbankversion laufen hatte, da LTS. Einer langen Suche kurzes Ende:

Elfen anhalten: mysql -p -e „stop slave
auf den Master connecten: mysql -p -e „set global binlog_checksum=’NONE‘; SHOW MASTER STATUS;“ ausführen.

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000138 | 521505   |              |                  |
+------------------+----------+--------------+------------------+

Datenbank auf dem Master dumpen, auf den Elfen kopieren. Auf dem Elfen die Datenbank wipen, den SQL Dump einspielen.

Auf dem Elfen : mysql -p -e „change master to MASTER_LOG_FILE=’mysql-bin.000138′, MASTER_LOG_POS=521505;start slave

Sollte wieder gehen. Ging nicht.. Neuer Fehler! Statt:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000136' a'

gabs jetzt :

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'test@masterserver:3306' - retry-time: 60  retries: 86400

Er zum Geier ist „TEST“ !?

Tja, keine Ahnung wie das passieren konnte, aber der „change master to …“ Befehl hatte den Replikationsusernamen durch „test“ ersetzt! Einfach so! Passwort war ok, Servername war ok, Username weg! Wie geil ist das denn ?!?!?

Also nochmal mit dem change master an den Elfen ran:

/usr/bin/mysql -p -e „stop slave;;CHANGE MASTER TO MASTER_USER=’myreplicationusername‘,MASTER_PASSWORD=’MeinPasswort‘;start slave

Da machste was mit als Admin … Ich wollte doch nur den Exim abdichten, nicht das Rad neu erfinden! Naja, jetzt gehts ja erstmal wieder 🙂 Und bevor noch einer fragt, nein, der Server hatte extern nur Port 25 zu bieten, deswegen ja auch das Update 😉

MariaDB Bugfix sorgt für ein bisschen Ärger

Ein kleiner selbstverursachter Logikfehler bei Datenbankstrukturen macht kleinen Webanwendungen grade ein bisschen Stress. Damit Ihr damit keinen Stress habt, eine kurze Erklärung zum Thema und wie man das behebt und vermeidet.

MariaDB Update

Bis vor kurzem hatten wir auf den Servern noch die MariaDB 10.1.33 laufen, jetzt die 10.2.21 . Beim Wechsel von 10.1 auf  10.2 haben die Devs von MariaDB den globalen SQL-Modus umgestellt, daß er jetzt eher failed, statt tolerant zu sein.

Eine Beispieltabelle:

beispiel

#NameTypKollationAttributeNullStandardKommentareExtra
1 int(11) Neinkein(e)AUTO_INCREMENT
2 int(11) Nein2
3 text utf8_general_ciNein
4 int(11) Neinkein(e)

Jetzt führen wir diesen Insert aus:

INSERT INTO beispiel SET id=NULL, test = 3, name=“Fritz“, counter = 0;

Klappt. Kein Fehler. Nächster Insert :

INSERT INTO beispiel SET name=“Hans“, counter = 0;

Klappt.Tabelle sieht jetzt so aus :

testnamecounterid
3Fritz01
2Hans02

Nun der Insert hier:

INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;

und schon kommt die Meldung:

ERROR 1364 (HY000): Field ‚counter‘ doesn’t have a default value

Vollkommen zurecht, weil ich im Insert der Datenbank durch Auslassung gesagt habe, nimm den Defaultwert für das ausgelassene Feld.  Da es keinen Defaultwert für das Feld gibt, kann die Datenbank den auch nicht benutzen.

Jetzt ist das aber in MariaDB 10.1 noch möglich gewesen. Das lag daran, daß sich mit 10.2.4 die Defaults des Servermode geändert haben und der Modus „STRICT_TRANS_TABLES“ jetzt aktiv ist, wenn die  Webanwendung das nicht selbst anders haben will. Beweis:

MariaDB [msctest]> INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;
ERROR 1364 (HY000): Field ‚counter‘ doesn’t have a default value
MariaDB [msctest]> SELECT @@SQL_MODE;
+——————————————————————————————-+
| @@SQL_MODE |
+——————————————————————————————-+
| STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+——————————————————————————————-+
1 row in set (0.00 sec)

MariaDB [msctest]> set sql_mode = „ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION“;
Query OK, 0 rows affected (0.00 sec)

MariaDB [msctest]> INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;
Query OK, 1 row affected, 1 warning (0.00 sec)

Jetzt die spannende Frage, mit was die Datenbank den Wert aufgefüllt hat, von dem Sie nicht weiß, wie der aussehen müßte:

idtestnamecounter
13Fritz0
22Hans0
59Killer0

Mit „0“ , was bei einem INT ja auch naheliegend ist.

Klare Ansage

Bevor jetzt jemand den MariaDB Entwicklern die Schuld dafür geben will, daß die eigene Webseite nicht mehr so funktioniert: selbst Schuld!

Ihr habt von vornherein einen Logikbug in Eurer Datenbankstruktur + Weblogik gehabt, sich darüber zu beschweren ist heuchlerisch. Da die Webanwendung sich selbst den Modus setzen kann, mit dem die Datenbank mit Ihr arbeiten soll, hätte man das ja auch mal selbst explizit so setzen können, wie man es braucht. Defaults können sich ändern, damit muß man rechnen.

Abhilfe schaffen

  1. Datenbankstruktur so ändern, daß ein Default vorhanden ist.
  2. Im Insert keine Felder auslassen, sondern explizit setzen.
  3. vor der Anwendung set sql_mode = „ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION“;  absetzen, dann hat man wieder das alte Verhalten

Viel Spaß jetzt damit 🙂