Nun muss ich sagen, dass ich bis zu diesem Freitagmorgen noch nichts von MySQL-Replikation gehört hatte.
MySQL-Replikation ist - sehr vereinfacht gesagt - eine Art Kopiervorgang von einem MySQL - Master - Server auf einen oder mehrere mit dem verbundene MySQL- Slave - Server. Man kann sich das wie ein weiteres Laufwerk vorstellen, auf den jeder MySQL-Befehl (in binärer Form) rüber kopiert wird, der auf dem jeweiligen Master-Server ausgelöst wird. Ergänzend hat jeder Befehl eine fortlaufende Nummer, anhand dessen der Slave mit dem Master kommuniziert, bis zu welchem Stand er die Kopie besitzt. Vorteile von MySQL-Replikation sind grob eine höhere Geschwindigkeit und - eigentlich - eine höhere Ausfallsicherheit. Jedenfalls, so lange nicht händisch in diesen Vorgang eingegriffen wird bzw. etwas ihn stört.

Den kompletten Freitag verbrachte ich ganz überwiegend damit, überhaupt erst einmal heraus zu finden, was das Problem ist, also warum ipernity nur noch im Lesemodus ist. Dafür galt es, unzählige Logfiles auf den diversen Servern zu analysieren und zu verstehen, wie diese Server untereinander vernetzt sind und einander bedingen.

Gegen Freitag Nachmittag war mir klar, was das Problem war, und grob auch, wie das Problem möglicherweise zu beheben sein könnte. Ich war mir aber noch nicht komplett sicher und schrieb daher am Freitagabend um 20:18 Uhr folgendes auf Twitter als Antwort auf die Störungsmeldung von ipernity: Zu dem Zeitpunkt war längst klar, dass Qwellcode nicht mehr an diesem Freitag an die Fehlersuche gehen würde. Und sicher auch nicht vor Montagmorgen, 9 Uhr.
Ich hatte also das restliche Wochenende Zeit, möglicherweise ein wenig Geld für ipernity einzusparen und mich weiter in das Thema einzulesen, die Serverarchitektur zu verstehen und möglicherweise selbst das Problem gelöst zu bekommen - da von außen bis zum Montagmorgen ohnehin nichts möglich war.


Ich verbrachte große Teile der Nacht von Freitag auf Samstag und den kompletten Samstag dann damit, mich weiter in das Thema MySQL-Replikation einzulesen. Mich darüber zu informieren, worauf bei einer derartigen Fehlermeldung besonders zu achten ist. Und wie das bei ipernity und der von ipernity verwendeten Serverarchitektur möglicherweise zu lösen ist. Dabei galt dann auch noch darauf zu achten, dass die von ipernity verwendeten Programmpakete auf den Servern alles sind - aber nicht aktuell. Ganz und gar nicht aktuell. Sie sind, um es deutlich zu sagen - hoffnungslos veraltet. Die Schreiber von Anleitungen, die schreiben, wie man den auftretenden Fehler behebt, gehen natürlich davon aus, dass wenigstens ansatzweise aktuelle Programmversionen verwendet werden.
Meine Recherche bestand also auch darin, heraus zu finden, ob die vorgeschlagenenen Lösungswege überhaupt mit entsprechend alter Software in der Form möglich sind - also ob die entsprechenden Befehle in der Programmversion, die ipernity nutzt, überhaupt schon dort implementiert waren. Nicht in allen Fällen war das der Fall, einige Anleitungen zur Problembehebung setzten ganz offenkundig Befehle ein, die es in der damaligen Programmversion, die ipernity noch immer verwendet, noch gar nicht gab.
Gegen Samstagmittag bzw Samstagnachmittag hatte ich eine mögliche Lösung parat, die funktionieren könnte. Ja, könnte, denn wirklich sicher war ich mir zu dem Zeitpunkt noch nicht.

Und ich muss sagen - gegen Samstagmittag sank meine Motivation ziemlich, da weiter Untersuchungen durchzuführen und das ganze (neue) Wissen in mich hinein zu prügeln.
Grund dafür war dieser Thread in einem Diskussionsforum bei Flickr, auf den ich Samstag gegen Mittag hingewiesen wurde, und den ich nachmittags dann während einer kurzen Kaffeepause dann las.
Dort geht es zunächst um den längeren Ausfall, den ipernity im Dezember 2019 hatte (was vor meiner Amtszeit als ipernity-Webmaster lag), der aber Ansichten einiger Clubmitglieder offenbarte, die mich einfach nur fassungslos und auch ein wenig wütend werden liessen, weil er im Folgenden auch meine Amtszeit und mich als Person betrifft bzw. mir Lügen unterstellt.

Ich füge dazu jetzt mal ein 13 Screenshots der dortigen Diskussion in diesen Artikel ein. Lest euch das dort geschriebene mal durch. Das gesagte befindet sich in der jeweiligen Bildbeschreibung, damit es für alle mit deepl problemlos zu übersetzen ist:



Den Sonntag verbrachte ich dann damit, über eine ssh - Verbindung zu versuchen, von allen Datenbanken ein Sicherheitsbackup zu ziehen, um die durch mich geplante Korrektur der Datenbanken vorzubereiten. Das funktionierte aus vielerlei Gründen für mich nicht. Um nur einige Gründe zu benennen, warum es nicht gelang, eine Kopie der Datenbank auf meinen Rechner zu ziehen: Zu geringer Plattenplatz auf den betroffenen Servern für einen MySQL-Dump direkt dort als per sudo su zum root gemachten normalen User. Der Versuch, mich stattdessen über eine ssh pipe auf den Server einzuloggen, um nicht erst die Datenbank-Kopie auf dem dortigen Server zu speichern und sie dann von dort herunter zu laden scheiterte an dem nicht Vorhandensein eines User-Passworts für einen User, der Leserechte an der MySQL-Datenbank hat. Es gibt lediglich für einen User mit einfachen Rechten einen Zugang, mit dem wir uns auf dem Server einloggen, dieser hat allerdings weder Lese- noch Schreibrechte für die Datenbank. Um direkt von der Datenbank lesen zu können, wird sich per "sudo su" zum root-User gemacht. Da von dem aber kein Passwort bekannt ist, ist damit (meines Wissens nach) kein Login per ssh-Pipe auf den Servern möglich, um ohne Zwischenspeicherung auf der zu kleinen Serverplatte die Kopie direkt auf meinen Rechner zu übertragen. Die Suche nach einem User ohne Passwort oder nach einem User mit irgendwo in einem File hinterlegten Passwort mit Leserechten für den MySQL-Server verlief erfolglos.

Aus diesem Grund brach ich dann am Sonntagabend meine weiteren Untersuchungen für den geplanten Rettungsversuch ab. Stattdessen stellte ich alles, was ich bis dahin an Informationen über den Zustand der ipernity-Server zusammen gesammelt hatte inklusive verschiedener möglicher Lösungswege für Markus von Quellcode zusammen, damit er dann direkt mit der Problembehebung starten kann - ohne wieder bei Null anfangen zu müssen.

Da ich wusste, dass ich unter diesen Umständen (es wird ipernity etwas kosten) und aufgrund der unerfreulich geführten Diskussion bei flickr noch schlechter schlafen würde als schon in den Nächten zuvor, schrieb ich am Sonntagabend dann noch die Zusammenfassung des Wochenendes, und was ich unternommen hatte, und postete diese auf pastebin.com (denn hier bei ipernity ging es halt noch nicht). Dort schrieb ich auch nochmal genauer, was der Hauptgrund dafür war, der mich davon abhielt, die Datenbank zu reparieren. Und ich schrieb was darüber, wie die Server von ipernity miteinander vernetzt sind und miteinander kommunizieren - was letztlich dann der Grund dafür war, dass praktisch gar nichts mehr möglich war, was Schreibrechte in der Datenbank erfordert. Bzw. es war möglich, wurde aber nicht mehr umgesetzt, sondern lediglich in die Warteschlange der noch abzuarbeitenden MySQL - Befehle hinten eingereiht.
Diesen entsprechenden Text - ich nannte ihn "Des ipernity Webmasters Wort zum Sonntag" in Anlehnung an eine kirchliche Sendung im Deutschen Fernsehen könnt ihr in deutsch, englisch und auf französisch auf der pastebin.com- Webseite nachlesen - auf ipernity konnte ich ihn ja leider gerade nicht schreiben. Also, ihr könnt ihn da nachlesen - jedenfalls, sofern inzwischen die pastebin - Webseite wieder funktioniert, denn auch die war offline:


Es ist doch schön zu sehen, dass nicht nur ipernity.com solche Probleme hat, sondern auch Webseiten, für die bezahlte Profis arbeiten. ;-)

Auch diese Information vom Sonntagabend verteilte ich dann wieder so breit, wie es mir eben möglich war. Also als weitere Antwort unter dem ipernity - Twitter - Posting zur Störung, in der besagten flickr - Diskussionsgruppe, im ipernity- Discord-Channel und - nun hatte ich ja genug Zeit für so was - sogar auch noch bei Facebook. Obwohl ich Facebook nun wirklich nicht mehr nutze...

Wie auch immer, Sonntagabend stellte ich dann noch alle Informationen zusammen, die ich bis dahin gesammelt hatte und schickte das mit einigen möglichen Lösungswegen an Markus von Qwellcode.
Die von Qwellcode hatten zum Glück direkt am Montagnachmittag einen Slot für uns frei, so dass er direkt mit der Reparatur der Datenbanken beginnen konnte. Er erstellte hierfür für das Sicherheits-Backup der Datenbank übrigens eine neue Serverinstanz bei Amazon Web Service - somit hatte er dann genügend Festplattenplatz zur Verfügung, um die komplette ipernity-Datenbank dort zu speichern.
Warum ich das nicht auch so tat? Weil ich von AWS noch weniger weiß wie von MySQL-Replikation vor dem fraglichem Wochenende.
Und ohne ein Sicherheitsbackup der kompletten Datenbank wollte ich nicht irgendwelche Versuche unternehmen, nicht bei dem Serveraufbau, den ipernity hat. Aber zum Serveraufbau und warum der so kompliziert ist (und welcher Punkt mich dabei besonders abschreckte bzw. irritierte) schrieb ich ja im Wort zum Sonntag was.
Dann musste nur noch der Fehler behoben werden (so grob, wie in den von mir gefundenen Anleitungen, aber halt nur so grob, weil die Architektur bei ipernity deutlich komplizierter ist wie in den Anleitungen) und die Server ihre Warteschlange abarbeiten. Nur als kurze Info: Die Slaveserver waren teilweise, nachdem sie wieder liefen, arbeitsrechnisch 18 Stunden hinterher. Normalerweise sollten MySQL-Slave-Server lediglich wenige Sekunden hinterher sein - wenn überhaupt. Im Idealfall wird natürlich jeder Befehl, der auf dem Master ausgeführt wird, sofort auf den Slave rüber kopiert, was zu einer Latenz von weniger als einer Sekunde führt.

Entsprechend der langen Warteschlange, die - obwohl die Server bereits wieder fehlerlos arbeiteten - im Laufe des Dienstags zwischenzeitlich sogar nochmal länger statt kürzer wurde (bedingt durch die vielen Tests vieler User, was denn nun schon funktioniert und was nicht), dauerte es auch noch bis zum Dienstagnachmittag, bis alles wieder gesynct war und funktionierte. Die eigentlichen Arbeiten an den Servern waren am Montag wohl dann weitestgehend abgeschlossen, den Rest mussten dann die Server unter sich ausmachen.

Es gab also faktisch rund zwei bis maximal drei Arbeitstage lang einen Ausfall. Also in dem Fall, dass ihr von professionellen Datenbankspezialisten ausgeht. Und nur von tatsächlichen Arbeitstagen ausgeht, an denen ein Mensch was tat, was über "überwachen des rückkehrens der Server" hinaus geht.
Was mich angeht war es ein verdammt anstrengender Freitag und ein Wochenende, was ich ausschliesslich am Rechner verbrachte, mit Ausnahme von kurzen Pausen zum Essen. Und viel besser sah es dann auch ab Montag nicht mehr aus, denn das Gefühl, nun nur noch auf andere warten zu können machte es nicht besser. Na gut, ihr hattet das bereits seit Donnerstagnacht.

Aber was ich mir für die Zukunft wünsche: etwas weniger demoralisierende Statements auf irgendwelchen Plattformen. Ich tue alles, was mir möglich ist - im Zweifel sogar fast rund um die Uhr - um ipernity am Laufen zu halten. Andere arbeiten ebenso hart daran, die Userbasis zu vergrößern, die Webseite zu verbessern (da steige ich wie woanders geschrieben ja nun auch so langsam ein) oder andere Dinge für ipernity zu tun. Und Statements, dass ihr euren Clubbeitrag ja bezahlt und dafür "wenigstens eine angemessene Informationspolitik durch das Management" erwartet - nun - ich bin nicht euer Management und möchte es auch nicht sein.
Ich bin Fotograf, der ebenso seinen Mitgliedsbeitrag bezahlt und nebenher vielleicht auch noch weitere Dinge übernimmt. Ich erwarte keine Dankbarkeit dafür, dass ich mir die Stunden mit der ipernity-Webseite um die Ohren schlage. Ich tue das freiwillig, und ich wusste, was auf mich zukommt. Na gut, nein, ich wusste es nicht, und hätte ich es gewusst, ich hätte vielleicht eine andere Entscheidung getroffen. Aber es macht mir Spass. Auch jetzt noch. Und auch an Tagen wie am vergangenen Wochenende - denn ich lerne gerne neue Dinge hinzu.

Aber gelegentlich wäre etwas mehr Geduld angebracht. Und Verständnis dafür, dass wir alle das hier nur nebenher machen und auch noch andere Dinge zu tun haben. Das mein Wecker nicht an eine Systemüberwachung gekoppelt ist, die sofort einen Alarm auslöst, wenn auf dieser Webseite irgendwas mal nicht funktionieren sollte. Und ich erwarte es, dass immer mal wieder irgendwelche Dinge passieren werden, die zu Problemen führen. Das lässt sich gar nicht vermeiden bei einer so veralteten Software, die technisch nicht mehr aktualisiert werden kann. Und vielleicht auch etwas Verständnis dafür, dass man sich bei Problemen zunächst einmal ganz prioritär darum kümmert, das Problem zu lösen - und die Kommunikation dann mehr teamintern abläuft, als nun allen Vereinsmitgliedern jeweils zu erzählen, was gerade aktuell unternommen wird.

Da muss es dann auch mal reichen, wenn einen Tag lang die Information nur aus "Wir sind uns des Problems bewusst und arbeiten an der möglichst schnellen Behebung" lautet. Und eben nicht stündlich ein Update kommt, was aktuell gerade gemacht wird. Auch nicht alle vier Stunden, auch nicht alle acht. Sondern dann, wenn es etwas zu berichten gibt. Also beispielsweise jetzt, wo das Problem wieder behoben ist.

Wer zeitnah mehr wissen möchte, was das Problem ist, darf gerne Teil des Teams werden und sich dann darum kümmern, mit den anderen Vereinsmitgliedern in den Austausch zu gehen, was genau das Problem jeweils ist und was gerade unternommen wird, um das Problem zu beheben. Ich zumindest werde auch zukünftig primär an Problemlösungen arbeiten statt Krisenkommunikation zu betreiben. Das beherschen andere ohnehin viel besser wie ich.

Bleibt gesund! Und überlegt, wie ihr selbst ipernity voran bringen könnt! Im Zweifel hilft es manches Mal schon bei einer Problemlösung, vielleicht einfach mal gar nichts zu sagen statt die noch motivierten Helfer zu demotivieren...

Also ganz so, wie es uns die ipernity - Server während der Störung sagten, als sie sagten, dass wir eigentlich ja gar nichts sagten, aber doch irgendwie etwas sagten, worauf irgendjemand reagiert hätte oder eben auch nicht. ;-)