[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