Perrypedia:Wartung/Archiv 2020 - 2022

Testwiki wird aktualisiert 10/22

Ich möchte das Testwiki auf den neuesten Stand bringen: ab Mittwoch, 19.10.22, ca. 09:30 Uhr. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst, dann ist noch bis Mittwoch früh Zeit dafür. --Klenzy (Diskussion) 10:53, 17. Okt. 2022 (CEST)

Verschoben. Neuer Termin Freitag, 21.10.22, ca. 09:30 Uhr. --Klenzy (Diskussion) 17:25, 19. Okt. 2022 (CEST)

Jetzt gehts los, ich nehme das Testwiki vom Netz. --Klenzy (Diskussion) 09:47, 21. Okt. 2022 (CEST)

Endlich wieder da. (Ich bastle gerade an einem Skript. Irgendwann wird es größtenteils automatisch laufen ... vielleicht ...) --Klenzy (Diskussion) 16:49, 21. Okt. 2022 (CEST)

Wartung Echtwiki

Mittwoch, 3. August 2022 möchte ich im Echtwiki die neue Mediawiki-Version 1.35.7 installieren. Außerdem werde ich nochmal ein paar Verbesserungen bei den Zeichensätzen der Datenbanktabellen vornehmen. Start vorauss. ca. 9 Uhr, Dauer 1-2 Stunden. Leider müssen wir einen Teil der Zeit völlig offline sein. --Klenzy (Diskussion) 16:35, 1. Aug. 2022 (CEST)

Viel Glück. --Norman (Diskussion) 22:21, 1. Aug. 2022 (CEST)

Mediawiki-Version 1.35.7 erfolgreich installiert.

Bitte beachtet: Die Pagelinks-Tabelle wird derzeit im Hintergrund vollständig neu aufgebaut.

Während dieser Job läuft, sind alle Auswertungsergebnisse über Spezial:Linkliste ("Die folgenden Seiten verlinken auf...") unvollständig.

Bitte Geduld. Es handelt sich um etwa 2,3 Millionen (!) Datensätze und das wird etwa 18-20 Stunden dauern. --Klenzy (Diskussion) 10:35, 3. Aug. 2022 (CEST)

Vielen Dank wie immer für Deinen tollen Einsatz, Klenzy! Du machst einen super Job! --Pisanelli (Diskussion) 08:08, 4. Aug. 2022 (CEST)

Gerne. Die Pagelinks sind jetzt fertig, 2436318 Datensätze. --Klenzy (Diskussion) 11:09, 4. Aug. 2022 (CEST)

Wartung Testwiki

Montag, 1. August 2022 möchte ich das Testwiki runderneuern: Datenübernahme aus dem Echtwiki, Upgrade Mediawiki-Software auf 1.35.7. Start zwischen 9 und 11 Uhr, Dauer unbekannt. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst ... dann ist noch bis Montag früh Zeit dafür. --Klenzy (Diskussion) 18:03, 30. Jul. 2022 (CEST)

Wartung beginnt. --Klenzy (Diskussion) 10:00, 1. Aug. 2022 (CEST)

Vielen Dank für Deine unermüdliche Arbeit, Klenzy. --GolfSierra (Diskussion) 10:13, 1. Aug. 2022 (CEST)

Das Testwiki ist wieder da. Mediawiki 1.35.7, Datenbestand vom Echtwiki 31.8.2022.

Wg. unermüdliche Arbeit ...: Heute hat es lang gedauert. Ich musste ganz plötzlich und ganz dringend mittags in die Eisdiele :-P --Klenzy (Diskussion) 16:01, 1. Aug. 2022 (CEST)

Neustart der MySQL-Datenbank

Verzeihung, ich muss ganz kurzfristig die Datenbank neu starten. Dauer 2 Minuten. --Klenzy (Diskussion) 17:05, 28. Jun. 2022 (CEST)

Schon erledigt. --Klenzy (Diskussion) 17:07, 28. Jun. 2022 (CEST)

Wartungsarbeiten der MySQL-Datenbank II

Nun also: Montag, 28.03.2022 ab 13.30 Uhr beginne ich mit den Wartungsarbeiten an unserer Datenbank, Dauer ca. 2 bis 3 Stunden (nur Echtwiki). Ich setze einen Schreibschutz, alle Datenbankänderungen werden blockiert. Zwischendurch wird das Echtwiki 1 bis 2 Stunden offline sein. Das Testwiki bleibt uneingeschränkt. Mehr dazu siehe hier. --Klenzy (Diskussion) 12:18, 25. Mär 2022 (CET)

Nun waren es doch fast vier Stunden. Am Schluss nochmal eine Schrecksekunde: Die verf§$%ten Wikipedia-Links wieder im Eimer, wie vor einer Woche! Dabei habe ich die Interwiki-Tabelle diesmal garantiert korrekt geändert ...!

... aber dann war's doch bloß einer der -zig Caches. Server-Reboot, fertig.

Jetzt herrscht Ordnung: Benutzer:Klenzy/MySQL-Zeichensätze 28.03.2022! --Klenzy (Diskussion) 17:36, 28. Mär 2022 (CEST)

Und das ist bekanntlich sehr viel Wert. Danke dafür. --Norman (Diskussion) 18:49, 28. Mär 2022 (CEST)

Vielen Dank für den Einsatz, Klenzy! --GolfSierra (Diskussion) 08:35, 30. Mär 2022 (CEST)

Damit ist es ab jetzt auch nicht mehr möglich, versehentlich 2 Artikel z.B. Zünder und ZÜNDER anzulegen, die es vor kurzem noch gab. Letzterer Link bleibt zwar rot, geht aber beim Anklicken auf den vorhandenen Artikel. --Klenzy (Diskussion) 20:47, 30. Mär 2022 (CEST)

Testwiki offline II

Ich möchte die Datenbankarbeiten noch einmal im Testwiki Schritt für Schritt durchspielen, um herauszufinden, an welcher Stelle ich einen Fehler gemacht habe. Streckenweise offline, teilweise online mit Schreibschutz. --Klenzy (Diskussion) 10:37, 23. Mär 2022 (CET)

Fertig mit dem Testwiki. --Klenzy (Diskussion) 12:14, 25. Mär 2022 (CET)

Wartungsarbeiten der MySQL-Datenbank

Montag, 14.03.2022 ab 10.00 Uhr beginne ich mit Wartungsarbeiten an unserer Datenbank, Dauer ca. 2 bis 4 Stunden (nur Echtwiki). Ich setze einen Schreibschutz, alle Datenbankänderungen werden blockiert. Das Echtwiki geht nicht offline, möglicherweise gibt es zeitweise Behinderungen beim Lesezugriff (Datenbank-Zugriffsfehler). Umfang/Dauer der Behinderungen kann ich nicht abschätzen. Das Testwiki bleibt uneingeschränkt.

Seit anno Tobak herrscht in unserer Wiki-Datenbank ein fröhliches Durcheinander verschiedener Zeichensätze und Sortierfolgen (character sets, collations), da gibt es Binary, Latin1 (mit Latin1_swedish_ci ...) und Utf8, also Unicode-8-Bit. Die neue Version MySQL 8 verwendet bei Utf8 implizit Utf8mb3 (= Multibyte 3), was aber allmählich als veraltet gilt. Von Latin1 will ich mal gar nicht reden. Mit den geplanten Maßnahmen hieve ich die Datenbank von Latin1 und Utf8mb3 einheitlich auf Utf8mb4. Das wird hoffentlich auf Jahre zukunftssicher sein. Die Binary-Zeichensätze bleiben erstmal so, andere Baustelle.

Wer jetzt nur Böhmisch versteht ...: Wichtig ist das vor allem für mich hinter den Kulissen, an der Bedienoberfläche ändert sich fast nichts. Eine Kleinigkeit ist für euch als Benutzer nützlich. Im Suchfeld funktionieren viele Umlaute (ä, ö, ü, á, é ...) zukünftig unabhängig von Groß-/Kleinschreibung, das war bisher nur auf der ersten Stelle so, neu an jeder Stelle im Suchbegriff. --Klenzy (Diskussion) 18:29, 10. Mär 2022 (CET)

Danke, dass du diese Bereinigung vornimmst. Damit setzt du nun eine seit Jahren bestehende Empfehlung von MySQL um. Diese Sachverhalte waren - zumindest mir - bisher gar so nicht bewußt. Damit einher geht, dass sich dadurch die DB um 33% vergrößert. Wird dieser Wachstumsschub Auswirkungen auf unser Backup-Konzept haben? Laufzeiten? Anzahl vorgehaltener Sicherungen? --Norman (Diskussion) 07:12, 11. Mär 2022 (CET)

Nach meinen bisherigen Beobachtungen im Testwiki wird sich die Datenbank nicht vergrößern. Das Konzept hinter Utf8mb3/mb4 ist weiterhin ein 8-Bit-Zeichensatz wie beim antiken ASCII (genauer: ISO-8859-1, auch Latin1 genannt). Die geläufigen mitteleuropäischen Buchstaben und Ziffern des lateinischen Alphabets belegen weiterhin 1 Byte. Lediglich Sonderzeichen wie Umlaute, Accentzeichen etc. benötigen 3 bzw. zukünftig 4 Bytes (daher "mb3"/"mb4" = Multibyte 3/4). Der älteste Unicode-Zeichensatz UTF-16 und der neuere UTF-32 belegen wesentlich mehr Platz, spielen aber im Internet keine Rolle ([1], [2]). Jedes über Leitung übertragene Byte kostet, daher ist Utf8 der bestmögliche Kompromiss. Utf8mb4 ist der derzeit neueste vereinbarte Standard, mb5 und mb6 sind bisher nur angedacht ([3]).

Es gibt also eine minimale Vergrößerung bei den Sonderzeichen, die mehr als wett gemacht wird, weil ich gleichzeitig 9 alte und überflüssige Tabellen entsorge, eine davon mit geschätzt 10 MB.

Bei Backup und Restore ändert sich voraussichtlich ebenfalls nichts.

Die Umstellung auf Utf8mb4 ist - wieder einmal - nicht jetzt nötig, aber jetzt habe ich gerade Zeit und weiß, wie's geht. --Klenzy (Diskussion) 09:14, 11. Mär 2022 (CET)

Danke für die interessante Erläuterung. Ich hatte in meinen früheren Berufsjahren schmerzhafte Erfahrungen, als wir eine SAP-Installation auf Unicode umstellen mussten. Es ist gut, dass du weißt wie es geht und es ist eine früher oder später notwendige Investition für die Zukunft. :-) --Norman (Diskussion) 10:28, 11. Mär 2022 (CET)

Verschoben. Es geht immer noch nicht so, wie ich möchte. --Klenzy (Diskussion) 21:24, 13. Mär 2022 (CET)

Neuer Anlauf: Montag, 21.03.2022 ab 10.00 Uhr, Dauer ca. 2 bis 3 Stunden (nur Echtwiki). --Klenzy (Diskussion) 16:03, 15. Mär 2022 (CET)

Leider auf den letzten Metern gescheitert.

Datensicherung von 10 Uhr wiederhergestellt. --Klenzy (Diskussion) 15:42, 21. Mär 2022 (CET)

Shit happens. Auf ein neues! --Norman (Diskussion) 18:47, 21. Mär 2022 (CET)

Voraussichtlich Freitag ... --Klenzy (Diskussion) 19:43, 21. Mär 2022 (CET)

Fingers crossed. --GolfSierra (Diskussion) 22:18, 21. Mär 2022 (CET)

Testwiki offline

Das Testwiki geht für einige Zeit offline. Ich möchte etwas ausprobieren. --Klenzy (Diskussion) 15:41, 15. Feb. 2022 (CET)

Testwiki wieder da. --Klenzy (Diskussion) 17:16, 15. Feb. 2022 (CET)

Ich nehme das Testwiki wieder offline. Muss etwas mit den Zeichensätzen der Datenbank testen. --Klenzy (Diskussion) 12:05, 18. Feb. 2022 (CET)

Testwiki ist endlich wieder uneingeschränkt verfügbar.

Bitte achtet darauf, ob es auffällige Darstellungsfehler gibt, ob die Links und Spezialfunktionen sauber funktionieren.

Hintergrund der leider unerwartet lang dauernden Aktion ist/war ein furchtbares Durcheinander in der Datenbank. Die einzelnen Tabellen verwenden unterschiedliche Zeichensätze und Sortierfolgen (collations): Binärformat, Latin1, UTF8 (genauer UTF8mb3). Das habe ich weitgehend bereinigt. Nützlich ist das vor allem für mich hinter den Kulissen, an der Bedienoberfläche ändert sich fast nichts. Eine Kleinigkeit ist für die Benutzer nützlich. Vergleicht mal Echtwiki und Testwiki, wenn ihr im Suchfeld solche Zeichenfolgen eintippt: "jül", "JÜL", "báa", "BÁA" ... --Klenzy (Diskussion) 15:35, 6. Mär 2022 (CET)

Ah ha! Jetzt wird unabhängig von der Groß-/Kleinschreibung alles in der Vorauswahl als Treffer angezeigt. Prima! --Norman (Diskussion) 13:05, 9. Mär 2022 (CET)

Testwiki wird aktualisiert 02/22

Ich möchte das Testwiki auf den neuesten Stand bringen: ab Mittwoch, 9.02.22, 09:00 Uhr. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst, dann ist noch bis Mittwoch früh Zeit dafür. --Klenzy (Diskussion) 21:20, 6. Feb. 2022 (CET)

Das Testwiki wird jetzt heruntergefahren und neu aufgesetzt. --Klenzy (Diskussion) 10:56, 9. Feb. 2022 (CET)

Testwiki ist wieder da, mit dem Stand vom 9.02.2022, 01.30 Uhr. --Klenzy (Diskussion) 12:28, 9. Feb. 2022 (CET)

Sieht auf die schnelle gut aus. Super! --Norman (Diskussion) 12:50, 9. Feb. 2022 (CET)

Und damit habe ich gleichzeitig erfolgreich erprobt, dass Datensicherung & Wiederherstellung nach all den schönen Upgrades einwandfrei funktionieren ;-) --Klenzy (Diskussion) 14:49, 9. Feb. 2022 (CET)

Prima. Es beruhigt ungemein, ein top aktuelles System und eine validierte und funktionierende Notfallprozedur zu haben! Danke dafür. --Norman (Diskussion) 07:35, 10. Feb. 2022 (CET)

Software-Upgrade: Fragen, Fehler und Probleme?

Der Upgrade hat mit Anlaufschwierigkeiten geklappt. MySQL ist jetzt 8.0, die Installation war etwas holprig. MediaWiki ist jetzt 1.35.5 und damit doch +0.0.1 gegenüber dem Testwiki; ich habe das 1.35.4-Installationspaket verschlampert. Macht aber nichts, weil die 1.35.5 mehrere wichtige Sicherheitsänderungen enthält. Das Skript für die Mediawiki-Datenbanktabellen lief allein schon 57 Minuten, damals im Testwiki war das viel schneller.

Hier ist der Platz für eure Fragen und Fehlermeldungen. --Klenzy (Diskussion) 14:02, 28. Jan. 2022 (CET)

Hauptseite

Am unteren Ende der Hauptseite erscheint nun __NONSHEADER__. Dies ist mir im Testwiki bisher nicht aufgefallen, obwohl es nun auf der dortigen Seite auch erscheint. --Norman (Diskussion) 18:15, 28. Jan. 2022 (CET)

Hast Du Schreibberechtigung für die Hauptseite? Bitte die Zeile mit __NONSHEADER__ löschen, wird nicht mehr benötigt. --Klenzy (Diskussion) 20:30, 28. Jan. 2022 (CET)

Erledigt (auch für Testwiki) --Norman (Diskussion) 20:34, 28. Jan. 2022 (CET)

Danke! --Klenzy (Diskussion) 20:46, 28. Jan. 2022 (CET)

Datenbank nicht gestartet

01.25–13.30 Uhr war die Perrypedia leider nicht erreichbar, ich bitte die Unannehmlichkeiten zu entschuldigen. Ich habe bis gerade eben nicht gewusst, dass man nach dem Upgrade der MySql-Version den Autostart neu einrichten muss. Das Versäumnis habe ich behoben und ab jetzt wird die Datenbank wieder automatisch gestartet. --Klenzy (Diskussion) 14:12, 29. Jan. 2022 (CET)

Vorlage:UserCreates wird nicht aktualisiert

In Arbeit. --Klenzy (Diskussion) 14:15, 29. Jan. 2022 (CET)

Die Datenbanktabelle "revision" hat sich in MediaWiki 1.35 geändert, die "stored procedure" muss angepasst werden. Das konnte im Testwiki leider nicht auffallen :-( --Klenzy (Diskussion) 14:23, 29. Jan. 2022 (CET)

Behoben. --Klenzy (Diskussion) 16:56, 29. Jan. 2022 (CET)

Skin:DarkVector - Farben stimmen nicht

Demnächst in Arbeit. --Klenzy (Diskussion) 23:20, 29. Jan. 2022 (CET)

Endlich auch erledigt. --Klenzy (Diskussion) 12:42, 23. Mär 2022 (CET)

TextErsetzen

Das TextErsetzen-Tool gibt nur noch maximal 250 Ergebnisse aus. Bitte wieder wie gehabt auf 2500 erhöhen (das deckt fast alles ab). --JoKaene 14:11, 30. Jan. 2022 (CET)

Erledigt, könntest Du das bitte nochmal ausprobieren?

Beim letzten Mal musste ich noch im Sourcecode der Extension herumpfuschen, mittlerweile gibt's einen praktischen Parameter. --Klenzy (Diskussion) 20:19, 30. Jan. 2022 (CET)

Ja, funktioniert. Es werden 2.500 Treffer angezeigt. Danke! --JoKaene 20:23, 30. Jan. 2022 (CET)

Timeout

Zumindest im Testwiki habe ich wieder ein Timeout-Problem. In diesem Fall mit »TextErsetzen«. --JoKaene 14:50, 30. Jan. 2022 (CET)

Jetzt auch im Echt-Wiki bei Aufruf der Seite »Spezial:Weiterleitungen prüfen«. --JoKaene 15:56, 30. Jan. 2022 (CET)

Ich habe die Ausführungszeit für PHP erhöht. Bitte beobachten, ob's hilft ... --Klenzy (Diskussion) 20:34, 30. Jan. 2022 (CET)

(Ich muss dazu sagen, dass es ungefähr mindestens ein Dutzend unterschiedliche Timeout-Parameter gibt ... :-( ...--Klenzy (Diskussion) 20:47, 30. Jan. 2022 (CET)

Hat jetzt erstmal nicht funktioniert. Test weiterhin mit »Spezial:Weiterleitungen prüfen«. --JoKaene 17:54, 31. Jan. 2022 (CET)

Hmmmm ... funktioniert bei mir praktisch immer. Irgendwelche Besonderheiten? Browser? Windows/Android? --Klenzy (Diskussion) 22:16, 31. Jan. 2022 (CET)

Bin unterwegs, also Tablet mit Android. --JoKaene 07:44, 1. Feb. 2022 (CET)

Siehe da ... auf dem Smartphone hatte ich jetzt auch 1 x "Gateway timeout" (versus 2 x erfolgreich). Könnte eine Spur sein. Ich bleibe dran. --Klenzy (Diskussion) 15:37, 1. Feb. 2022 (CET)

Hier kann ich offenbar leider doch nichts machen. Auf dem Smartphone bekomme ich den "Gateway timeout" zwar auch ab und zu, genau genommen: beim ersten Aufruf von »Spezial:Weiterleitungen prüfen«; die nachfolgenden Aufrufe funktionieren dann (vermutlich sind dann die verschiedenen Servercaches recht brauchbar gefüllt, sodass es dann schneller läuft). Verschiedene Internetfundstellen deuten darauf hin, dass der Chrome-Browser einen kürzeren Timeout im Vergleich zu anderen Browsern hat und man diesen Wert nicht ändern kann. Wenn es bei dir tatsächlich auch Chrome ist, könntest Du vielleicht mal einen anderen Browser ausprobieren? --Klenzy (Diskussion) 13:44, 2. Feb. 2022 (CET)

So, bin wieder zuhause. Noch einmal mit dem Tab und Chrome getestet: Hat innerhalb etwa 50 Sekunden geklappt. Der folgende Test mit PC und FF brauchte im Anschluss etwa 35 Sekunden. Das Timeout zuvor schlug wie früher schon mal nach 1 Minute zu. Jetzt im Moment ist also alles in Ordnung. Da ich mich um Seitenpflege eh' meist am Wochenende kümmere, ist es mir eigentlich egal, was Chrome so tut. Erst wenn ich auch mit FF Schwierigkeiten habe, melde ich mich wieder. Danke bis hierhin. --JoKaene 19:58, 2. Feb. 2022 (CET)

So, gerade jetzt passiert: Timeout nach einer Minute. Zweiter Versuch nach 50 Sekunden erfolgreich. (Mit FF) Am Ende bekomme ich also was ich will. Ist aber nicht schön. --JoKaene 18:14, 4. Feb. 2022 (CET)

Könntest Du bitte kurz was nachschauen? Schreibe bitte in die URL: "about:config"; die Warnung übergehen; dann neben der Suchlupe "network.http.connection-timeout": Was steht bei dir für ein Wert? Bei mir: 90 (Sekunden). --Klenzy (Diskussion) 19:56, 4. Feb. 2022 (CET)

Sorry, ich muss nachfragen: In welche URL an welche Stelle. Bin gerade nicht weit gekommen, hab aber auch 'nen schlechten Tag. --JoKaene 20:08, 4. Feb. 2022 (CET)

Im URL-Eingabefeld im Firefox-Browser, also dort, wo normalerweise "https://www.perrypedia.de" steht. Es muss ja aber auch nicht heute sein, wenn's nicht passt. --Klenzy (Diskussion) 20:42, 4. Feb. 2022 (CET)

Ebenfalls 90. --JoKaene 20:46, 4. Feb. 2022 (CET)

Danke! Dann werde ich die nächsten Tage doch nochmal ein paar Werte auf dem Server probieren. --Klenzy (Diskussion) 21:00, 4. Feb. 2022 (CET)

Neuer Versuch? Ich habe drei zentrale Timeout-Werte auf 90 Sekunden gesetzt, den normalen Apache-Webserver, Apache-Proxy (für die Schnittstelle zum PHP-FPM), und PHP-FPM. Die beiden letzten gibt es erst seit einer kleinen Technikumstellung vor ein paar Wochen und waren daher bisher leer. Mit etwas Glück sind das die entscheidenden Werte. --Klenzy (Diskussion) 12:55, 6. Feb. 2022 (CET)

Ich hätte dir ja gerne Infos zukommen lassen. Aber egal was ich ausprobiere, heute geht alles schneller als in 60 Sekunden. --JoKaene 19:46, 6. Feb. 2022 (CET)

Wir schauen uns das nochmal an, sobald ich ein aktuelles Testwiki habe. --Klenzy (Diskussion) 21:17, 6. Feb. 2022 (CET)

Im Testwiki eben nach gut 50 Sekunden erfolgreich, im Echtwiki sogar nach rund 35. Das sind erstaunlich gute Werte (ich habe früher bis zu vielleicht fünf Minuten warten müssen). Wenn's so bleibt, bin ich glücklich. --JoKaene 18:50, 9. Feb. 2022 (CET)

Wenn's wieder passiert, bitte melden. Ein paar Tests im Testwiki lassen mich hoffen und vermuten, dass es die zuletzt geänderten Timeoutwerte sind oder waren oder sein könnten. --Klenzy (Diskussion) 11:12, 10. Feb. 2022 (CET)

Gute Nachricht! Heute hat der Seitenaufruf doch mal wieder länger als eine Minute gedauert – und wurde ohne Timeout-Hinweis beendet. Danke! --JoKaene 17:58, 19. Feb. 2022 (CET)

...und Rückschlag... Erster Versuch nach 90 Sekunden wegen Timeout abgebrochen (hab' ja früher schonmal angemerkt, dass es auch sehr lang dauern kann), zweiter Versuch dann nach 70 Sekunden erfolgreich. Wenn nichts gegen eine weitere Erhöhung des Wertes spricht, bitte ich darum. --JoKaene 15:39, 20. Feb. 2022 (CET)

120 Sekunden. Kann nicht schaden, auch "Text ersetzen" dauert zuweilen. --Klenzy (Diskussion) 11:09, 21. Feb. 2022 (CET)

Favoriten setzen

Um Seiten schneller aufrufen zu können, kann man Favoriten setzen/einrichten. Geht jetzt nicht mehr bei mir. Da wird immer eine Fehlermeldung angezeigt. --Pisanelli (Diskussion) 11:51, 31. Jan. 2022 (CET)

Neue Version, neue Fehler :-(( ... in Arbeit! --Klenzy (Diskussion) 13:57, 31. Jan. 2022 (CET)

Sorry, danke! --Pisanelli (Diskussion) 14:42, 31. Jan. 2022 (CET)

Nix sorry, dafür bin ich da. Meistens macht es auch Spaß, wenn ich was bewirken kann. Leider nicht in diesem Fall: Die Mediawiki-Freaks haben verpennt, die Favoriten für die neue Version 1.35 anzupassen. Das ist bisher niemandem aufgefallen, oder niemand hat's gemeldet. Ob und wann der Fehler korrigiert wird, weiß ich nicht. --Klenzy (Diskussion) 16:56, 1. Feb. 2022 (CET)

Oh, das ist schade. Für mich war das eine sehr nützliche Funktion. Dann warten wir mal ab. Danke für Checken! --Pisanelli (Diskussion) 09:27, 4. Feb. 2022 (CET)

Als Idee/Vorschlag: Ich habe mir damit beholfen, dass ich auf meiner Benutzerseite eine Rubrik Memo to me erstellt habe und dort die Links sammle, die ich gerne schnell und häufiger aufrufen möchte. --Vasudeva (Diskussion) 09:01, 23. Feb. 2022 (CET)

Ja, anders geht's leider nicht. Schade

Die Extension ist weiterhin stillgelegt: https://www.mediawiki.org/wiki/Extension:Favorites

Daher habe ich die Favoriten bei uns jetzt entfernt. --Klenzy (Diskussion) 22:24, 20. Jun. 2022 (CEST)

CSS (Einklapp, Navleisten, Infoboxen...)

Die Vorlage Einklapp Anfang erzeugt eine falsche Darstellung (siehe z.B. Arkoniden#Stammbaum). --JoKaene 21:53, 3. Feb. 2022 (CET)

Von jetzt auf gleich (seit ca. 21.40 Uhr) funktioniert ein großer Teil der CSS-Einstellungen nicht mehr. Ich wüsste nicht, dass irgendwer irgendwas daran geändert hätte ... im Moment stehe ich vollständig auf dem Schlauch. --Klenzy (Diskussion) 22:09, 3. Feb. 2022 (CET)

Server neu gestartet, jetzt funktioniert es wieder ... das ist, ääähh, ssehr sseltssam ... --Klenzy (Diskussion) 22:23, 3. Feb. 2022 (CET)

Ein merkwürdiger Tag gestern. Erst dieser seltsame Bot aus Russland und am Abend dieses ... Die Symptome waren eindeutig, alle Styles aus MediaWiki:Common.css wurden ignoriert, auf allen Browsern auf allen Seiten. Mit dem Bot kann das nichts zu tun haben, eher sieht es nach einem Datenbankfehler aus. In den Logdateien ist nichts Auffälliges zu sehen. Es bleibt vorerst ein ungeklärtes Phänomen. --Klenzy (Diskussion) 08:39, 4. Feb. 2022 (CET)

Vorlage Anker

Nach diesem Einsatz der Anker-Vorlage in einer Absatz-Überschrift werden die korrekt angelegten Redirects [[Chronautenstation]] und [[Legion-Führer]] falsch-positiv auf der Seite Redirects prüfen angezeigt. --JoKaene 10:37, 12. Feb. 2022 (CET)

Behoben! --Klenzy (Diskussion) 18:31, 12. Feb. 2022 (CET)

Gegengecheckt. Funktioniert. Danke! --JoKaene 20:09, 12. Feb. 2022 (CET)

MultiCategorySearch

Ist mir erst heute aufgefallen: Die Spezialseite für Mehrfach-Kategorie-Suche [[Spezial:MultiCategorySearch]] fehlt. --JoKaene 18:08, 3. Mär 2022 (CET)

Die gibt es leider nicht mehr. Wir haben das schon irgendwo angesprochen, aber ich finde die Stelle gerade nicht.

Ersatzweise gibt es "Semantische Suche". Syntax z.B.: [[Kategorie:Personen]] [[Kategorie:Perry Rhodan Neo]], scheußlich, aber Besseres kann ich leider nicht bieten. --Klenzy (Diskussion) 19:23, 3. Mär 2022 (CET)

Schade! --JoKaene 19:45, 3. Mär 2022 (CET)

Echtwiki Software-Upgrade

Freitag, 28.01.2022, 11.00–12.30 Uhr möchte ich nun den fälligen Upgrade der Mediawiki-Software vornehmen (von 1.31 nach 1.35, vgl. Perrypedia:Wartung/Archiv_2020_-_2022#Testwiki_Software-Upgrade). Im selben Aufwasch werde ich versuchen, den vorigen Monat fehlgeschlagenen Datenbank-Upgrade von MySQL 5.7 nach 8.0 nachzuholen, 5.7 gilt als veraltet. Das kann ich vorab leider nicht testen, daher müssen beide Wikis (Echt & Test) in dieser Zeit offline gehen. --Klenzy (Diskussion) 11:32, 20. Jan. 2022 (CET)

Schon mal vorab: Heute morgen wollte ich im Testwiki einen Testlauf mit Spezial:Text ersetzen durchführen. Starten und Suchabfrage funktionierten; der Schalter Auswahl umkehren funktionierte nicht. Der Startschalter funktionierte scheinbar: Zunächst normales Verhalten (Seite wechselte), aber die Liste wurde nicht abgearbeitet. Falls das nicht auch an MySQL liegt weißt du schon mal Bescheid. --JoKaene 10:51, 26. Jan. 2022 (CET)

Auswahl umkehren ...: Funktioniert bei mir; lässt sich das Problem wiederholen?

Die Hintergrundverarbeitung läuft im Testwiki völlig anders. Kurz ausgeholt: Die Jobs werden ja erst einmal in eine Warteschlange eingereiht. Im Echtwiki behandelt der Apache-Webserver die Warteschlange. Jedesmal, wenn von außen irgendein Zugriff auf das Wiki erfolgt, wird mit einer gewissen Wahrscheinlichkeit (derzeit 50 %) zusätzlich zu der externen Anfrage genau 1 Hintergrundjob ausgeführt. Da wir täglich x-tausend Zugriffe haben, ist die Warteschlange zuverlässig bald abgearbeitet. Im Testwiki funktioniert das nicht, da kommen täglich vielleicht ein paar Dutzend Requests. Deswegen läuft von 8 bis 22 Uhr alle 20 Minuten ein Cronjob und arbeitet einen Teil der Warteschlange ab.

Aktuell werden zwar in der Siteinfo 60 ausstehende Jobs angezeigt, aber das stimmt nicht. Die Warteschlange ist leer, deine Ersetzungen müssten inzwischen fertig sein?

Ich schau mal, warum die Anzeige falsch ist.

Vorweg: Heute morgen war mein Versuch mit Tablet und Chrome.

Der Job ist nicht abgearbeitet, nicht einmal angefangen (leider nur hier ersichtlich).

Jetzt am PC funktioniert Auswahl umkehren. Ein erneuter Testlauf bringt jedoch wieder kein Ergebnis.

Jetzt vor dem Upgrade brauchst du dich aber nicht kümmern, ist nur das Testwiki. --JoKaene 11:58, 26. Jan. 2022 (CET)

Da war was. Der Cronjob hat nichts gemacht (und komischerweise keinen Fehler gemeldet), ein Überbleibsel meiner Experimente mit 2 PHP-Versionen. Jetzt habe ich das PHP-Problem behoben und bekomme wenigstens eine Fehlermeldung. --Klenzy (Diskussion) 12:04, 26. Jan. 2022 (CET)

Ein Teil ist jetzt durchgelaufen, einige hängen noch. --Klenzy (Diskussion) 15:07, 26. Jan. 2022 (CET)

Betriebssystemwechsel: Fehler und Probleme?

Hier ist der Platz für eure Berichte, wenn ihr Fehler findet oder den Eindruck habt, dass etwas nicht stimmt. --Klenzy (Diskussion) 12:11, 27. Dez. 2021 (CET)

PP nicht erreichbar

Die PP war heute gegen 12:05 Uhr nicht erreichbar, es kam zu einer Fatal_error-Anzeige. Der Aufruf der Spezialseite Letzte Änderungen ergab die Fehlermeldung, das die PHP-Extensions mbstring und xml fehlten. Seit 12:10 Uhr ist die PP wieder erreichbar. --GolfSierra (Diskussion) 12:14, 2. Jan. 2022 (CET)

Entschuldigung ... mein Fehler. Ich habe die PHP-Module für das Testwiki neu installiert. Das hatte dummerweise Auswirkungen auf das Echtwiki, die ich flugs behoben habe. --Klenzy (Diskussion) 12:33, 2. Jan. 2022 (CET)

Kein Problem, ich hatte mir schon sowas gedacht. Frohes neues Jahr, Klenzy! --GolfSierra (Diskussion) 12:38, 2. Jan. 2022 (CET)

Vorlage:UserCreates wird nicht aktualisiert

In Arbeit. --Klenzy (Diskussion) 08:01, 28. Dez. 2021 (CET)

Weitere PHP7.2-Module nachinstalliert, die gefehlt haben. Manueller Aufruf erfolgreich. Morgen werden wir sehen, ob auch die nächtliche Automatik wieder funktioniert. --Klenzy (Diskussion) 08:50, 28. Dez. 2021 (CET)

Behoben. --Klenzy (Diskussion) 09:01, 29. Dez. 2021 (CET)

Vorlage:Most Viewed wird nicht aktualisiert

Erstmals heute fehlen die Most-Viewed-Dateien. --JoKaene 07:33, 3. Jan. 2022 (CET)

Manuell importiert. Sollte ab heute Nacht wieder automatisch laufen. --Klenzy (Diskussion) 10:13, 3. Jan. 2022 (CET)

Hat geklappt, danke. --JoKaene 07:14, 4. Jan. 2022 (CET)

Zugriffsstatistik (Awstats) wird nicht aktualisiert

In Arbeit. --Klenzy (Diskussion) 08:51, 28. Dez. 2021 (CET)

Behoben, anscheinend waren es dieselben fehlenden Module wie bei den UserCreates. --Klenzy (Diskussion) 09:02, 29. Dez. 2021 (CET)

Spezial:RottenLinks wird nicht aktualisiert

In Arbeit. --Klenzy (Diskussion) 09:49, 29. Dez. 2021 (CET)

Das war ein Irrtum. Hat immer funktioniert. --Klenzy (Diskussion) 08:51, 26. Jan. 2022 (CET)

RSS-Feed

Aufruf der Seite Benutzer:JoKaene/Neue Seiten RSS schlägt fehl. Fataler Ausnahmefehler des Typs „DomainException“ --JoKaene 21:24, 28. Dez. 2021 (CET)

Behoben. Es war eine PHP-Einstellung verkehrt konfiguriert, an der ich jüngst testweise herumgefummelt habe. --Klenzy (Diskussion) 09:48, 29. Dez. 2021 (CET)

Betriebssystemwechsel

Es ist soweit: Ab Montag, 27.12.2021, möchte ich den Betriebssystemwechsel von Ubuntu 18.04 LTS -> 20.04 LTS durchführen. Notwendig ist das nicht, weil der Support für 18.04 bis April 2023 garantiert wird (LTS = long-term support), aber empfehlenswert. Für mich als Sysadmin steckt vor allem dahinter, dass sich der gleichzeitige Betrieb der unterschiedlichen PHP-Versionen nicht bewährt hat (7.2 für das Echtwiki mit der älteren Wikisoftware, 7.4 ist erforderlich für die Wikiverson 1.35/Testwiki). Ich möchte vor dem Update der Wikisoftware fürs Echtwiki auf PHP 7.4 vereinheitlichen. Damit entfallen für mich einige der aktuell nötigen Klimmzüge.
tl;dr: Für euch ändert sich nix. Unter der Haube wird der Motor ausgetauscht, außen bleibt alles gleich.
Beachtet bitte: Ich habe keine Ahnung, wie lange es dauern wird. 3 Stunden bis 3 Tage, alles möglich. --Klenzy (Diskussion) 09:43, 20. Dez. 2021 (CET)

Die jeweils neuesten Infos findet ihr dann in diesem Thread im PR-Forum. --Klenzy (Diskussion) 09:59, 20. Dez. 2021 (CET)

Macht Sinn so vorzugehen! Drück dir die Daumen. --Norman (Diskussion) 21:44, 21. Dez. 2021 (CET)

Fertig. Bericht folgt ... jetzt mache ich erst einmal Mittagspause.

Eure Meldungen bitte dort oben: Perrypedia:Wartung#Betriebssystemwechsel:_Fehler_und_Probleme?. --Klenzy (Diskussion) 12:19, 27. Dez. 2021 (CET)

Lagebericht: Wechsel des Betriebssystems auf Ubuntu 20.04.3 LTS abgeschlossen.

Um 9.30 Uhr sind wir vollständig offline gegangen. Download und Installation haben etwa 30 Minuten gedauert. Danach haben sich zwei kleine Hürden aufgetan. Erstens sind drei PHP-Module der alten Version 7.2 rätselhafterweise verschwunden. PHP ist die Programmiersprache, in der die Mediawiki-Software geschrieben ist und die für den Betrieb nötig ist (weil es keine Compilersprache, sondern eine Interpretersprache ist). Wir verwenden PHP 7.2 für das Echtwiki und PHP 7.4 für das Testwiki, weil die dortige neuere Mediawiki-Software 7.4 erfordert. Mehrere Versionen zu haben, ist ein wenig knifflig, aber nicht ungewöhnlich. Der Betriebssystemwechsel hat uns sogar eine weitere Versionen beschert, PHP8.0 ... daher keine Ahnung, weshalb in der 7.2-Version herumgepfuscht wurde. Ich habe die fehlenden Module neu installiert, Problem behoben.

Zweitens hat der Betriebssystemwechsel versucht, einen Upgrade der MySQL-Datenbank von 5.7 nach 8.0 zu erzwingen. Das ist gescheitert (sinngemäß "[...] post-install mit Fehlercode 2 beendet [...]"), MySQL musste ich komplett neu installieren und habe dafür die bisherige Version MySQL 5.7 beibehalten. Die neuere Datenbank ohne vorherige Erprobungsphase zu verwenden, ist mir zu riskant. In diesem Fall ist wenigstens der Grund für den zwangsweisen Upgrade erklärlich, MySQL 5.7 ist nicht/nicht mehr/noch nicht für Ubuntu 20.04 freigegeben. Mit einem kleinen Kniff konnte ich die Beschränkung umgehen, Problem behoben.

Seit 12.15 Uhr sind wir wieder online. --Klenzy (Diskussion) 17:01, 27. Dez. 2021 (CET)

Vielen Dank für deine Mühen! Bisher läuft alles prima. --Johannes Kreis (Diskussion) 18:09, 27. Dez. 2021 (CET)

Danke für diesen Einsatz. Prima, dass du auch die "kleinen Kniffe" zur rechten Zeit parat hast. --Norman (Diskussion) 08:22, 28. Dez. 2021 (CET)

Danke Dir für Deinen unermüdlichen Einsatz. Habe auch endlich mal wieder etwas Zeit zum Einsteigen. --Pisanelli (Diskussion) 13:49, 28. Dez. 2021 (CET)

Echtwiki & Testwiki Konfigurationsänderung

Am Mittwoch, 13.10.2021, 9 Uhr möchte ich eine notwendige Konfigurationsänderung in beiden Wikis vornehmen. Beide, Echtwiki und Testwiki, müssen gleichzeitig offline gehen für voraussichtlich nicht mehr als eine Stunde. --Klenzy (Diskussion) 21:17, 11. Okt. 2021 (CEST)

Ging leichter als erwartet. Heute Nachmittag mache ich mit dem Testwiki weiter (s. nächster Abschnitt). --Klenzy (Diskussion) 11:32, 13. Okt. 2021 (CEST)

Testwiki Software-Upgrade

Unsere Mediawiki-Version 1.31 gilt seit dem 1. Oktober als veraltet, der offizielle Supportzeitraum ist abgelaufen: siehe Tabelle. Das hat für uns zunächst keine Auswirkungen. "Support" ist sehr dehnbar, meine sämtlichen drei oder vier offiziellen Anfragen der letzten Monate wurden konsequent ignoriert. (Enttäuschend, aber nichts wirklich Wichtiges, daher juck. Das sind schließlich auch alles Freiwillige.) Ein letztes kleines Update gäbe es noch, von jetzt 1.31.15 auf dann 1.31.16. Da aber alles stabil und zufriedenstellend läuft (oder?), könnten wir problemlos auch dauerhaft auf 1.31 bleiben. Keine Notwendigkeit für einen Upgrade auf eine neue LTS-Version (Long Term Support).
Ich möchte aber zumindest einen Blick auf 1.35 LTS werfen und daher nächste Woche, voraussichtlich ab Montag (genau weiß ich noch nicht), die aktuelle 1.35.4 im Testwiki installieren. Einen Überblick über die Änderungen, Hunderte!, muss ich mir erst verschaffen, wenn ich mal Lust und Laune habe. Dreierlei Hinweise habe ich im Hinterstübchen:

• viele Änderungen/Verbesserungen der Benutzeroberfläche, vor allem auf Spezialseiten, auch mit neuen Selektionsmerkmalen;
• das Seitenvorschau-Popupfenster soll nun fest integriert sein (statt bisher zwei leicht wackligen Extensions, die wir bereits haben);
• der VisualEditor soll nun fest integriert sein (statt einer ziemlich wackligen Extension, die wir bisher nicht haben).

Nachdem der VisualEditor jahrelang in der Mediawiki-Community umstritten war, ist das jetzt ein klares Bekenntnis der Entwickler für die langfristige weitere Zukunft dieses Teils. Ob dieser VisualEditor für uns brauchbar ist, müssen wir ausprobieren. Anfang 2019 war er's noch nicht. --Klenzy (Diskussion) 16:21, 8. Okt. 2021 (CEST)

Ich habe keine Ahnung von Aufwand und Technik und kann Dir da nur vertrauen. Wäre aber schön, wenn wir irgendwann irgendwie wieder auf die aktuelle Version zurückgreifen können. Ich habe die Erfahrung gemacht, Updates zu ignorieren führt irgendwann zum ENDE :-) Aber wie gesagt, ich habe null Ahnung. Wenn Du Dich schlau machst - super, danke, danke, danke!!! --Pisanelli (Diskussion) 16:30, 8. Okt. 2021 (CEST)

Das ist mein Job hier. --Klenzy (Diskussion) 17:06, 8. Okt. 2021 (CEST)

Das Testwiki geht jetzt offline. --Klenzy (Diskussion) 15:47, 11. Okt. 2021 (CEST)

Na schön, der erste Versuch ist ausgegangen wie das Hornberger Schießen. Für Mediawiki 1.35 benötigen wir eine neuere PHP-Version. Bei der jetzigen Konfiguration des Apache-Webservers kann ich keine zwei PHP-Versionen parallel betreiben. Ich muss zuerst die Apache-Konfiguration anpassen, im Echtwiki und im Testwiki gleichzeitig. Das ist hoffentlich nicht allzu schwer. Ich plane die Änderung für Mittwoch, 9 Uhr. --Klenzy (Diskussion) 21:12, 11. Okt. 2021 (CEST)

Das Testwiki bleibt vorerst offline. Fehler in der Wikisoftware, ich hänge beim Support in der Warteschleife. --Klenzy (Diskussion) 10:05, 15. Okt. 2021 (CEST)

1.35.4 läuft im Testwiki, hier geht es zur Diskussion: Perrypedia:Verbesserungsvorschläge/Archiv 2020 - 2022#Neue_Wikisoftware_1.35_im_Testwiki. --Klenzy (Diskussion) 11:21, 19. Okt. 2021 (CEST)

Nächtlicher Neustart (testweise)

Ich möchte ausprobieren, ob und wie sich ein täglicher Neustart des Servers auswirkt. Ab der nächsten Nacht wird jeweils um 01:25 Uhr ein Reboot durchgeführt, Dauer etwa 2 bis längstens 4 Minuten. Ich bitte vorauseilend um Verzeihung, wenn was schief läuft ... --Klenzy (Diskussion) 09:09, 23. Sep. 2021 (CEST)

Zufälliges Nebenergebnis: Infolge des nächtlichen Neustarts läuft die vollständige Datensicherung zuverlässig innerhalb eines Zeitrahmens von nur mehr 30 bis 40 Minuten. Superb! --Klenzy (Diskussion) 20:56, 14. Okt. 2021 (CEST)

Testwiki wird aktualisiert 09/21

Das Testwiki ist wieder einmal sehr veraltet. Ich möchte daher ab Mittwoch, 22.09.21 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 Mittwoch früh Zeit dafür. Gibt's Einwände? --Klenzy (Diskussion) 12:25, 19. Sep. 2021 (CEST)

Nee, nix dagegen – ganz im Gegenteil. --JoKaene 12:38, 19. Sep. 2021 (CEST)

Begrüsse das auch! keine Einwände. :-) --Norman (Diskussion) 14:37, 19. Sep. 2021 (CEST)

Das Testwiki geht in wenigen Minuten offline. --Klenzy (Diskussion) 10:50, 22. Sep. 2021 (CEST)

Testwiki ist jetzt auf dem Stand vom 22.9.21, 0:14 Uhr. --Klenzy (Diskussion) 15:56, 22. Sep. 2021 (CEST)

:-) Danke! --JoKaene 17:32, 22. Sep. 2021 (CEST)

Echtwiki Software-Upgrade

Ich möchte am Freitag, 2.07.2021 ab 10:00 Uhr einen Software-Upgrade im Echtwiki durchführen (Mediawiki 1.31.15). Dafür müssen wir offline gehen: Dauer der Unterbrechung bis zu 60 Minuten. --Klenzy (Diskussion) 12:37, 30. Jun. 2021 (CEST)

Es scheint ja alles geklappt zu haben. Danke für deinen Einsatz. --Norman (Diskussion) 11:00, 2. Jul. 2021 (CEST)

Ja, alles erledigt.

Im Herbst wird es dann Zeit, sich Gedanken über einen Umstieg auf 1.35 zu machen. Hier [4] sieht man schon einmal grob die Highlights. --Klenzy (Diskussion) 11:26, 2. Jul. 2021 (CEST)

Ja, vielen Dank! --Pisanelli (Diskussion) 11:56, 2. Jul. 2021 (CEST)

Auch von mir ein Dankeschön, Klenzy!--Zoltar (Diskussion) 14:38, 2. Jul. 2021 (CEST)

Nicht dafür. Der nächste Wechsel wird aufwendiger. --Klenzy (Diskussion) 16:06, 2. Jul. 2021 (CEST)

Echtwiki Software-Upgrade

Ich möchte am Montag, 12.10.2020 (Nachtrag:) um 10:00 Uhr den Software-Upgrade im Echtwiki nachziehen (Mediawiki 1.31.10, SMW 3.2). Dafür müssen wir offline gehen: Dauer der Unterbrechung ca. 15 bis 45 Minuten. --Klenzy (Diskussion) 16:55, 9. Okt. 2020 (CEST)

Hallo Klenzy. Hast Du eine ungefähre Uhrzeit?--Jenka (Diskussion) 09:01, 12. Okt. 2020 (CEST)

Oha, habe ich vergessen anzugeben ... dabei hätte ich schwören können ...

Danke für den Hinweis! --Klenzy (Diskussion) 09:10, 12. Okt. 2020 (CEST)

Testwiki Software-Upgrade

Ich installiere im Testwiki die neue Mediawiki-Version 1.31.10, die mehrere Sicherheitslücken schließt. Das Testwiki geht kurz offline. --Klenzy (Diskussion) 14:49, 9. Okt. 2020 (CEST)

"Kurz", naja ... das Testwiki ist wieder da. --Klenzy (Diskussion) 15:41, 9. Okt. 2020 (CEST)

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)