[Eisfair] [E1] MySQL 2.5.0 - Crash nach Systemupdate auf MariaDB

[Marcus Roeckrath]

Hallo Benjamin,

Benjamin Heide wrote:

> nach dem Update des kompl. Servers wurde bei der Option "A" natürlich

Du meinst "a"?

> auch MySQL mit geupdatet, was ja auch ok ist. Aber leider ist da ein
> Fehler aufgetreten den ich jetzt nicht weiter ergründen kann.
> 
> Auszug aus dem Logfile:
> 
> ---
> expected column 'sql_mode' at position 14 to have type
>
set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVA
> ERROR: 1548  Cannot load from mysql.proc. The table is probably corrupted
> 151020 15:39:39 [ERROR] Aborting

Hier wird also eine Korrumpierung der Spalte sql_mode in der Tabelle proc
der Datenbank mysql angemeckert.

Das betrifft Deine Daten zunächst mal nicht, sondern ist eine interne
Datenbank von mysql/mariadb.

Repariert werden müsste das aber dennoch; wahrscheinlich durch komplette
Neuinstallation nach Komplett-Deinstallation.

Aber erstmal weiter analysieren und auch weitere Infos wären wichtig.

> 151020 15:39:40 [Note] /usr/bin/mysqld (mysqld 5.5.45-MariaDB) starting
> as process 32154 ...
> InnoDB: Error: inconsistent data in space header in data file ./ibdata1

Also die ist auch irgendwie kaputt.

> 151020 15:39:40 InnoDB: Could not open or create data files.
> 151020 15:39:40 InnoDB: If you tried to add new data files, and it
> failed here,
> 151020 15:39:40 InnoDB: you should now edit innodb_data_file_path in
> my.cnf back
> 151020 15:39:40 InnoDB: to what it was, and remove the new ibdata files
> InnoDB created
> 151020 15:39:40 InnoDB: in this failed attempt. InnoDB only wrote those
> files full of
> 151020 15:39:40 InnoDB: zeros, but did not yet use them in any way. But
> be careful: do not
> 151020 15:39:40 InnoDB: remove old data files which contain your
> precious data!

oder die war aus irgendeinem Grund verschwunden.

Was ist ibdata1?

Es gibt verschiedene Typen von Datenbanken u. a. InnoDB und MyISAM.

Ist Deine Datenbank vom Typ MyIsam liegen unter

/var/lib/mysql/<datenbankname>

sowohl frm-Dateien als auch die Datenbankdateien selbst (*.MYD und *.MYI; *
= Name der Tabelle in der Datenbank).

Benutzt Du auch den Datenbanktyp InnoDB, liegen in

/var/lib/mysql/<datenbankname>

nur die frm-Dateien, die eigentlichen Daten in /var/lib/mysql/ibdata1
(eventuell je nach mysql-Konfiguration auch ibdata2 usw.

ibdata* sind dabei keiner bestimmten InnoDB-Datenbank zugeordnet.

Und genauso eine Datei wird als nicht zu finden/öffnen gemeldet.

Also klären wir erstmal, welches die eigentlichen Datenbanken sind, also
Verzeichnisse unter /var/lib/mysql

Dann von welchem Typ, also gibt es in den Unterverzeichnissen nur die
frm-Dateien oder auch MYD/MYI-Dateien.

Die Datenbanken vom Typ MyIsam müsste man einfach durch wegkopieren an einen
sicheren Ort und nach erneuter Installation von mysql/mariadb durch
zurückkopieren wiederherstellen können.

Ich würde jetzt zunächst sowieso den ganzen /var/lib/mysql-Ordner an einen
sicheren Platz kopieren.

Problematisch wären InnoDB-Datenbanken, wenn ibdata1 wirklich kaputt ist.

> ich darf auf keinen Fall die Datenbanken verlieren.

Deswegen keine Schnellschüsse sondern in Ruhe die Situation analysieren.

Hast Du Backups?

Nutzt Du die Backup-Funktion des mysql-Paketes?

Die Backups liegen unter /var/lib/mysql_backup.

Von wann sind die?

Problem: Wenn Du in den Backup-Einstellungen in der mysql-Konfiguration den
Parameter FORCE auf no stehen hast, könnten die Backups für den Typ InnoDB
veraltet sein, da die Erkennung von Datenbankänderungen nicht funktioniert
und daher ein Backup nicht angestossen wurde.

Bei MyIsam funktioniert das problemlos.

Also poste mal die Infos zu den von mir gestellten Fragen.

-- 
Gruss Marcus