Wir sind jetzt schon mehrmals auf ein Szenario gestoßen, bei dem unsere MySQL-Datenbank beschädigt wurde, wenn wir versuchten, eine mysqldump-Datei wiederherzustellen. Wir haben dieselben Verfahren (über Batch-Skripte) mehrere Jahre lang ohne Probleme verwendet und sind erst seit kurzem in den letzten Monaten auf das Problem gestoßen.
Wir verwenden MySQL Server Version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu 16.04.2 LTS) und stellen zwei MyISAM-Tabellen mit ~350.000 Datensätzen (zusammen) wieder her.
Wir verwenden das folgende Befehlsskript, um die Tabellen von unserem internen Server zu sichern und auf dem Remote-Datenbankserver wiederherzustellen:
"%mysql_path%\mysqldump.exe" --user=root --password="%PWD%" --host=%source% ourdbname --tables table1 table2 | "%mysql_path%\mysql.exe" -uroot --password="%PWD%" --host=%dbtarget% -C ourdbname
Wobei die %%Variablen als Teil des größeren Batch-Skripts bereitgestellt werden. Im Grunde leiten wir die Ausgabe des Dumps an mysql.exe weiter, um sie auf dem Remote-Server wiederherzustellen. Das Skript wird auf einem Windows 10-Computer ausgeführt, aber sowohl die Quell- als auch die Zieldatenbank befinden sich unter Linux.
Beim Wiederherstellen wird die Datenbank beschädigt, was dazu führt, dass die CPU-Auslastung des DB-Servers auf 100 % pro Kern ansteigt. Die einzige Möglichkeit, dieses Problem zu beheben, besteht unserer Meinung nach darin, den MySQL-Prozess zu beenden, die .frm, .MYD, .MYIDateien zu löschen, dann MySQL zu starten und die Tabellen lokal wiederherzustellen (die MySQL-Dump-Datei per SCP auf den Server zu übertragen und wiederherzustellen).
Wir haben festgestellt, dass die Datenbank nur dann beschädigt wird, wenn wir aktiven Verkehr auf der Website haben. Wir könnten also die Site herunterfahren (separater Server, auf dem Java ausgeführt wird und der über JDBC verbunden ist), das Skript ausführen und die Site dann wieder online bringen, und sie funktioniert zu 100 % der Zeit. Natürlich ist das nicht ideal, aber es ist die einzige Möglichkeit, die wir derzeit haben.
Irgendwelche Ideen, was die Ursache sein könnte? Vorschläge, wie man das Problem umgehen kann, ohne den Front-End-Server herunterfahren zu müssen?
Antwort1
Es scheint, dass Sie MyISAM als Datenbankmodul für Ihre Site verwenden. Ich empfehle die Verwendung von InnoDB, es ist in vielerlei Hinsicht besser.
Das Hauptproblem hierbei ist jedoch, dass Ihre Webanwendung höchstwahrscheinlich gleichzeitig mit Ihrem Backup in die Datenbank schreibt. Abhängig vom tatsächlichen Tabellenschema kann dies alle möglichen negativen Auswirkungen haben. Die Verwendung von MyISAM führt nur dazu, dass es funktioniert, da es in MyISAM, wenn ich mich recht erinnere, keine Sperre auf Zeilenebene gibt.
Die Verwendung von InnoDB könnte hier helfen, aber vielleicht auch nicht. Die einzige sichere Option könnte darin bestehen, den Front-End-Server einfach zu stoppen. Eine andere Möglichkeit besteht darin, eine API für die Remote-Anwendung zu erstellen, die die eingehenden Daten sicher in die Datenbank schreibt.