DNS Probleme nach Stromausfall

robbie.rob

robbie.rob

Aktives Mitglied
Thread Starter
Dabei seit
01.09.2007
Beiträge
223
Reaktionspunkte
9
Liebe Mac-Freunde,

ich habe mit meinem OSX Mavericks Server große DNS Probleme seit einem Stromausfall. Der DNS Server löst die IP-Adressen nicht mehr auf bzw. leitet nicht mehr an den Router weiter. DNS Dienst aus- und einschalten sowie DNS Cache flushen bringt keine Besserung. Irgendwo hat sich ordentlich was zerschossen...

Was ist der beste Weg, um das System wieder in Gang zu setzen? Bitte keine Neu-Installation oder Ähnliches.

LG Robert
 
Was ist der beste Weg, um das System wieder in Gang zu setzen? Bitte keine Neu-Installation oder Ähnliches.
Zum Vergrößern anklicken....

Da wirst du aber nicht drum rum kommen, Dein backup auspacken und einspielen via Time Machine
 
Keine andere Idee???
 
Backup einspielen. Oder hast du Angst davor? :)
 
Backup? Ich würde erst einmal vorschlagen die Logs zu lesen. Oder glaubt Ihr die gibt es nur zum Spass?
 
Es ist seeeeehr merkwürdig: Sowie sich der Mavericks Server im lokalen Netzwerk befinden, ist die Internet-Kommunikation gestört - obwohl ich DCHP und DNS am Server deaktiviert habe. Die Protokolle geben nichts her.

Also doch den "no brain"-Weg und 2 TB Backup über das Netzwerk einspielen... *seufz* Mal gucken, ob es bis morgen früh damit fertig ist...

LG Robert
 
So - Backup eingespielt... ein Trauerspiel. Internet ist schnell und stabil. ABER: MySQL Server startet nicht mehr. Und der Server ist nicht mehr von außen erreichbar.
Beim Neu-Start des Servers wurden die Server-Dienste "aktualisiert". Nur scheinbar wurde dabei noch mehr Unheil angerichtet.. *seufz* Server per Backup wiederherstellen funktioniert nicht so ohne Weiteres... so scheint es.
Jemand einen Tipp? Im Moment gibt es kein E-Mail, keine Datenbank...

LG Robert
 
Wie schon gesagt wurde helfen die Logs da weiter. Ist so eine Sache mit der Glaskugel hier herauszufinden, warum was nicht läuft. Im Gegensatz zu Windows bietet Unix da oft eine aussagekräftigere Meldung als nur: "Ein unerwarteter Fehler ist ausgetreten" ;)
 
Ping etc. geht. Mailserver läuft jetzt auch. Aber Wordpress meldet "Fehler beim Aufbau einer Datenbankverbindung". Der MySQL Server läuft wieder.
Welche Logfiles möchtest Du haben?
 
Kommando zurück. MySQL Server hat sich wieder verabschiedet.

2014-09-04 16:26:37 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
2014-09-04 16:26:38 0 Warning The syntax 'pre-4.1 password hash' is deprecated and will be removed in a future release. Please use post-4.1 password hash instead.
2014-09-04 16:26:38 0 Warning TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-09-04 16:26:38 2449 Warning Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
2014-09-04 16:26:38 2449 Note Plugin 'FEDERATED' is disabled.
2014-09-04 16:26:38 2449 Note InnoDB: The InnoDB memory heap is disabled
2014-09-04 16:26:38 2449 Note InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-09-04 16:26:38 2449 Note InnoDB: Compressed tables use zlib 1.2.3
2014-09-04 16:26:38 2449 Note InnoDB: Using CPU crc32 instructions
2014-09-04 16:26:38 2449 Note InnoDB: Initializing buffer pool, size = 128.0M
2014-09-04 16:26:38 2449 Note InnoDB: Completed initialization of buffer pool
2014-09-04 16:26:38 2449 Note InnoDB: Highest supported file format is Barracuda.
2014-09-04 16:26:38 2449 Note InnoDB: 128 rollback segment(s) are active.
2014-09-04 16:26:38 2449 Note InnoDB: Waiting for purge to start
InnoDB: Error: tablespace id is 315 in the data dictionary
InnoDB: but in file ./wordpress/wp_posts.ibd it is 419!
2014-09-04 16:26:38 1296a7000 InnoDB: Assertion failure in thread 4989808640 in file fil0fil.cc line 794
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:26:38 UTC - 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.
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.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68218 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x40000
0 mysqld 0x0000000104fb77d6 my_print_stacktrace + 61
1 mysqld 0x0000000104e132a0 handle_fatal_signal + 705
2 libsystem_platform.dylib 0x00007fff8c4ad5aa _sigtramp + 26
3 ??? 0x747265737341203a 0x0 + 8390880602273947706
4 libsystem_c.dylib 0x00007fff86cbfb1a abort + 125
5 mysqld 0x000000010502ce9f _ZL18fil_node_open_fileP10fil_node_tP12fil_system_tP11fil_space_t + 1886
6 mysqld 0x0000000105034655 _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 116
7 mysqld 0x0000000105034e5e _Z6fil_iombmmmmmPvS_ + 679
8 mysqld 0x000000010500ab35 _ZL17buf_read_page_lowP7dberr_tbmmmmxm + 427
9 mysqld 0x000000010500af13 _Z13buf_read_pagemmm + 69
10 mysqld 0x0000000104ff7dc3 _Z16buf_page_get_genmmmmP11buf_block_tmPKcmP5mtr_t + 2773
11 mysqld 0x0000000104fe4db7 _Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_tmmP9btr_cur_tmPKcmP5mtr_t + 2671
12 mysqld 0x00000001050e3807 _Z22row_search_index_entryP12dict_index_tPK8dtuple_tmP10btr_pcur_tP5mtr_t + 140
13 mysqld 0x00000001050e1b13 _ZL28row_purge_remove_sec_if_possP12purge_node_tP12dict_index_tPK8dtuple_t + 377
14 mysqld 0x00000001050e10a1 _Z14row_purge_stepP9que_thr_t + 786
15 mysqld 0x00000001050bb285 _Z15que_run_threadsP9que_thr_t + 1401
16 mysqld 0x00000001051049ed _Z9trx_purgemmb + 2793
17 mysqld 0x00000001050fa054 srv_purge_coordinator_thread + 2156
18 libsystem_pthread.dylib 0x00007fff87e49899 _pthread_body + 138
19 libsystem_pthread.dylib 0x00007fff87e4972a _pthread_struct_init + 0
20 libsystem_pthread.dylib 0x00007fff87e4dfc9 thread_start + 13
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.
 
Dir hat's wohl die Datenbank zerissen -> 2. Link lesen und nach Backup der Datenbank befolgen.
 
Schon getan. Leider ohne Erfolg. Auch nicht mit "älteren" Backups der letzten 48 Stunden. Nun installiere ich den MySQL Server neu und versuche eine Migration der Daten aus dem Backup.
 
Ich denke den mysql neu zu installieren, braucht's nicht, eher die config checken.

Zieh' einfach richtig alte Daten aus dem Backup und schau ob's wieder läuft und dann immer weiter nach vorne.
 
Ich werde hier bald irre...

- index.html aus dem Internet erreichbar? ja
- phpinfo.php aus dem Internet erreichbar? ja
- jungfräulicher MySQL Server läuft? ja

ABER:
- jungfräuliche WP Installation? ja, aber keine Verbindung zum localhost bzw. zur MySQL Datenbank möglich

Wahrscheinlich sehe ich den Wald vor Bäumen nicht...
 
Jetzt probiere ich es mit einem ganz alten Backup... ich habe keinen Schimmer, wo der Wurm drin ist.
Warum läuft das Backup (direkt vor dem Stromausfall) nicht? Der Server tat doch einwandfrei... Und warum bekomme ich keine Verbindung zum MySQL Server?

Kann das ein DNS Problem sein?
 
Eigentlich nicht, wenn der mysql über socket angesprochen wird.

Du weisst aber mittlerweile, dass man dir besser helfen könnte, wenn du logfiles posten würdest.
 
Gern - welche log Files hättest Du denn gern?

/usr/local/mysql/bin/mysql Ver 14.14 Distrib 5.6.13, for osx10.7 (x86_64) using EditLine wrapper

Connection id: 121
Current database:
Current user: Administrator@localhost
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.6.13 MySQL Community Server (GPL)
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /tmp/mysql.sock
Uptime: 1 hour 3 min 39 sec

Threads: 5 Questions: 2980 Slow queries: 0 Opens: 90 Flush tables: 1 Open tables: 83 Queries per second avg: 0.780


UND:


(...)
Timestamp, Thread, Type, Details
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_options" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_options" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_options" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_users" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_usermeta" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_posts" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_comments" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_links" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_options" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_postmeta" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
, , , 2014-09-04 21:36:29 1379ae000 InnoDB: cannot calculate statistics for table "wordpress"."wp_terms" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
(...)

LG Robert
 
Ich glaube, ich kann das Problem weiter eingrenzen. APC und Memcache scheinen die Ursache zu sein. Das Backup der MySQL Datenbank und der Cache passen evtl. nicht zusammen, da der Cache nicht im TM-Backup enthalten ist - so scheint es.
 
Hm, der APC dürfte weniger das Problem sein.
Wozu und wie verwendest du memcached?
Und warum gibt es kein dazu passendes Backup?
 
Zurück
Oben Unten