MySql-Server startet nach virtualisierung nicht

Hallo,

Da wir bald neue Server bekommen müssen unsere jetzigen Server umgezogen werden. Wir haben unseren Webserver auf Debian 4.0 laufen, welcher nun mit ESXI Virtualisiert werden soll und danach geupdated. Ich habe nun mit dem Programm VMware vCenter Converter das laufende System auf einen ESXI-Host kopiert und die Netzwerkkonfiguration der VM angepasst (sonst keine Änderungen vorgenommen).

Nun mein Problem:
Der MySql Server startet nicht. Ich bekommen im syslog beim Ausführen von /etc/init.d/mysql start folgende Meldungen:

Feb 5 13:05:59 labskaus_test mysqld_safe[2819]: started
Feb 5 13:05:59 labskaus_test mysqld[2826]: 130205 13:05:59 InnoDB: Database was not shut down normally!
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Starting crash recovery.
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Reading tablespace information from the .ibd files...
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Restoring possible half-written data pages from the doublewrite
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: buffer...
Feb 5 13:05:59 labskaus_test mysqld[2826]: 130205 13:05:59 InnoDB: Starting log scan based on checkpoint at
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: log sequence number 23 3046575611.
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Doing recovery: scanned up to log sequence number 23 3046575971
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Transaction 0 90347829 was in the XA prepared state.
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: 1 transaction(s) which must be rolled back or cleaned up
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: in total 0 row operations to undo
Feb 5 13:05:59 labskaus_test mysqld[2826]: InnoDB: Trx id counter is 0 90348288
Feb 5 13:05:59 labskaus_test mysqld[2826]: 130205 13:05:59 InnoDB: Starting an apply batch of log records to the database...
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Progress in percents: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Apply batch completed
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Last MySQL binlog file position 0 2120017, file name /var/log/mysql/mysql-bin.002155
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 InnoDB: Started; log sequence number 23 3046575971
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 [Note] Starting crash recovery...
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 InnoDB: Starting recovery for XA transactions...
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 InnoDB: Transaction 0 90347829 in prepared state after recovery
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 InnoDB: Transaction contains changes to 1 rows
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 InnoDB: 1 transactions in prepared state after recovery
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00 [Note] Found 1 prepared transaction(s) in InnoDB
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Error: trying to access page number 1733654191 in space 0,
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: space name ./ibdata1,
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: which is outside the tablespace bounds.
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: If you get this error at mysqld startup, please check that
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: your my.cnf matches the ibdata files that you have in the
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: MySQL server.
Feb 5 13:06:00 labskaus_test mysqld[2826]: 130205 13:06:00InnoDB: Assertion failure in thread 47360118068848 in file fil0fil.c line 3959
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: We intentionally generate a memory trap.
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: If you get repeated assertion failures or crashes, even
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: immediately after the mysqld startup, there may be
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Feb 5 13:06:00 labskaus_test mysqld[2826]: InnoDB: about forcing recovery.
Feb 5 13:06:00 labskaus_test mysqld[2826]: mysqld got signal 11;
Feb 5 13:06:00 labskaus_test mysqld[2826]: This could be because you hit a bug. It is also possible that this binary
Feb 5 13:06:00 labskaus_test mysqld[2826]: or one of the libraries it was linked against is corrupt, improperly built,
Feb 5 13:06:00 labskaus_test mysqld[2826]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 5 13:06:00 labskaus_test mysqld[2826]: We will try our best to scrape up some info that will hopefully help diagnose
Feb 5 13:06:00 labskaus_test mysqld[2826]: the problem, but since we have already crashed, something is definitely wrong
Feb 5 13:06:00 labskaus_test mysqld[2826]: and this may fail.
Feb 5 13:06:00 labskaus_test mysqld[2826]:
Feb 5 13:06:00 labskaus_test mysqld[2826]: key_buffer_size=0
Feb 5 13:06:00 labskaus_test mysqld[2826]: read_buffer_size=131072
Feb 5 13:06:00 labskaus_test mysqld[2826]: max_used_connections=0
Feb 5 13:06:00 labskaus_test mysqld[2826]: max_connections=100
Feb 5 13:06:00 labskaus_test mysqld[2826]: threads_connected=0
Feb 5 13:06:00 labskaus_test mysqld[2826]: It is possible that mysqld could use up to
Feb 5 13:06:00 labskaus_test mysqld[2826]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K
Feb 5 13:06:00 labskaus_test mysqld[2826]: bytes of memory
Feb 5 13:06:00 labskaus_test mysqld[2826]: Hope that's ok; if not, decrease some variables in the equation.
Feb 5 13:06:00 labskaus_test mysqld[2826]:
Feb 5 13:06:00 labskaus_test mysqld[2826]: thd=(nil)
Feb 5 13:06:00 labskaus_test mysqld[2826]: Attempting backtrace. You can use the following information to find out
Feb 5 13:06:00 labskaus_test mysqld[2826]: where mysqld died. If you see no messages after this, something went
Feb 5 13:06:00 labskaus_test mysqld[2826]: terribly wrong...
Feb 5 13:06:00 labskaus_test mysqld[2826]: frame pointer is NULL, did you compile with
Feb 5 13:06:00 labskaus_test mysqld[2826]: -fomit-frame-pointer? Aborting backtrace!
Feb 5 13:06:00 labskaus_test mysqld[2826]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Feb 5 13:06:00 labskaus_test mysqld[2826]: information that should help you find out what is causing the crash.
Feb 5 13:06:00 labskaus_test mysqld_safe[2832]: ended
Feb 5 13:06:13 labskaus_test /etc/init.d/mysql[2967]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Feb 5 13:06:13 labskaus_test /etc/init.d/mysql[2967]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Feb 5 13:06:13 labskaus_test /etc/init.d/mysql[2967]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Feb 5 13:06:13 labskaus_test /etc/init.d/mysql[2967]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Feb 5 13:06:13 labskaus_test /etc/init.d/mysql[2967]:


MySql Version:
labskaus_test:~# dpkg -l mysql-server
Gew�nscht=Unbekannt/Installieren/R=Entfernen/P=S�ubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: GROSS=schlecht)
||/ Name Version Beschreibung
+++-=====================================================-=====================================================-==========================================================================================================================
ii mysql-server 5.0.32-7etch5 mysql database server (meta package depending on the latest version)


Ich vermute das bei dem erstellen der VM Fehler in der Datenbank aufgetreten sind und sich diese nun in einem inkonsistenten zustand befindet.

Ich bitte um hilfe und danke schonmal im Vorraus

 

Das würde ich nun auch vermuten. Aus dem Bauch heraus würde ich empfehlen, komplexe Dinge wie laufende Datenbanken VOR der Migration zu beenden. Das hast Du offenbar nicht getan. Läuft die DB auf dem Ursprungssystem noch?


Andreas

 

Auch mein erster Gedanke. Das original System sollte ja noch unangetastet vorhanden sein. Einfach alle DB Dienste beenden und dann die Konvertierung nochmal starten.

 

Danke für die schnellen Antworten.

Ich kläre es dann jetzt noch ab, dass ich heute nacht die Datenbank runterfahren kann. Im Betrieb ist das ein wenig ungünstig.

Gruß Tim

 

Es hat ein wenig gedauert bis ich das abgeklärt hab.
Das abschalten des Dienstes hat funktioniert. Er hat die Maschine konvertiert und die Datenbank läuft.