Perrypedia:Wartung

Aus Perrypedia
Wechseln zu: Navigation, Suche
Google translator: Translate from German to English.
Google translator: Přeložte z němčiny do češtiny.
Google translator: Vertalen van Duits naar Nederlands.
Google translator: ドイツ語から日本語への翻訳
Google translator: Traduire de l'allemand vers le français.
Google translator: Traduzir do alemão para o português.

Um diese Seite übersichtlich zu gestalten, bitte

  • neue Beiträge/ Fragen oben und nach dieser Textbox einfügen.
  • jedem neuen Beitrag eine Überschrift geben (z.B: == Diskussionsthema ==).
  • mit zwei Bindestrichen und vier Tilden (--~~~~) unterschreiben.

Archivierte Beiträge

2011–2013 | 2014–2016 | 2017–2019 | ...


Wartungsfenster Mittwoch 29.04.20

Wegen Wartungsarbeiten im Contabo-Rechenzentrum wird die Perrypedia (Echt + Test) am 29.04.20 von 05:30 bis 05:45 nicht erreichbar sein. Der Server bleibt in Betrieb, aber die Verbindung zum Internet wird gekappt. --Klenzy (Diskussion) 22:19, 27. Apr. 2020 (CEST)

Testwiki wird aktualisiert 04/20

Da ich an einigen Einstellungen des Backups herumgefummelt habe, wird es höchste Zeit, den Restore zu testen. Ich möchte daher am Osterwochenende 10.-13.04.20 das Testwiki plätten und neu aufsetzen. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst, dann ist noch bis Freitag Mittag Zeit dafür. --Klenzy (Diskussion) 15:03, 9. Apr. 2020 (CEST)

Ich fahre jetzt das Testwiki herunter. --Klenzy (Diskussion) 15:56, 11. Apr. 2020 (CEST)
Wieder da. --Klenzy (Diskussion) 19:45, 11. Apr. 2020 (CEST)

Echtwiki Software-Update

Ich möchte heute abend kurzfristig den Software-Update auf 1.31.6 auch im Echtwiki durchführen. 19.30 Uhr, Dauer der Unterbrechung wenige Minuten. --Klenzy (Diskussion) 15:59, 29. Mär 2020 (CEST)

Ich nehme die Perrypedia JETZT kurz offline. Bis gleich. --Klenzy (Diskussion) 19:38, 29. Mär 2020 (CEST)
Fertig! --Klenzy (Diskussion) 19:41, 29. Mär 2020 (CEST)

Testwiki Software-Update

Ich möchte morgen im Testwiki die Mediawiki-Software aktualisieren, von derzeit 1.31.3 auf 1.31.6. Darin enthalten sind ein paar Sicherheitspatches. --Klenzy (Diskussion) 15:31, 25. Mär 2020 (CET)

Ich fahre jetzt das Testwiki herunter. --Klenzy (Diskussion) 13:11, 26. Mär 2020 (CET)
Wieder da. --Klenzy (Diskussion) 13:49, 26. Mär 2020 (CET)

Dauer Datenbank-Backup

Das Datenbank-Backup benötigt inzwischen fast drei Stunden. Während dieser Zeit ist keine Bearbeitung möglich. Auch die Portalseiten funktionieren nicht und melden nur einen Zugriffsfehler. Früher betrug die Zeit nur eine Stunde. Das war kein Problem.

Gibt es einen Weg, die Dauer des nur lesenden Zugriffs zu verkürzen? Ich denke an Möglichkeiten, wie das Backup lokal zu erstellen, die Datenbank wieder freizugeben und dann das Backup im Hintergrund auf einen anderen Server zu übertragen. --Hb059 (Diskussion) 06:33, 8. Mär 2020 (CET)

@Klenzy: Was genau passiert denn beim nächtlichen Backup? Wird da "nur" die Datenbank gedumpt? Oder wird so ein XML-Export gemacht? Im ersten Fall sollten wir das wirklich beschleunigen können, im zweiten Fall evtl. überlegen, ob wir einen täglichen Export (anstatt eines Datenbank-Dumps) brauchen ...
(Will mich nicht in Dinge einmischen, von denen du mehr Ahnung hast als ich, aber bei dem Thema kenne ich mich ein bisschen aus - und manchmal hilft es ja, solche Dinge zu besprechen, um die zündende Idee für eine Optimierung zu haben) --Lars Jürgenson (Diskussion) 11:42, 8. Mär 2020 (CET)
@Hb059, vorab danke, dass Du das Thema ansprichst.
Zunächst muss ich die Aussage ein wenig geradebiegen, der Backup laufe »inzwischen fast drei Stunden«. Richtig ist, dass auf dem vorherigen Dedicated Server die Laufzeit sehr gut kalkulierbar war und in der Regel eine Stunde betrug. Jetzt, auf dem V-Server, ist die Dauer nicht mehr vorhersagbar und es gibt erhebliche Schwankungen. Gestern nacht war die Datenbank 182 Minuten gesperrt, das ist tatsächlich der schlechteste jemals beobachtete Wert. Wenn ich die letzten Wochen so überfliege, waren es größtenteils ≈120 Minuten mit gelegentlichen Ausreißern nach oben und unten (7.03.: 70 Minuten, 4.03.: 146 Minuten, 21.02.: 180 Minuten, 20.02.: 158 Minuten, 19.02.: 59 Minuten). Für unsere Mitarbeiter hierzulande ist das wenig relevant, aber von der anderen Seite der Erdkugel ist es natürlich ... schmerzlich.
Bei einem V-Server haben wir keinen Einfluss darauf, welche Ressourcen uns zugeteilt sind. Da die nächtlichen Abläufe bei uns immer gleich sind, gehe ich davon aus, dass uns die konkurrierenden V-Server ausbremsen. Hier können wir also technisch nichts mehr erreichen. Eventuell lässt sich unser Backup verbessern.
Vor einiger Zeit habe ich bereits (von euch unbemerkt) den Datenbankabzug (@Lars: mysqldump) so umgestellt, dass im ersten Schritt ins Shared Memory (SHM) geschrieben wird. Der Erfolg war enttäuschend: Obwohl wir mehr als genug RAM haben, hat sich an der Laufzeit 0.0 geändert. Eigentlich ein Unding; Shared Memory/RAM müsste in der Theorie etwa zehnmal schneller als der SSD-Festspeicher sein, ist es aber nicht. Dazu hatte ich mit dem Provider bereits Kontakt, beiße aber auf Granit. Man lässt sich nicht in die Karten blicken. Es kam lediglich heraus, dass die V-Server-Konfiguration für IOPS optimiert sei, also übersetzt etwa für das Tagesgeschäft eines Webservers, und man bei sequenzieller Massenverarbeitung wie einem Backup keine Bestwerte erwarten darf.
Welche weiteren Tuningmöglichkeiten gibt es? Mir fällt nicht mehr viel ein. Lokale und externe Sicherung sind bereits entkoppelt. Kurz zusammengefasst erstellt das Skript erst den SQL-Dump (im SHM), dann mit TAR ein Filesystem-Archiv. Nun wird die Datenbank wieder freigegeben, zuletzt überträgt das Skript die beiden Backupdateien (gezippt 6 GB und 21 GB) nach auswärts.
Die einfachste Maßnahme wäre, die Datenbank bereits nach dem SQL-Dump wieder freizugeben, bevor das Filesystem archiviert wird. Konsequenzen:
Meine bisherige Methode garantiert bei einer Wiederherstellung 100% Konsistenz zwischen Datenbank und Filesystem. Wenn ich die Schreibsperre sofort nach dem SQL-Dump aufhebe, sind die 100% nicht mehr gewährleistet. Es könnte (Konjunktiv!) bei einer Wiederherstellung zu Inkonsistenzen kommen. Diese wären sehr überschaubar. Nach meiner ersten Einschätzung gibt es zwei denkbare Fälle, nämlich wenn vor der Beendigung des Filesystem-Archivs Bilder hochgeladen/geändert oder gelöscht werden.
Könnte man also jederzeit machen, aber: bringt nicht viel. Wir hatten gestern: 153 Minuten SQL-Dump, 29 Minuten Filesystem, 7 Minuten für den Transfer SHM -> SSD, und 34 Minuten für den externen FTP-Transfer.
Über andere Optimierungen habe ich mir bisher, zugegeben aus Bequemlichkeit (und weil ich andere Baustellen habe), keine Gedanken gemacht. Lasst hören, wenn ihr Ideen habt ... --Klenzy (Diskussion) 13:02, 8. Mär 2020 (CET)
Hm ... mit V-Servern kenne ich mich wieder wenig aus, aber ich bin überrascht, wie lange der SQL-Dump dauert. Bei den von mir mitbetreuten Servern (Dedicated/Managed, also vergleichbar mit dem alten Server) gehen selbst Datenbank-Dumps im zweistelligen Gbyte-Bereich (Größe des Dumps) recht flott - in dem Bereich bewegen wir uns bei der PP auch, oder? Aber vielleicht kann man da nichts machen. Nur zur Sicherheit: Wird mysqldump direkt für die gesamte DB aufgerufen, oder geht das durch ein Skript wie den PHP "Mysqldumper", das das evtl. nach Tabellen aufteilt? Das kann nach meiner Erfahrung nach einen riesigen (Faktor 10 bis 50) Unterschied ausmachen (keine Ahnung warum).
Konsistenz beim Backup ist gut, die sollten wir nur aufgeben, wenn es wirklich viel bringt.
Vielleicht können wir das Problem auch einfach erstmal umschiffen, indem wir den Backup-Zeitpunkt anpassen? Die meisten PPnauten sind ja in oder nahe bei MEZ, wenn es bislang nur Hb ist, der/die regelmäßig "am anderen Ende der Welt" ist, kann man vielleicht eine Zeit finden, wo die meisten Europäer schlafen und Hb sowieso nicht editieren kann? Keine schöne Lösung und keine Dauerlösung, aber es würde den Schmerzpunkt erstmal wegnehmen (und dafür sorgen, dass ein starker Contributor nicht ausgebremst wird). Wann genau geschieht das Backup denn momentan? --Lars Jürgenson (Diskussion) 13:44, 8. Mär 2020 (CET)
Start 02:00 CET (bzw. später wieder CEST). Vielleicht lässt Hb059 mal hören, welche Zeit für ihn geschickt wäre.
Ja, es ist mysqldump, Bestandteil von MySQL und von Mediawiki empfohlene Backupmethode. PHP "Mysqldumper" kenne ich nicht; wo ich "Skript" schreibe, meine ich das selbstgestrickte Backupskript.
Wir machen einen zusätzlichen XML-Export ab 04:30 CET, der ist völlig unabhängig von der Schreibsperre, daher nicht unbedingt konsistent, was aber für Home-Downloads reicht. Als Backup taugt das sowieso nicht, das sind nur die Artikel ohne sonstige Datenbanktabellen. Details findet ihr übrigens hier: Perrypedia:Server. --Klenzy (Diskussion) 14:09, 8. Mär 2020 (CET)
Was den Zeitpunkt betrifft, werden wir wohl kaum eine sinnvolle Variante finden. Da würde ich nicht dran drehen.
Vielleicht gibt es einen Weg, das Backup inkrementell durchzuführen, d.h. jeden Tag nur die Änderugnen und einmal pro Woche alles. Auch könnte man überlegen, das Backup direkt auf ein externes Netzlaufwerk zu streamen. Der sqldump kommt mir auch merkwürdig langsam vor. Da finden sich sicher Wege dies zu beschleunigen. Wäre halt noch schön zu wissen, wo im System der Flaschenhals ist. Dann könnte man daraufhin optimieren. --Hb059 (Diskussion) 01:24, 9. Mär 2020 (CET)
Die Bemerkungen von Klenzy, dass selbst das Schreiben in den Shared-Memory keinerlei Verbessung erzielt bedeutet, dass der Enpass nicht die Output-Operationen sind. Offensichtlich werden Batch-Prozessen (was eine Sicherung ja ist) so gut wie keine Prioritäten zugeordnet. Vielleicht kann man beim Provider sich für diesen Zeitraum (für 1h) fest zugeordnete virtuelle Ressourcen (1 fixe CPU nur für diesen Job) einrichten lassen. Ich bin auch sicher dass ein inkrementelles Backup bei dem V-Server keinen Geschwindigkeitsvorteil bringen wird, da - wie oben bemerkt - nicht die Output-Operationen der Engpass sind. Ich kann ein Wechselspiel zwischen Voll- und Teil-Sicherungen bei diesem geringen Datenvolumen wirklich nicht empfehlen; wir hätten im Restorefalle sogar höhere Komplexitäten und somit deutliche Verzögerungen bei der Wiederherstellungszeit. --Norman (Diskussion) 08:33, 9. Mär 2020 (CET)
Hm, nachdem, was Klenzy oben geschrieben hat, klingt es nicht wahrscheinlich, dass das mit den fest zugeordneten Ressourcen klappt. Damit sieht es schwierig aus, wenn ein zeitliches Verschieben keine Option ist.
Eine radikalere Idee: Wenn man mysqldump den Parameter --single-transaction muss die Datenbank und deshalb das Wiki nicht gelockt werden. Stattdessen dumpt mysql dann den Zustand, den die Datenbank zu Beginn des backups hat (egal, wie lange der Dump dauert). Und dann müssten wir uns entscheiden:
  • Wir pfeifen auf absolute Konsistenz zwischen DB- und File-Backup (wie Klenzy oben schreibt, sind die Risiken gering), und locken das Wiki einfach gar nicht: Zero Down-time, entsprechend ist es Wurst, wie lange das Backup dauert ODER
  • Wir gehen wie folgt vor:
    • Schreibschutz des Wiki an
    • Anstoßen des DB-Backups
    • Anstoßen des File-Backups in einem separaten Prozess
    • Nach Ende des File-Backups: Schreibschutz des Wiki aus
Damit wäre die Konsistenz gegeben, da der DB-Backup ja die Datenbank in dem Zustand dumpt, den sie während des Locks hatte. Und der Schreibschutz wäre nur für den Zeitraum des File-Backup aktiv.
Man findet im Web durchaus Berichte, wo Leute bei Mediawiki mit --single-transaction arbeiten, und in diesem Buch wird das empfohlen, um lange lock-Zeiten zu vermeiden. Es ist also keine exotische Idee. Aber da diese Methode vom empfohlenen Backup-Vorgang abweicht, müssten wir sie zuerst testen.
--Lars Jürgenson (Diskussion) 11:26, 9. Mär 2020 (CET)
Ich versuche mal was. Die anderen Experimente möchte ich auf nächsten Monat verschieben, da ich demnächst ein paar Tage weg bin. --Klenzy (Diskussion) 10:57, 10. Mär 2020 (CET)
Gestern habe ich an ein paar Einstellungen herumgefummelt. Im Ergebnis lief der Backup letzte Nacht 79 Minuten (55 Minuten Datenbank, 24 Minuten Filesystem). Ein einmaliger Wert sagt nicht viel aus. Bleibt abzuwarten, ob es ein zufällig guter Wert war oder sich ein neuer, besserer Durchschnitt herausbildet. --Klenzy (Diskussion) 08:43, 1. Apr. 2020 (CEST)
Nach weiteren Basteleien haben wir jetzt: vorletzte Nacht 29 Minuten, letzte Nacht 34 Minuten. Ich bin, hm, verhalten optimistisch, dass die Zeitdauer der Sperre zukünftig deutlich unter zwei Stunden bleiben wird. --Klenzy (Diskussion) 12:59, 9. Apr. 2020 (CEST)
Das klingt doch schonmal super. Mal wieder: Danke für deinen Einsatz! --Lars Jürgenson (Diskussion) 13:27, 9. Apr. 2020 (CEST)
Auch von meiner Seite vielen Dank! Das hilft mir extrem. --Hb059 (Diskussion) 14:34, 9. Apr. 2020 (CEST)
29 Minuten, 35, 55, gestern 78 Minuten. Also: alles auf Anfang. Langsam gehen mir die Ideen aus. --Klenzy (Diskussion) 11:50, 11. Apr. 2020 (CEST)
Na ja, so wie ich das sehe sind die Zeiten doch schon deutlich geschrumpft gegenüber früher (180 min.?). Hoffentlich nur ein einmaliger Ausreißer nach oben. Und vielleicht kann der Hoster doch noch etwas an der Konfiguration (tempörar mehr Ressourcen zuordnen o.ä.) für uns tun? --Norman (Diskussion) 13:05, 11. Apr. 2020 (CEST)
Ich glaube, wir haben den Durchbruch geschafft. In den letzten 8 Nächten dauerte die Sperre zwischen 28 und 43 Minuten, wir sind also konstant unter einer Stunde (≈60-70 Minuten war die Messlatte unseres vorherigen Stammservers). --Klenzy (Diskussion) 12:14, 24. Apr. 2020 (CEST)
Tolle Nachricht. Gratulation. --Norman (Diskussion) 12:28, 24. Apr. 2020 (CEST)
Super Arbeit.--Jenka (Diskussion) 12:31, 24. Apr. 2020 (CEST)
In den letzten Tagen häufen sich leider wieder die Rückfälle mit über 2 Stunden. Wochendurchschnitt 75 Minuten, die Woche davor Durchschnitt 58 Minuten. Die Schwankungsbreite ist enorm, Minimum 33, Maximum 173. Ich beobachte weiter. --Klenzy (Diskussion) 12:08, 5. Jul. 2020 (CEST)

Testwiki wird aktualisiert 02/20

Das Testwiki ist inzwischen sehr veraltet. Ich möchte daher nächstes Wochenende 1.-02.02.20 das Testwiki plätten und neu aufsetzen. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst, dann ist noch bis Samstag vormittag Zeit dafür. Gibt's Einwände? --Klenzy (Diskussion) 19:56, 30. Jan. 2020 (CET)

Das Testwiki wird jetzt geplättet. --Klenzy (Diskussion) 12:20, 2. Feb. 2020 (CET)
Das Testwiki ist wieder da. Stand: 1. Februar 2020. --Klenzy (Diskussion) 14:09, 2. Feb. 2020 (CET)

offline wegen Semantic Mediawiki

Ich benötige ein Zeitfenster, um SMW wieder zu aktivieren. Die Extension habe ich bereits installiert, nun müssen zwei Skripte laufen, welche das Datenbankschema anpassen und den "SMW-Store" befüllen. Während der Datenbankanpassung muss die Perrypedia offline gehen. Wie lange das dauert, kann ich nicht voraussagen. Im günstigsten Fall sind wir wenige Minuten später wieder online. Ich plane den Start für morgen, Freitag, 17.01. um 11 Uhr. Sollte es länger dauern (bei SMW ist das so 'ne nicht voraussehbare Sache), dann halte ich euch im Forum, Perrypedia-Infokanal auf dem Laufenden. --Klenzy (Diskussion) 11:40, 16. Jan. 2020 (CET)

Super, danke, dass Du das machst! --Pisanelli (Diskussion) 12:26, 16. Jan. 2020 (CET)
Schon erledigt, Datenbankupdate ist fertig, Perrypedia wieder online. Glück gehabt.
Eventuell muss ich ein weiteres Skript aufrufen, das die SMW-Tabellen füllt und das dann wirklich viele Stunden laufen wird. Das passiert aber im Hintergrund, der Betrieb wird dadurch in keiner Weise eingeschränkt. --Klenzy (Diskussion) 11:10, 17. Jan. 2020 (CET)