travelmearound
Goto Top

MySQL läuft nach RAM-Upgrade nicht mehr (Xampp)

Guten Tag,

wir haben eine Joomla Installation über Xampp realisiert. Die entsprechende Domain zeigt auf unseren Server der über HyperV virtualisiert ist. Nach einem RAM-Update vergangene Nacht startet scheinbar der SQL-Server nicht mehr ordnungsgemäß. Ich habe das System nicht aufgesetzt, der damalige Entwickler ist nicht mehr greifbar.
Xampp liefert mir folgende Fehlermeldungen...

2017-09-04 09:52:40 12200 [Note] Plugin 'FEDERATED' is disabled.  
2017-09-04 09:52:40 3a30 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.  
2017-09-04 09:52:40 12200 [Note] InnoDB: Using atomics to ref count buffer pool pages
2017-09-04 09:52:40 12200 [Note] InnoDB: The InnoDB memory heap is disabled
2017-09-04 09:52:40 12200 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2017-09-04 09:52:40 12200 [Note] InnoDB: Memory barrier is not used
2017-09-04 09:52:40 12200 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-09-04 09:52:40 12200 [Note] InnoDB: Not using CPU crc32 instructions
2017-09-04 09:52:40 12200 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2017-09-04 09:52:40 12200 [Note] InnoDB: Completed initialization of buffer pool
2017-09-04 09:52:40 12200 [Note] InnoDB: Highest supported file format is Barracuda.
2017-09-04 09:52:40 12200 [Note] InnoDB: The log sequence numbers 6146261284 and 6146261284 in ibdata files do not match the log sequence number 6146264507 in the ib_logfiles!
2017-09-04 09:52:40 12200 [Note] InnoDB: Database was not shutdown normally!
2017-09-04 09:52:40 12200 [Note] InnoDB: Starting crash recovery.
2017-09-04 09:52:40 12200 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-09-04 09:52:40 12200 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace .../joomla_jevents_vevdetail uses space ID: 2 at filepath: .\...\joomla_jevents_vevdetail.ibd. Cannot open tablespace mysql/innodb_index_stats which uses space ID: 2 at filepath: .\mysql\innodb_index_stats.ibd
InnoDB: Error: could not open single-table tablespace file .\mysql\innodb_index_stats.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

Kann mir hier jemand sagen, was passiert ist? Kann es mit der Erweiterung des RAM zu tun haben? Dynamischer RAM ist bei dem Server nicht aktiviert.

Herzlichen Dank,
travelmearound

Content-Key: 348099

Url: https://administrator.de/contentid/348099

Ausgedruckt am: 28.03.2024 um 08:03 Uhr

Mitglied: maretz
maretz 04.09.2017 um 10:04:49 Uhr
Goto Top
Moin

bei aller liebe, aber da steht doch nu wirklich genau was los ist:
- letzter Shutdown war nicht sauber gelaufen
- dabei hat es dir ne Tabelle zerlegt
- die DB startet nicht da die nicht mehr schaden machen will...

Und sogar was du jetzt (nach einem Backup natürlich) probieren kannst steht da...
Mitglied: 117471
Lösung 117471 04.09.2017 aktualisiert um 10:44:29 Uhr
Goto Top
Hallo,

da steht es doch:

Database was not shutdown normally!

Die Datenbank wurde nicht sauber heruntergefahren...

InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mroptik/joomla_jevents_vevdetail uses space ID: 2 at filepath: .\mroptik\joomla_jevents_vevdetail.ibd. Cannot open tablespace mysql/innodb_index_stats which uses space ID: 2 at filepath: .\mysql\innodb_index_stats.ibd

...und ist dabei offenbar beschädigt worden, so dass sie nicht mehr sauber gestartet werden kann.

Unter http://bfy.tw/DjTU findest Du einige Beiträge, in denen Teilnehmer beschreiben, wie sie ihre zerschossenen Datenbanken wieder reanimieren konnten. Ich persönlich würde:

a) ein Backup der defekten Datenbank anlegen
b) das vorherige Backup einspielen
c) nur wenn das nicht hilft, ausgehend von den in a) gesicherten Daten die Tipps aus den o.g. Suchergebnissen durchspielen

Gruß,
Jörg
Mitglied: Penny.Cilin
Penny.Cilin 04.09.2017 um 10:34:57 Uhr
Goto Top
Zitat von @117471:

Unter http://bfy.tw/DjTU findest Du einige Beiträge, in denen Teilnehmer beschreiben, wie sie ihre zerschossenen Datenbanken wieder reanimieren konnten. Ich persönlich würde:
@fa-jka:
Poste bitte die direkten Links, meinetwegen auch lmgtfy. Oder hast Du Dich vertippt? - Dann korrigiere es bitte.

Gruß,
Jörg


Gruss Penny
Mitglied: travelmearound
travelmearound 04.09.2017 um 10:43:10 Uhr
Goto Top
Wir haben eine Veeam Sicherung des Xampp-Ordners. Sollte es funktionieren, wenn wir diesen komplett ersetzen über die Replication?
Mitglied: 117471
117471 04.09.2017 um 10:52:24 Uhr
Goto Top
Hallo,

Zitat von @Penny.Cilin:

Poste bitte die direkten Links, meinetwegen auch lmgtfy. Oder hast Du Dich vertippt?

Nein, ich habe bewusst diesen Link gepostet, weil ich es ehrlich gesagt etwas frustrierend finde, wenn jemand 10 Minuten einen Beitrag zu einer Frage verfasst, die er sich in 30 Sekunden mit rudimentären Englischkenntnissen selber beantworten kann.

Ich hätte natürlich auch gleich: "Guck' doch bitte bei Google" schreiben können face-smile

Im Übrigen stellt sich die Frage, ob wir derartige Themen überhaupt aufgreifen sollten.

Es handelt sich hierbei um den ersten Beitrag des Verfassers, und dann gleich so ein Kracher: Der Datenbankadministrator ist "weg" (warum auch immer) und der Server wurde anschließend in grenzenlosem Pragmatismus an die Wand gefahren. Jetzt meldet sich jemand (=derjenige, der das Ding an die Wand gefahren hat?) mit der Erwartungshaltung, dass wir Ihn "mal eben" kostenlos ausbilden. Aktuell scheint ja nicht einmal die Bereitschaft vorhanden zu sein, die via Cut & Paste ins Forum kopierten Meldungen vorher zu lesen.

Zum Einen entspricht das meiner Meinung nach nicht unserem "Communitygedanken", zum Anderen frage ich mich, ob die Hilfe wirklich konstruktiv ist und nicht letztendlich dazu beiträgt, dass sich jemand noch tiefer in die Nesseln setzt.

Ich bleibe dabei:
a) ein Backup der defekten Datenbank anlegen
b) das vorherige Backup einspielen
c) nur wenn das nicht hilft, ausgehend von den in a) gesicherten Daten die Tipps aus den o.g. Suchergebnissen durchspielen

Und ergänze ggf. noch:

d) Jemanden fragen, der sich damit auskennt

Gruß,
Jörg
Mitglied: 117471
Lösung 117471 04.09.2017 um 11:00:48 Uhr
Goto Top
Hallo,

Zitat von @travelmearound:

Wir haben eine Veeam Sicherung des Xampp-Ordners. Sollte es funktionieren, wenn wir diesen komplett ersetzen über die Replication?

Das mit dem Backup ist sehr hilfreich.

In dem Fall würde ich zuerst einmal gucken, wo die Datenbank im Dateisystem liegt. Diesen Ordner bzw. diese Ordner benennst Du um. Anschließend holst Du genau diese Ordner (und nur die) aus dem Backup und stellst sie am originalen Ablageort wieder her.

Danach sollte sich die Datenbank fehlerfrei starten lassen.

Gruß,
Jörg
Mitglied: Penny.Cilin
Penny.Cilin 04.09.2017 um 11:44:56 Uhr
Goto Top
Ich habe grade gesehen das es sich um einen lmgtfy link handelt.
Mich hat nur das bfy.tw stutzig bemacht.


Gruss Penny
Mitglied: travelmearound
travelmearound 04.09.2017 um 11:49:55 Uhr
Goto Top
So, nun funktioniert es wieder.

Ich werde mich nicht zu den Umständen hier öffentlich äußern, aus denen heraus dies entstanden ist. Dies war die Lösung:

1) Open my.ini (my.cnf on linux-based systems and Mac)
2) Look for [mysqld]
3) Just below [mysqld] insert innodb_force_recovery = 1
4) Start MySQL Service
5) Stop MySQL Service
6) Remove the line from my.ini (innodb_force_recovery = 1)
7) Start MySQL Service

ich möchte mich an dieser Stelle nochmal bei FA-jka bedanken, der mir hier sehr gut weitergeholfen hat und mit konstruktiven Vorschlägen versuchte, hier zu einer Lösung zu kommen. Vielen Dank dafür.
Mitglied: 117471
117471 04.09.2017 um 12:26:53 Uhr
Goto Top
Hallo,

das freut mich.

Sorry, falls mir da gerade der Kragen geplatzt ist. Aber hier schneien öfter mal Onehit-Wunder rein, die etwas kaputtgespielt haben und "mal eben ganz schnell fix" eine fertige Lösung erwarten - verbunden mit der Erwartungshaltung, dass ihnen nicht nur jegliche Denkarbeit, sondern nach Möglichkeit auch noch jegliche Verantwortung abgenommen wird.

Wenn man Montag gleich als erstes über so einen Beitrag stolpert, kochen gelegentlich auch mal Emotionen hoch face-smile

Freut mich, dass es jetzt wieder läuft face-smile

Gruß,
Jörg