Aktuelle Wiki-Störung <= Backup eingespielt: OK!

[Martin Lemke]

Ich habe leider einen folgenschweren Fehler gemacht.

Ich habe die Checklisten-Komponente geändert, aber vorher ein Backup der falschen Version gemacht, so dass ich kein Backup einspielen kann. Nun ist da einiges verhunzt und ich musste die Komponente abschalten. Es fehlen darum im Moment ein paar Tabellen.

Ich arbeite dran und hoffe, dass ich das im Laufe des Tages wieder hin bekomme.

Martin

[Tobias]

Nun sind alle Artikel betroffen und können nicht mehr aufgerufen werden.

Tobias

[Martin Lemke]

Nun sind alle Artikel betroffen und können nicht mehr aufgerufen werden.

Das ist nur manchmal der Fall, wenn ich was ausprobiere, das nicht geht.

Fakt ist, dass alle automatisch erzeugten Tabellen nicht mehr verfügbar sind. Ich verstehe nicht, warum.

Die Komponente an sich funktioniert, aber so bald die Datenbank aufgerufen wird, stürzt das Skript ab. Es wird hier aber nichts anders gemacht als in meinen anderen Skripten (Z. B. beim Erzeugen einer Checkliste) und hunderten anderen Wiki-Skripten Dritter.

Ich habe mal einen Pseudo-Hook zum Testen erstellt. Auch hier: Sobald die Anfrage, sei sie auch noch so simpel (an anderer Stelle getestet ist sie sowieso!) an die Datenbank geschickt wird, stürzt das Skript ab. Ich habe keine Idee, woran es liegen könnte und darum auch keinen Ansatz, das Problem zu lösen. Ich bin wirklich verzweifelt.

Pseudo-Hook:
Im Wiki aufzurufen mit <dbcheck />. Der macht nichts wirklich sinnvolles. Er zeigt den verwendeten SQL-String an (das klappt) und soll eine simple Datenbankabfrage abschicken, was den oben beschriebenen Fehler auslöst: Es erscheint eine leere Seite.

01: function HOOK_dbcheck($input, $args, $parser, $frame)   {
02:   $dbr=wfGetDB(DB_SLAVE);
03:       
04:   $sql="SELECT name FROM sf_gd_art WHERE id_fam=2";
05:       
06:   $res=$dbr->doQuery($sql);  // Ab hier bricht alles ab!
07:   $items=array();
08:   while($row = $dbr->fetchObject($res))
09:     $items[]=$row->name;
10:   return sprintf("<p>%d Einträge: %s.</p><p>%s", count($items), $sql, $error);
11: }

Wenn ich den Bereich der Zeilen 6 bis 9 auskommentiere funktioniert es. Aber es fehlen eben die Daten aus der Datenbank.

Hat irgend wer eine Idee?

Selbst folgendes erzeugt eine leere Seite:

   function HOOK_dbcheck($input, $args, $parser, $frame)   {
      $dbr=wfGetDB(DB_SLAVE);
      
      $sql="SELECT name FROM sf_gd_art WHERE id_fam=2";
      try {
      $res=$dbr->doQuery($sql);
      $items=array();
      while($row = $dbr->fetchObject($res))
         $items[]=$row->name;
            return sprintf("<p>%d Einträge: %s.</p><p>%s", count($items), $sql, $error);
      } catch (Exception $e) {
         return sprintf('Caught exception: %s',  $e->getMessage());
      }
   }

Dabei soll hier der Fehler abgefangen und angezeigt werden.

Ich sehe nicht einmal einen Ansatz, den Fehler einzukreisen.

Meist sind die Hintergründe scheinbar vollkommen irrationalen Programmverhaltens richtig dämlich. Programmverhalten hat immer eine Ursache. Leider sehe ich keine Chance den Fehler einzukreisen und zu finden.

Hat jemand eine Idee?

Martin

[Martin Lemke]

Debug-Optionen in der LocalSettings.php werden ignoriert!

$wgShowExceptionDetails=true;
$wgShowSQLErrors=true;
$wgShowDBErrorBacktrace =true;

Im Programmverlauf abgefragt, zeigt sich, dass alle auf FALSE stehen.

Es scheint, als müssten wir hinnehmen, dass ein integraler Bestandteil des Wikis nicht mehr funktioniert. Es sei denn, jemand weiß Rat oder wo man Rat bekommen kann.

Eine Sekunde nicht aufgepasst und schon ist alles kaputt. Ich kann allenfalls mal nach einem Backup des Providers von gestern fragen.

Ich habe zu Testzwecken eine ganz neue Koponente programmiert (test2 mit den Hooks <dbcheck2 /> uns <except />). Aber immer das selbe!

Sobald ein Datenbankaufruf erfolgt oder eine Exception abgefangen werden soll, bleibt die Seite leer. Debugmöglichkeiten funktionieren nicht. Mir erscheint das alles vollkommen irrational.

Martin

[Eveline Merches]

Hallo Martin,
hast Du die Datenbank mal runter und dann wieder raufgefahren? Vielleicht hängt die Datenbank an sich.

liebe Grüße
Eveline

[Martin Lemke]

Vielleicht hängt die Datenbank an sich.

Dann würde das Wiki überhaupt nicht angezeigt werden.

Es sind ja noch andere Irrationalitäten vorhanden. Nicht nur in Zusammenhang mit der Datenbank.

Ich habe mal im Supportforum meines Hosters nachgefragt, aber bislang keine Antwort erhalten. Bestimmt ist es irgend eine ausgesprochen blöde Kleinigkeit. Nur die hat verzweifelnde Folgen.

Martin

[Eveline Merches]

Es könnte auch nur eine Tabelle betroffen sein, wenn z:B. eine Anforderung an diese Tabelle auf irgendwas wartet und die Tabelle deshalb blockt.
In Oracle kann man einzelne Sessions killen, in MySQL weiß ich nicht genau, wie das da geht. Deshalb der Vorschlag: die ganze Datenbank runterfahren und wieder rauffahren.
Kannst Du mit SQL auf die Tabelle abfragen, also außerhalb von PHP?

liebe Grüße
Eveline

[Martin Lemke]

Kannst Du mit SQL auf die Tabelle abfragen, also außerhalb von PHP?

Das habe ich nicht versucht, weil mir das zu kompliziert ist. Noch eine Baustelle, in die ich mich einarbeiten müsste.

Es ist aber ein unter php installiertes Programm zum Verwalten der DBs vorhanden (phpMyAdmin). Darüber kann ich unter anderem SQL-Abfragen machen. Das klappt ohne Probleme.

Es liegt also weder an der Datenbank, noch an PHP selber.

Hier nochmal eine neue, aufs wesentliche konzentrierte Komponente:
http://wiki.eu-arachnida.de/index.php?title=Benutzer:Martin/test/familie2gattungen/wahnsinn

Ich bin absolut ratlos und entsprechend mit "den Nerven zufuß".

Martin

[Eveline Merches]

Ok. Also
SELECT name FROM sf_gd_art WHERE id_fam=2;
liefert in phpMyAdmin den gewünschten Wert?

$dbr=wfGetDB(DB_SLAVE); # <= Fehlereintritt hier. Folge: Leere Seite!
        $res=$dbr->doQuery($sql);

Ist  der erste Befehl der Connect zur DB oder was macht der?
Der zweite führt die Abfrage aus, wenn er es denn tut.
Die Exception wird nicht abgefangen. Vielleicht, weil sie aus der Datenbank kommen müsste, und er da gar nicht dran kommt?
In Java muss man den Funktionen mit "throw" sagen, wenn sie exception werfen können. Keine Ahnung, wie das in PHP geht.

Ist $e eine spezielle Exception (z.B. Runtime-Error), oder irgendeine undefinierte?
Manchmal hilft es die spezielle Exception abzufragen, wenn das in PHP überhaupt geht.

Kannst Du vor und nach

$dbr=wfGetDB(DB_SLAVE);

eine Meldung ausgeben und sonst nichts machen?
Ich gehe davon aus, dass Du diesen Schritt an vielen Stellen im Programm machst/machen musst. Woanders scheint er zu klappen?

Wenn Du  jetzt gar nicht weiterkommst, dann warte auf Rückmeldung vom Hoster und lasse den letzten Backup einspielen. Dann nennst Du hier den Zeitpunkt zu dem zurückgesetzt wurde. Und wir machen die bis dahin gemachten Änderungen halt noch einmal.

Gib Dir eine Anzahl Versuche vor, die Du noch machst. Dann trinkst Du einen guten Kaffee, streckst Dich auf der Couch aus, schreist "Scheiße" und gut iss!

liebe Grüße
Eveline

[Eveline Merches]

Die hier aufgefühtren, als FALSE ausgelesenen Variablen werden in der zentralen Konfigurationsdatei LocalSettings.php auf TRUE gesetzt. Trotzdem bleibt ihr Wert == FALSE.

Ich weiß nicht, ob es hilft, aber bei PHP habe ich gelesen, das man manchmal den Browser Cache leeren muss.

liebe Grüße
Eveline

[Tobias]

Falls zurückgesetzt wird, kann man die eventuell neuen/ergänzten Artikel in dieser Zeit ja dadurch retten, dass man die Texte per copy in einer Word-Datei sichert. Dann muss ich bzw. andere die nicht nochmal schreiben. Ich bin gerade sehr im Stress und komme nicht dazu (mir kommen die Linyphiiden schon aus den Ohren raus, ich hatte gerade im Moment in einer einzelnen Bodenfallenbeprobungsreihe bisher schon allein 40 Oedothorax apicatus, das geht schon seit Tagen so). Ab morgen bin ich zudem bis Sonntag in NRW zur Projektkoordinierung. Daher nicht wundern, wenn ich nicht im Forum bin :-).
 
Tobias

[Martin Lemke]

Es ist ganz gut, wenn Du jetzt pausierst, Tobias.

Ich bin mir aber nicht mehr sicher, wann ich den Fehler produziert habe. Hier gepostet hatte ich erst, als sich abzeichnete, dass ich den Fehler kurzfristig nicht korrigiert bekomme.

Aktueller Stand
Ich habe heute die Kundenbetreuung konsultiert und schon Antwort vom Support. Backups werden 3 Tage aufbewahrt. Das heißt, ich kann das Backup von vorgestern einspielen lassen (die anfallenden Kosten inklusive Mehrwertsteuer betragen 4,99 € sind kein Vergleich zu dem ganzen Ärger).

Die Wiki-Änderungen von gestern müssen vorher gesichert werden. 4 Dateien wurden hoch geladen. Die Seiteninhalte können alle in Textdateien gesichert werden. Es wurden gestern inklusive der hochgeladenen Dateien nur 17 Änderungen¹ vorgenommen. Kein Vergleich zu den Tagen davor! -- Schwein gehabt!

1 (Änderungen): Ich sehe gerade, diese Änderungen betreffen teilweise das selbe Dokument. Es muss aber nur die letzte Änderung gesichert werden. Dabei geht zwar der Bearbeiter-Hinweis flöten, aber das ist sicher ein zu verschmerzender Effekt.

Ausblick
Für künftig sollten wir uns partielle Backup-Strategien entwickeln. Unter Linux (der Server läuft unter Linux) geht das ganz gut mit dem Archivierungstool tar (solche archive.tar.gz kennt sicher jeder vom Sehen). Das wäre per Cron-Job möglich (cron ist ein Programm, das zeitgesteuert Aktionen startet).

BTW: Datenbankabfrage
@Eveline: Der Fehler hat nichts mit dem SQL zu tun. Die genannte Abfrage ist eine zum Testen. Sie würde 3 Datensätze zurück liefern.

Die Orignalabfrage soll alle in Europa vorkommenden Gattungen einer angegebenen Familie liefern. Diesen SQL-String habe ich ausprobiert und er funktioniert:

SELECT SUBSTRING_INDEX(art.name, ' ', 1) as Gattung
FROM sf_gd_familie as fam, sf_gd_art as art, cl_art as cl
WHERE fam.name='$familie'
AND art.id_fam=fam.id
AND cl.id_art=art.id
GROUP BY Gattung
ORDER BY Gattung

Optimieren können wir gern sobald das Wiki wieder läuft.

SUBSTRING_INDEX($artname, ' ', 1) liefert den Teilestring des Wertes $artname vom Anfang bis zum 1. Vorkommen eines Leerzeichens (3. Parameter). Das ist sehr praktisch und erspart mir in PHP eine nachbearbeitende Schleife.

$familie ist eine PHP-Variable, die den Namen der Familie enthält.

Martin

[Martin Lemke]

So, die Wiki-Änderungen habe ich jetzt gesichert. Es waren netto nur 9 (inklusive der Dateien):

1. Zacheus crista Bezdecka Text.jpg
2. Zacheus crista
3. Trachyzelotes pedestris
4. Leptyphantes-leprosus-female.jpg
5. Lepthyphantes leprosus-Epigyne.jpg
6. Lepthyphantes leprosus‎
7. Dicranopalpus ramosus
8. Aphantaulax trifasciata
9. Aph.trifasciata Bauer.jpg

Will sicherheitshalber noch jemand anders die Daten zusätzlich sichern? Falls ich ein gutes Händchen hatte? Ich warte jetzt erst nochmal eine Stunde ab und schaue dann nochmal hier. Wenn dann hier nichts entgegen stehendes steht, gebe ich das Einspielen des Backups in Auftrag.

Martin

[Martin Lemke]

Wahrscheinlich sind Tobias' Bearbeitungen gar nicht tangiert, da die Backups zwischen 1 und 4 Uhr erzeugt werden. Siehe Screenshot.

Ich erteile jetzt den Auftrag das Backup aus der Nacht zum 11.12. einzuspielen. Für die Webinhalte und die Datenbank.

Martin

[Tobias]

Achso, ich wusste nicht, dass die Backups in so kurzen Zeitabständen erfolgen. Dann passt das ja sowieso. Ich hatte nur Angst, dass der überarbeitete Dysderidae-Artikel vlt. betroffen ist.

Tobias

[Martin Lemke]

Achso, ich wusste nicht, dass die Backups in so kurzen Zeitabständen erfolgen.

Ich habe das noch nie in Anspruch nehmen müssen. Ich bin nach wie vor von diesem Hoster (Domainfactory df.eu) sehr überzeugt und darum der Meinung, dass die Preisdifferenz zu allerhand billigeren Anbietern sehr gut angelegtes Geld darstellen. Ich bin dort seit 2004 zufriedener Kunde.

Martin

[Eveline Merches]

hallo Martin,
ist doch gut - dann haben wir - DU - das auch mal ausprobiert. Ist doch beruhigend, wenn man weiß, das soetwas klappt.
Der Schaden ist eng begrenzt. Hätte es einen sehr aktiven Tag getroffen, wäre das zwar arbeitsaufwendiger gewesen, aber auch kein Beinbruch.

Ich hoffe, Du kannst schon wieder lachen!

liebe Grüße und Danke für Deine Nerven.

liebe Grüße
Eveline

[Martin Lemke]

Ich hoffe, Du kannst schon wieder lachen!

Noch nicht ganz.

Der Schrecken sitzt noch zu tief und ich bin etwas skeptisch.

Jetzt muss ich noch die letzten Änderungen restaurieren.

Martin

[Martin Lemke]

Da haben wir auch schon das erste Malheur! Ich habe die Datei Leptyphantes-leprosus-female.jpg von Guido nicht in dem dafür vorgesehenen Backup-Ordner gespeichert!

Habe Guido eine pers. Mitt. geschickt.

Martin :-(

[Katja Duske]

Na, wenn das einzige Fehlende ein Foto ist, haben wir doch nun wirklich kein Problem! Guido lädt das bestimmt noch mal hoch und dann sind wir auf dem gleichen Stand wie vorher.

Katja

[Katja Duske]

Ab morgen bin ich zudem bis Sonntag in NRW zur Projektkoordinierung.
Tobias

Wo genau bist Du denn dann?

Katja

[Tobias]

Höxter, an der dortigen FH (Ostwestfalen-Lippe). Leider genau auf der anderen Seite :-( (hab schon geguckt).

Tobias

[Katja Duske]

Schade.

Katja