[Eisfair] Mariadb Probleme nach Klonen oder Kopieren

Dirk Alberti Howy-1 at gmx.de
Sa Dez 17 15:29:23 CET 2016


Hallo zusammen,

nach einigen Kämpfen läuft der RAID-Verbund nun wohl, aber bei den 
Vorarbeiten ist ein weiteres Problem aufgetaucht, diemal mit Mariadb.

Um das laufende System auf der Einzelplatte nicht zu gefährden, habe ich 
diese auf eine andere, gleichgroße geklont. Lief zwar dann, aber Mariadb 
startete nicht.
Anderer Versuch, mit den aus der RAID-Anleitung entnommenen Befehlen die 
Platten komplett identisch eingerichtet und alles rüberkopiert, danach 
mit lilo startfähig gemacht. System läuft, aber Mariadb startet wieder 
nicht.

Im Log einige dieser Einträge:

161217 14:27:10  InnoDB: Error: page 25618 log sequence number 414197700
InnoDB: is in the future! Current system log sequence number 414196800.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.


Zusätzlich dann noch dieser:


161217 14:33:28 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 5.5.53-MariaDB
key_buffer_size=268435456
read_buffer_size=1048576
max_used_connections=0
max_threads=302
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 
883970 K  bytes
of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x80000
/usr/bin/mysqld(my_print_stacktrace+0x29)[0xb6a742b9]
/usr/bin/mysqld(handle_fatal_signal+0x4ba)[0xb66b18aa]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb6eb9404]
/lib/libc.so.6(gsignal+0x3d)[0xb5d8e9dd]
/lib/libc.so.6(abort+0x14e)[0xb5d9007e]
/usr/bin/mysqld(+0x602117)[0xb693f117]
/usr/bin/mysqld(+0x60259a)[0xb693f59a]
/usr/bin/mysqld(+0x6ffa33)[0xb6a3ca33]
/usr/bin/mysqld(+0x6f4c68)[0xb6a31c68]
/usr/bin/mysqld(+0x603a0d)[0xb6940a0d]
/usr/bin/mysqld(+0x5f7a7e)[0xb6934a7e]
/lib/libpthread.so.0(+0x6bc7)[0xb6283bc7]
/lib/libc.so.6(clone+0x5e)[0xb5e3b4ae]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.


Nach einigen Recherchen im Internet bin ich auf diese Seite gestoßen [1] 
Dann habe ich nochmal die ursprüngliche Platte gestartet, von den 
Datenbanken einen kompletten Dump erstellt (auf meine Backup-Platte, als 
/Backup gemountet):

mysqldump -A > /Backup/all_your_bases.sql

Das dauerte eine ganze Weile ;-)

Danach wieder die Klon- bzw. Kopie-Platten dran, aber wenn Mariadb nicht 
startet, kann man auch den Dump nicht zurückspielen. Also weiter nach 
der Anleitung vorgegangen, und die Ordner der Datenbanken und die 
Einzelfiles in /var/lib/mysql gelöscht.
Mariadb konnte danach wieder im Setup gestartet werden.
Somit habe ich dann mit 'mysql < /Backup/all_your_bases.sql' alles 
wiederhergestellt und Mariadb läuft wieder komplett.


Ist das normal, dass es beim einfachen klonen oder kopieren der 
Mariadb-Daten Probleme gibt?
Wenn ja, müsste vielleicht irgendwo mit vermerkt werden, dass man es 
besser mit einem Dump macht.


Grüße Dirk


[1] 
https://www.linet-services.de/was-tun-wenns-brennt-innodb-corruption-und-recovery/



Mehr Informationen über die Mailingliste Eisfair