MySQL5.6 unter Windows SBS2011: Datenbank Crash- was nun?

E

Eismann

Benutzer
Beiträge
14
Hallo zusammen,
bin neu im Forum hier und werde demnächst bestimmt auch was positives hier beitragen. :)

Bei mir brennt gerade die Luft .... aber alles der Reihe nach:

Wir haben auf einem Windows 2011-Small Business –Server eine MySQL5.6-Instanz installiert, auf der 2 wichtige Datenbanken laufen.

Am 22.09.2016 gegen 16:30 gab es einen Stromausfall für ca 1 Sekunde. Der Server war an eine USV angeschlossen und machte einen Neustart. Der MySQL 5.6-Server aber ist via ODBC nicht mehr erreichbar. Ein Neustart des Mysql5.6 Dienstes hat nicht weitergeholfen. Mit Heidi-SQL komme ich also auch nicht mehr rein.
Die Protokoll-Dateien und die Datendateien des Servers konnte ich lokalisieren. Zugangsdaten von root, sqlbackup und von den ODBC-Konten sind mir bekannt.
Wie kann man einen „Desaster recovery“ durchführen?

Mein Problem ist jetzt vorallem, das ich mich mit den SQL-Konsolen und mit mysqldump nicht auskenne. Aber grundsätzlich bin nicht allergisch gegen Kommandozeilen.
Es gibt einen SQL-Dump vom Vortag 22:45.


Es wäre super, wenn mir jemand bei diesem Problem helfen könnte.
Grüße aus Köln
Eismann
 
Werbung:
Um einen Dump einzuspielen machst Du dies: mysql < dump.sql

Für die Zukunft solltest Du die Regel Dir merken: wer wichtige Daten hat, verwendet kein MySQL. Zumindest nicht zum zweiten Mal.
 
Hast du in den Logs geschaut ob der MySql Server ordnungsgemäß hochgefahren ist?
Das klingt eher danach das der Dienst nicht richtig läuft als das die Daten nicht da sind.
 
Dukel schrieb:
Hast du in den Logs geschaut ob der MySql Server ordnungsgemäß hochgefahren ist?
Das klingt eher danach das der Dienst nicht richtig läuft als das die Daten nicht da sind.
Zum Vergrößern anklicken....

Ich vermute eher, daß die Daten korrupt sind. Wenn sich InnoDB zerbröselt dann wird es halt knifflig. Mir fällt auch grad ein: das Einspielen des Dumps geht dann auch nicht so trivial, da wirst eher das System neu aufsetzen müssen (vorher vielleicht aber wegsichern ...) nd dann bei Punkt 0 anfangen.
 
das hier habe ich gestern abend in Chepri.com gefunden:
Steps to get it back up.

1. Stop mysqld.
2. Backup /var/lib/mysql/ib*
3. Add the following line into /etc/my.cnf

innodb_force_recovery=4

4. Restart mysqld.
5. Dump all tables:# mysqldump -A > dump.sql
6. Drop all databases which need recovery.
7. Stop mysqld.
8. Remove /var/lib/mysql/ib*
9. Comment out innodb_force_recovery in /etc/my.cnf
10. Restart mysqld. Look at mysql error log. By default it should be /var/lib/mysql/server/hostname.com.err to see how it creates new ib* files.
11. Restore databases from the dump:mysql < dump.sql

**Hint : A simple query for finding all of your InnoDB tables in case you want to specifically target the corruption.

SELECT table_schema,table_nameFROM INFORMATION_SCHEMA.TABLESWHERE engine='innodb';
Zum Vergrößern anklicken....

Wenn ich das nun auf Deutsch und Windows übersetze, dann sehe ich das zunächst mal so:
1. Den Dienst bzw über notifier den server stoppen.

2. in c:\ProgramData\MySQL Server 5.6\ die ib*.dateien sichern.

3. in c:\ProgramData\MySQL Server 5.6\my.cnf die folgende Zeile anfügen.
innodb_force_recovery=4
4. Den Dienst bzw über notifier den server starten.

Wenn das nicht funktioniert, dann neuinstallieren.... wie von akretschmer vorgeschlagen.

5. Dump all tables:# mysqldump -A > dump.sql // hier brauche ich Unterstützung, denn da muss wohl ein Login mit hinein, und ich würde das lieber remote mit der Kommandozeiele des Win-7-PCs durchführen.

6. Drop all databases .

7. Den Dienst bzw über notifier den server stoppen.

8. in c:\ProgramData\MySQL Server 5.6\ die ib*.dateien löschen.

9. in c:\ProgramData\MySQL Server 5.6\my.cnf die folgende Zeile auskommentieren.
innodb_force_recovery=4

10. Den Dienst bzw über notifier den Server starten.

11. die Erstellung der neuen IB-Log-Files im MySQL errorlog beobachten. Das geht natürlich nur unter linux fließend. In Windows müsste man wohl abwarten , bis sich das Errorlog nicht vergrößert. Und dann mit Notepad öffnen. Frage: wo liegen die Errorlog's?

12. zurückspielen des dumps: mysql < dump.sql

13. testen:

SELECT table_schema,table_nameFROM INFORMATION_SCHEMA.TABLESWHERE engine='innodb';
Zum Vergrößern anklicken....
 
Hallo,
da inzwischen viele Versuche daneben gingen, habe ich nun mySQL 5.7 installiert. Und über Workbench Dumps zurückgespielt.


Die lokal zugreifende Workbench zeigt alles an. OK


Nun habe ich noch einen ganz anderen Fehler: Das DBMS lässt sich nur lokal ansprechen.

In der my.cnf steht
# skip-networking
bind-address = 0.0.0.0

auf dem Server sieht netstat so aus:

C:\Users\bksadmin>netstat -p tcp -a |find /N "3306"
[24] TCP 0.0.0.0:3306 SBS-2011:0 ABHÖREN

eine odbc-Verbindung auf dem Client geht nicht

Was kann ich jetzt noch tun?
 
ja.. es ist eh schon ms-sql auf der Mühle. Eine neue Instanz aufmachen, und dann mssql- cals bezahlen. 10 user x 6 Kerne x ca 14dollar . Müsste ich mal drüber nachdenken.

oder was meinst Du mit richtiger DB?

Gruß Eismann
 
aber das letzte Problem betrifft wahrscheinlich nicht mysql, sondern die freigabe von Ports.

auf dem Server gebe ich also 3306 frei. Müsste ich auf den Clients ebenfalls machen. ist nur kurios, das es vor dem crash alles lief. wie so ist auf einmal der Port gesperrt?
 
Gibt es den irgendwo Infos zum Administrieren? User, Netzwerk, Backup, Export, Import....

Würde ich zunächst mal unter Windows 7 reizen. Aber ich könnte auch einen dedizierten ubuntu-Server aufbauen.
Gruß Eismann
 
Werbung:
Danke, akretschmer, werde ich mir nach der Stressphase auf jeden Fall ansehen.

ein Zwischenstand:
damit die Schule, für die ich das "nebenbei" mache, nicht zu nervös wird, habe ich einen kurzfristig anderen Weg eingeschlagen. Die eine DB hat mir netterweise der Support des Programmgherstellers in eine Access-Datei konvertiert. Und der ODBC-Zugriff läuft jetzt. Ist nicht optimal , aber man kann mit 2-3 Mann arbeiten.
Wie gesagt Access-Format ist eine Zwischenlösung und gibt mir Zeit für eine neue gute Lösung zu konfigurieren.

Die 2. DB muss ich mit Anleitung selbst konvertieren. Dazu habe ich den Ärger mit dem produktiv arbeitenden 64-Bit-Server und eventuelle Netzwerkeinstellungen umgangen und mir eine 32-bit-Win7-Maschine eingerichtet, auf der alles als localhost läuft.. Jetzt läuft dort ein mySQL5.6 ( mit 5.7 hatte ich irgendwie Ärger beim konfigurierten während des Setups.- Waren wohl gleichzeitig ein paar Win-Updates unterwegs..... ätzend)
Der SQL-Dump ist auch schon eingespielt. Der User für den ODBC-Zugriff ist auch ok. Er arbeitet auch mit der richtigen My.ini ( poste ich gleich auch mal hier hinein.)
- Hier zu ein Wichtiger Hinweis: Wer hintereinander verschiedene Versionen von MYSQL installiert, bekommt Ärger mit verschiedenen my.ini's ! Eine Connection in Workbench wollte auf die 5.7-Version im anderen order zugreifen... Man kann das aber als root bei User - Systemprofile- alles korrigieren und dafür sorgen, das alle User mit der gleichen my.ini arbeiten. -
Das Migrationstool des Herstellers arbeitet mit UDL-Dateien. Eine für die Quelle ( = die ODBC-DSN des mySQL mit dem dafür erstellten User) und im Ziel ebenfalls mit einer UDL , die mit JET auf die Access-mdb-Datei zugreift.
Und nun passiert folgendes:
- ODBC-Test mit der DSN Verbindung: ok
- UDL-Datei mit der ODBC-Quelle : ok
- UDL-Test mit der Access-Quelle : ok

- Immerhin macht das Programm am Anfang eine Verbindungstest. Verbindungstest im Migrationstool :FAIL. Sieht so aus, als wäre das wieder eine MYSQL-Typische Meldung. Wenn ich gleich am richtigen PC sitze, poste ich mal einen Screenshot.

Gruß Eismann
 
Zurück
Oben