Troet.Cafe & Muenchen.Social Leben - ein Update #TroetCafeLebt
Heute wurden die ersten Schritte zur „Rettung“ der Instanz besprochen und ein Team gegründet: Das Team Troet.Cafe.
Martin wird weiterhin Admin und Leiter seiner Instanzen bleiben, aber wir werden bei Updates und SysAdmin Aufgaben unter die Arme greifen.
Wir haben das Problem am Update verstanden und Logs mit den Fehlermeldungen werden uns bald übermittelt. Diese werden von unseren FISIs analysiert sowie an Postgresql/Datenbank Experten (ja, sowas gibt es wirklich) weitergegeben.
Niemandem wurde Zugriff auf sensible Daten gegeben. Was wir planen läuft nach allen Regeln der Kunst und eure Daten sind sicher.
Dies sind die ersten Schritte und der Fortschritt wird langsam sein. Kein Herunterfahren muss mehr befürchtet werden, zudem wird troet.cafe sowie muenchen.social in der Zukunft einen weitaus höheren Bus-Faktor haben (heißt, dass es keine one-man-show mehr sein wird und wir alle einander unterstützen und helfen falls eine Person nicht mehr kann)!
Danke an die Tröt-Community und eure Unterstützung! Dank eurem vielen Zuspruch und Hilfsbereitschaft hatte Martin die Motivation doch weiterzumachen, wirklich! Gebt euch selbst einen Klopfer auf die Schulter, troet.cafe und muenchen.social werden bleiben, uns alle macht dieser Fakt sowie das Feedback aus der Community sehr sehr glücklich.
Es geht los! Viel Durchhaltevermögen troet.cafe und muenchen.social!
Der Exakte Plan
Exakt gleichen Datenbank Cloud-Server bestellen wie für troet.cafe und muenchen.social. (CPX31 | x86 | 160 GB | eu-central)
Alle muenchen.social Server herunterfahren.
Die Datenbank vom muenchen.social Datenbankserver exportieren und zum neuen Cloud-Server übertragen.
Alle muenchen.social Server wieder hochfahren.
Postgresql auf der neusten (mit Mastodon kompatiblen) Version auf dem neuen Datenbank-Server aufsetzen.
Einen Weg finden den Datenbank-Export von muenchen.social zu importieren.
Alle Server wieder herunterfahren.
Schritte 1-5 wiederholen.
Den gefundenen, funktionierenden Weg in Echt mit der Live-Datenbank durchführen ohne die alten muenchen.social Server wieder hochzufahren.
muenchen.social Web- und Worker-Server umstellen um mit neuer Datenbank zu funktionieren.
muenchen.social Web- und Worker-Server auf neuste Mastodon Version updaten.
All das mit troet.cafe wiederholen.
Antwortet gerne auf diesen Beitrag wenn ihr Hilfe zum Thema postgresql Datenbanken (Umstellung des Datenbank-Schemas) anbieten könnt, dann melden wir uns bei euch direkt wenn wir nicht weiterkommen!
Kleine Änderung: wir mussten aus persönlichen Gründen das Datum um eine Woche nach hinten verschieben. Am 11. und 12. Mai finden nun die großen Umbauten an muenchen.social und troet.cafe statt! Danke für euer Verständnis :ablobcatheartsqueeze:
Eine lange Sendepause... wurde troet.cafe und muenchen.social nun aufgegeben? Nein! Wir haben mehr denn je im Hintergrund gearbeitet und endlich ein Datum für das Beheben aller Fehler auf beiden Plattformen festgelegt:
📅 11. Mai & 12. Mai 2024 🕛 08:00 — 22:00 Uhr 📍 Eine Instanz in deiner Nähe
Das wird das Wochenende sein an dem wir troet.cafe und muenchen.social mit den neusten Servern, neusten Sicherheitsstandards und natürlich auch neuster Mastodon-Version neu-aufsetzen. Selbstverständlich bleiben alle Beiträge und Accounts erhalten. Sobald wir wieder online gehen ist alles so wie zuvor, nur mit den neusten Features und Design!
Wir haben Wege gefunden so viel Arbeit wie möglich von Martin abzunehmen, arbeiten als Trio recht gut zusammen und haben einen Plan für die zukünftige geteilte Administration der Plattform, damit so ein Rückstand nie wieder aufkommen kann! Das ist gar keine Kritik an Martin, keineswegs, Ich bin eher erstaunt das es für über 6 Jahre als one-man-show ohne Probleme funktioniert hat. Facebook hatte nach 6 Jahren 1.218 vollzeitbeschäftigte Mitarbeitende, nur so...
Für Zukunftspläne ein Geheimnis: 💻♻️🫂 ;)
Wie Ich anfangs gesagt habe: diese Aufgabe ist keine Operation die eine Nacht lang geht, sondern ein Marathon. Wir haben dieses Jahr schon viele Eckdaten geplant und realistische Ziele gesetzt und werden euch so gut es geht bei Laune halten!
Selbstverständlich werdet ihr nochmal vor dem Wochenende benachrichtigt, denn es wird während des Zeitraums Momente geben in denen diese Mastodon Server nicht erreichbar sind, oder andere Probleme aufkommen. Es kann auch sein das für diese zwei Tage der Dienst vollkommen eingestellt bleibt, was wir natürlich versuchen werden so gut es geht zu vermeiden.
Mein, oder eher unser Ziel ist es, Troet.Cafe und Muenchen.Social in der Funktionsweise, die Dinge die Menschen lieben und für die sie auf die Plattformen gekommen sind, darunter auch die Leitung von Martin, niemals zu ändern, jedoch strukturelle Änderungen in der Administration und Moderation vorzunehmen, durch das diese Plattformen langfristig funktionieren können.
Das erhoffen wir mit euch zusammen zu erreichen! ❤️ 🎉
Es gibt gleich zwei neue Versionen (v4.1.14 & v4.1.15) wegen zwei neuen Sicherheitslücken! Dieses Mal haben wir nicht lange gewartet und wenige Stunden nach der Veröffentlichung schon alles up-to-date gehabt.
Mit „wir” meine Ich dieses Mal komplett alleine Martin @martinmuc und Nick @freestyle! Ich habe kein bisschen geholfen, also geht jeglicher Lob an sie!
Naja, die anderen Male saß Ich auch nur daneben und sah bestenfalls schön aus, aber dieses Mal kann man nicht mal das behaupten! Haha. Aber Spaß beiseite, die beiden haben immer super Arbeit geleistet – zudem können Nick und Ich jetzt unabhängig Updates auf troet.cafe und muenchen.social machen, heißt es hängt nicht mehr alles alleinig von Martin ab :ablobcatheartsqueeze:
Das nimmt ihm natürlich viel Stress und erlaubt es uns die Last aufzuteilen!
Ich bitte zudem um aufrichtige Entschuldigung bei allen Instanzen die auch von uns aus Spam erfahren mussten - es hat Zeit gebraucht das Problem zu erkennen, von uns aus zu lösen, und dann so nachhaltig zu lösen das auch unsere User nicht mehr betroffen waren. Deshalb muss Ich auch @FanCityKnits und @catflyhigh als Café-Helfer:Innen des Monats auszeichnen für die tolle Report-Arbeit über die wir live genau erkennen konnten von wo der Spam kam. Ohne euch wäre der heutige Tag weitaus stressiger gewesen! :ablobcatheartsqueeze:
Wir haben muenchen.social und mit etwas Überzug troet.cafe nach 18:00 Uhr erfolgreich auf Version 4.1.13 ge-updated! Die Sicherheitslücke ist somit gelöst, niemand muss sich mehr um dessen Account Sorgen machen!
Nicht nur ist alles reibungslos gelaufen, sondern haben Nick, Emily, und Ich in diesem 3 Stunden Meeting gelernt wie die Infrastruktur von troet.cafe sowie muenchen.social aufgebaut ist und könnten somit zukünftig solche Updates selbst machen. Zeitgleich haben wir angefangen eine Dokumentation zu schreiben welche die Wissensweitergabe auch nachhaltig versichert.
Auch wenn es sehr kurzfristig zusammengekommen ist, war es ein massiver Erfolg! :ablobcatheartsqueeze:
Die Updates um die momentanen Sicherheitslücken zu schließen werden wir versuchen Morgen, Samstag den 03.02.2024 um 16:00 - 18:00 Uhr einzuspielen. Von v4.1.9 auf v4.1.13, Version für Version. Für diesen Zeitraum können troet.cafe und muenchen.social offline sein. Nach diesem Zeitraum gibt es das Sicherheitsproblem hoffentlich nicht mehr und niemand muss sich um seinen Account, sowie die Sicherheit seiner Daten, Sorgen machen.
Martin, Nick, und Ich haben soeben gemeinsam in einem Telefonat herausgefunden ob diese Version 4.1.13 weiterhin kompatibel mit der problematischen Datenbank ist (das ist sie), weshalb uns wahrscheinlich das Update erleichtert wird. Das Problem in der Vergangenheit waren Fehler beim Updaten der Datenbank, da wir diese hierbei nicht Updaten müssen, bleibt uns einiges an Arbeit hoffentlich erspart. Wir haben einen Plan überlegt wie wir das ganze angehen werden und alle Eventualitäten durchdacht, es ist also möglich, dass Dinge dennoch schiefgehen, doch auch dafür haben wir einen Plan B.
Dies wird das erste Mal sein das wir zusammen arbeiten, was, auch wenn es nicht ganz in dem Rahmen geschieht in den Ich es mir gewünscht hätte, zur Wissensweitergabe sowie nachhaltigen Aufgabenverteilung und Wissensaufbereitung führt. Zum Beispiel erstellen wir zeitgleich mit der Updatedurchführung eine sogenannte „Documentation” / Dokumentation. Diese erklärt sehr ausführlich alles vom Aufbau der Instanz und Server. So könnten zukünftig Menschen, die noch nie an der Instanz gearbeitet haben, uns dennoch helfen und es würde weitaus weniger Abhängigkeit von einzelnen Personen existieren. Das Wissen bleibt erhalten und aufbewahrt, kein Druck und Stress liegt auf einer Person mehr, so das Ziel.
Da Martin bisher alles alleine gemacht hat haben wir bisher keine Ahnung wie die Server funktionieren oder aufgebaut sind. Jede Person hat da so deren Art Dinge zu tun; als Fremde dort einzusteigen wäre sehr schwierig und wir würden wahrscheinlich dennoch oft auf Martin's Hilfe zurückgreifen müssen, selbst wenn wir es „alleine” versuchen würden. Deshalb muss der erste Termin einer sein der Martin passt, ggf. auch der Zweite, wahrscheinlich auch der Dritte! Jedes Mal heißt aber weniger Arbeit für und Abhängigkeit von Martin. Jedes weitere Mal bedeutet immer größere Aufgaben die wir übernehmen können und er nicht mehr beachten muss.
Auch wenn es aus einer Notlage heraus ist freue Ich mich auf die Zeit morgen mit Martin und Nick, denn dann beginnt der erste Schritt dieses eigentlich sehr schönen Prozesses! ❤️ :coffefied:
Wie viele von euch sicherlich mitbekommen haben macht gerade ein Heise Online Artikel über Sicherheitslücken in Mastodon die Runden. In diesem Artikel wird erwähnt, dass Mastodon Server der folgenden Versionen von diesen Sicherheitslücken betroffen sind:
3.5.16 und älter,
4.0.12 und älter,
4.1.12 und älter,
4.2.4 und älter.
troet.cafe und muenchen.social sind auf der Version 4.1.9, was bei „4.1.12 und älter” mitgemeint ist.
Zudem ist die genaue Sicherheitslücke bisher noch geheim — die Chance, dass etwas passiert ist also gering.
Nun hatten Martin und Ich uns eigentlich mehr Zeit erhofft um Updates ohne Fehler sowie die Zugänge zu den Servern DSGVO-Konform umzusetzen. Letzte und diese Woche haben treffen stattgefunden um die Logs zu analysieren, es wurden Erklärungen geschrieben damit nachvollzogen werden konnte wie diese Logs eigentlich zu stande gekommen sind und viele Erkenntnisse über mögliche Lösungsansätze gewonnen. Eine Übergabe von Serverzugriffen habe Ich bisher jedoch abgelehnt da Ich uns nicht aufdringen und Martin die Kontrolle entnehmen wollte, sowie sicherstellen wollte, dass jede Person von troet.cafe und muenchen.social erstmal weiß was passiert, mich kennt und von uns gehört hat. Eine zwar nicht Übernahme aber schon große Abgabe von Kontrolle scheint mir andernfalls sehr intransparent, ihr sollt ja wissen wer Ich bin, was passiert, und lange genug Zeit haben um ggf. ein Problem mit dieser Entwicklung zu haben.
Naja, nun gibt es eine Sicherheitslücke und das heißt ganz und gar nicht das Grundsätze der Transparenz über Bord geworfen werden sollten, eher im Gegenteil (deshalb, dieser Beitrag), jedoch das wir für den Moment zusammenkommen müssen um den Plan kurzfristig zu ändern um diese Sicherheitslücke zu schließen.
Was heißt das konkret? Die Update-Versuche welche bei troet.cafe und muenchen.social in den letzten Monaten versucht wurden bezogen sich immer auf ein Update auf eine viel höhere Version von Mastodon (>4.2.x), da kann auch mehr schiefgehen. Die Versionen der beiden Instanzen sind momentan 4.1.9, und jede Version unter 4.1.12 ist, wie oben benannt, betroffen. Es gibt zum schließen dieser Sicherheitslücke jedoch seit kürzester Zeit auch die Version 4.1.13, was von unserer Version 4.1.9 ggf. leichter zu erreichen, und ohne Fehler zu Updaten ist. Dies würde zwar den eigentlichen Plan durcheinanderbringen, ggf. die über die letzten Wochen geteilten und analysierten Logs sowie deren Auswertung sinnlos machen, dafür aber das akute Problem lösen, also die User von troet.cafe und muenchen.social schützen. Das liegt uns selbstverständlich am meisten am Herzen und wird so schnell es geht umgesetzt — da es den Plan etwas durcheinanderwürfelt sowie durch mein Ablehnen der Zugänge zu den Servern die gesamte Abhängigkeit wieder an Martin allein liegt, bitten wir um Verständnis, dass das ganze nicht so schnell stattfindet wie es stattfinden sollte.
Der Plan unserer Gruppierung, die gesamte Idee warum Martin und Ich zusammenarbeiten sowie das Team Troet.Cafe existiert, ist damit so etwas nie wieder geschieht. So eine Abhängigkeit von einer einzelnen Person sowie der damit einhergehende Druck nicht mehr existiert und Probleme schneller, professioneller, transparenter und vertrauenswürdiger gelöst sowie angegangen werden. Dieser Prozess braucht Zeit, Vertrauen, Einarbeitung, etc. Alles Dinge die wir leider jetzt nicht haben!
Nachdem die Sicherheitslücke geschlossen ist geht dieser Prozess jedoch weiter um den eigentlichen Plan, also das Durchführen der größeren und problematischeren Updates, sowie das langfristigere bessere Moderieren und Instandhalten von troet.cafe sowie muenchen.social, umzusetzen.
Ich freue mich aufrichtig auf diese Zeit und wünsche allen Mastodon Usern ein Überstehen dieser unsicheren Phase. 👋
Die Logs des in der Vergangenheit gescheiterten Update von muenchen.social sowie dem fehlerhaften postgresql Import von troet.cafe sind uns seit Montag (22.01.2024) zugänglich!
Seither wurden diese Logs vom FISI Nick durchstöbert, sowie heute an Menschen welche eng an Mastodon arbeiten weitergegeben. Freitag (26.01.2024) wird ein Team von der DENIC :DENIC: mit postgresql (Datenbank) Expert:Innen sich das ganze mal ansehen. Wenn wir nicht weiterkommen würden wir natürlich auf die vielen Menschen zurückgreifen welche ihre Hilfe bei diesem Projekt angeboten haben, bis dahin wollen wir jedoch mit solchen Daten so kleinräumig und sensibel wie möglich umgehen.
Die Logs die uns nun vorliegen sind lediglich die genauen Fehlermeldungen welche Programme melden wenn die Updates durchgeführt werden sollten. Diese Fehlermeldungen haben also sehr kompliziert in sich geschrieben wo das Problem eigentlich ist und woran das Update von troet.cafe und muenchen.social scheitert. Die Logs zu analysieren bringt uns einen Schritt weiter das Problem zu lösen, anders gesagt die Updates erfolgreich durchzuführen — Ich möchte nur nochmal betonen das darin keine privaten Daten oder irgendwas von Usern drin zu finden ist.
Das nur so als kleines Update am Rande! Das sind jetzt keine großen Nachrichten, Ich möchte die Menschen welche den ersten Post gesehen haben, und mit guten Gründen eifrig dieser Entwicklung folgen, nur in Sicherheit dabei lassen, dass unser Plan noch existiert, durchgeführt wird, und etwas passiert! Wie anfangs gesagt wird dieser Fortschritt jedoch langsam sein und wir werden uns über viele kleine Teilerfolge freuen müssen! Wir halten euch natürlich so gut es geht auf dem laufendem, und auch wenn für eine längere Zeit Sendepause herrscht, bleibt ruhig im Wissen, dass vieles im Hintergrund geschieht! :coffefied:
@ErikUden >Die originale Datenbank von troet.cafe ist 99GB, die resultierende Datenbank nach dem Import nur noch 44GB hört sich danach an als würden die Indexe nicht generiert werden und das die Reihenfolge der Tabellenimporte nicht korrekt ist... Eventuell helfen alternative export formate oder die Trennung zwischen Struktur und Daten beim Import
Kleine Zwischenbilanz: Wir stecken bei Schritt 6 fest! Wir haben ein paar Probleme beim Importieren der Datenbank und bekommen ständig neue Fehlermeldungen. Wir haben eine interne Gruppe gegründet mit einigen Menschen die sich mit Postgresql auskennen und ihre Hilfe angeboten haben. Wir werden vielleicht gleich eine ganz andere Herangehensweise versuchen.
Es wird in diesem Abschnitt sehr technisch, deshalb entschuldigt wenn dies wenig für die normalen User ist für welche diese Plattform natürlich auch / eher gedacht ist!
Wir haben diese Nacht einen Datenbank-Export von troet.cafe angefertigt, einfach ein psql dump von dem psql-server auf der Version 10.23! Diesen zu importieren in eine leere Datenbank (psql Version 15) wirft viele Fehler auf. Die originale Datenbank von troet.cafe ist 99GB, die resultierende Datenbank nach dem Import nur noch 44GB. Also läuft irgendwas sehr schief. Die einzigen Fehlermeldungen bezogen sich auf ein „foreign key constraint”.
Wir hatten es auch mit einer Datenbank der gleichen Version versucht, doch das hat umso mehr Fehler aufgeworfen.
Wir haben daraufhin versucht das Schema der Datenbank nur zu importieren aus dem bereits existierenden dump, wobei jedoch auch 5 Fehler auftreten.
Als wir jedoch das Datenbank-Schema einzeln exportieren und einzeln importierten funktionierte dies ohne Fehler!
Nun importierten wir nur die Daten und bekamen dabei wieder hunderte Fehler mit „foreign key constraint”. Die resultierende Datenbank war lediglich 33GB. Foreign key constraints verstehe Ich so, dass sie die Integrität einer Datenbank wahren. Wenn also ein Eintrag in einer Datenbank irgendwo erwähnt wird, dieser jedoch nicht existiert, dann läuft irgendwas schief. Sowas kann zum Beispiel passieren wenn man auf Mastodon einen Beitrag favorisiert, dieser Beitrag jedoch gelöscht wird. In der Liste von favorisierten Beiträgen eines Users steht dann zwar noch der Beitrag eingetragen, doch in Echt ist er gelöscht. Durch normal auftretende Fehler können solche Ungereimtheiten in der Datenbank sich verhäufen. Doch in unserem Fall scheint irgendwas beim Import groß schief zu laufen, da Ich nicht erwarte das ⅔ der Datenbank nur Fehler sind!
Es könnte möglich sein das selbst schon beim Exportieren (dump) der Datenbank Fehler auftreten, um sicherzustellen, dass dem nicht der Fall ist, machen wir folgendes:
Unsere jetzige beste Idee ist nochmal einen psql-Server der Version 10.23 aufzusetzen und daraufhin den originalen Ordner von der troet.cafe Datenbank (var/lib/psql/10/.) in eine Zip zu tun (dafür müsste troet.cafe heruntergefahren werden). Diese Zip wird übertragen auf den neuen Server und dort eingespielt, so haben wir einen postgresql Server mit allen Fehlern der originalen Datenbank und können re-index sowie repair Befehle ausführen um die Datenbank zu reparieren und Ungereimtheiten wie diese zu entfernen. Dies live an der troet.cafe Instanz zu machen wäre zu gefährlich.
Wenn diese Fehlerbehebungsmaßnahmen erfolgreich sind versuchen wir weitere Dinge wie:
Die Datenbank exportieren und importieren und gucken oh Fehler auftreten.
Das Upgraden auf höhere Versionen von psql.
Wenn dies erfolgreich ist und die daraus resultierenden Datenbanken keine Fehler mehr haben, dann ist jedes zukünftige Update leicht!
Wer mithelfen will / Erfahrung mit Datenbanken hat schreibt mich gerne auf Matrix an und kann Teil der Gruppe werden welche gerade daran arbeitet das Problem zu lösen!
@ErikUden wenn du nicht das custom format für das backup verwendet hast, probier mal "SET session_replication_role = replica;" ganz oben im file einzufügen
@Jain zudem wurden foreign keys erst in Version 11 von psql hinzugefügt wobei wir mit einer DB auf Version 10.23 arbeiten!
Wir hatten es auch mit single-core versucht um sicherzustellen das alles in der richtigen Reihenfolge passiert, aber auch da gleiche Fehler. Das exportierte Format des Dumps ist ein besonderes (Zip).
Trennung zwischen Struktur und Daten hatte tatsächlich geholfen! Als wir das Schema unabhängig exportierten und importierten gab es keine Fehler, erst wieder bei den Daten.
@ExtraFlauschig@ErikUden kein problem, also natürlich gibts foreign keys schon vorher, das problem ist das die foreign keys nicht aufgelöst werden können beim importieren dieses backups
@ErikUden@Jain vornweg sorry für das seitlich reingrätschen, aber die Aussage foreign keys gibt es erst seit Postgres 11 (ca 2017) irritiert mich sehr. Ohne foreign keys funktioniert doch sql nicht wirklich. Kann es sein, dass du das was falsch verstanden hast? Falls dafür gerade keine Kapazitäten sind und ihr da eh andere Probleme habt ignoriere meinen Einwurf einfach.
Nach langer, langer Pause kommt nun die Überraschung! Für sehr Tech-Interessierte haben wir den gesamten Prozess der Rettung (der Datenbank) von troet.cafe in diesen gewaltigen Blog getan:
Nun, nachdem wir die größte Aufgabe, nämlich das Beheben aller Fehler auf der Plattform troet.cafe, aber auch das Beheben aller Fehler in dessen Datenbank, bestritten und gelöst haben, kamen wenige Nachrichten unsererseits!
Seither haben wir muenchen.social und troet.cafe auf den neusten Sicherheitsversionen gehalten, doch demnächst muss auch muenchen.social das große Versionsupdate durchmachen. Da wir nun unfassbare Expertise zum Mastodon-Datenbank-Schema haben, sollte dies aber nicht zu schwierig sein (solange die Fehler der Datenbank und Plattform ähnliche sind).
Wir planen mit dem übernächsten Wochenende, also den 10. und 11. August. Erwartet an dem Tag also ein paar Downtimes auf muenchen.social. Genaueres dazu folgt aber noch!
Vor diesem Datum kommt noch etwas sehr großes an dem wir lange für euch gearbeitet haben, seid daher gespannt!
Troet.Cafe ist online auf der neusten Version (4.2.8). Schaut alle ob es irgendwo Probleme gibt! Wenn irgendwas nicht läuft, meldet es sofort - dies ist ein smoke test!
Okay, wow. Wir haben es geschafft. Ich würde Lügen wenn Ich sage das Ich alles verstehe was unsere nun große Gruppe an Helfenden herausgefunden hat, doch die Datenbank ist hergestellt, das Troet.Cafe auf die neuste Version von 4.2.8 ge-updated und wir machen soeben die finalen Tests um alles wieder hochzufahren. Heute Abend bricht ein neues Zeitalter für troet.cafe an!
Ach, wäre es nur so geblieben! Wir haben alles so grandios lösen können, doch das Problem das wir Gestern noch als so leicht angesehen haben stellte sich heute als eine Meisterleistung heraus:
Wir haben ~19.000.000 Einträge für link-previews (kleine Vorschau-Texte und Bilder wenn man einen Link zu einem Beitrag einfügt) in einer Tabelle der Datenbank, für diese ein Index zu erstellen ist ab v12 von Postgresql nicht mehr möglich dank einer Reduzierung der maximalen Indexgröße. Mastodon hat einen maintenance Task eingebaut welcher dieses Problem über das Entfernen duplizierter Einträge lösen soll, doch...
Aus irgendeinem uns nicht erklärlichen Grund gibt sich die Datenbank als eine höhere Version aus. Die Datenbank behauptet selbst sie benutzt ein Schema welches erst bei Mastodon 4.2.0 angewandt wurde (wir sind auf 4.1.15), jedoch schauen wir manuell nach besitzt die Datenbank einige Tabellen nicht welche sie bei dieser Version bereits haben sollte. Sie gibt sich als etwas aus das sie nicht ist. Die Maintenance-Skripte der alten Mastodon-Version, welche offiziell nicht für die identifizierte Version gemacht sind, funktionieren nicht.
Wir testen einen der vielen troet.cafe Server und machen dort (ohne das die Instanz wieder online geht) einen Upgrade-Versuch auf 4.2.0. Dort sollten die Maintenance-Skripte funktionieren, es kann jedoch sein das sie es nicht tun.
All das um einen Index zu erzeugen der viel zu groß geworden ist! Alle Daten, Bilder, Accounts, Passwörter usw. sind perfekt, reibungslos und sicher übertragen, das, so dachten wir Gestern, war die schwere Aufgabe. Doch die kleine Vorschau der Webseite wenn man einen Link beifügt, diese fehlt.
Nein, wir können sie leider nicht einfach weglassen, auch wenn der Datensatz irrelevant ist funktioniert Mastodon wahrscheinlich nicht ohne sie.
Ich bin der festen Überzeugung das wir heute eine Lösung finden, jedoch hatte Ich nach Gestern eigentlich gedacht die Lösung sei schon längst in unseren Händen!
Das troet.cafe hält stand, keine Sorge! :blobcatmeltlove:
PS: Selbst wenn alles den Bach runtergehen würde ist nichts verloren. Wir haben tausendfach Backups und würden den Betrieb einfach so weitermachen wie zuvor. Wir sind schonmal definitiv schlauer geworden, nur noch nicht schlau genug.
Es läuft alles super. Alle Daten sind bisher perfekt übertragen worden. Unser Plan geht also auf — ein letzter Fix wird angestrebt und die alten Server auf die neue Datenbank umgestellt! Das schwierigste ist (glaube Ich) geschafft!
Wir werden jetzt das troet.cafe herunterfahren! Postet bitte heute keine Lebensnotwendigen Informationen, denn es kann sein das wir wieder zurückgehen müssen falls doch etwas schief läuft!
Wenn troet.cafe wieder online geht tobt herum und meldet alle Fehler (falls welche auftreten) denn dann haben wir noch die Möglichkeit alles rückgängig zu machen. Wir führen jetzt einen smoke test durch! :blobcatmeltlove:
Entschuldigt das fehlende Update von Gestern! Es ist sehr spät geworden und Ich wollte nach 22:00 Uhr eigentlich nur noch schlafen :blobcatgooglyholdingitsheadinitshands:
Wir haben es tatsächlich geschafft! Wir haben noch keinen echten Transfer der Datenbank gemacht, jedoch haben wir mit einer Kopie der Datenbank eine erfolgreiche Migration ohne Datenverlust durchgeführt.
Alles was wir heute machen müssen ist es diese Schritte zu wiederholen währenddessen das troet.cafe heruntergefahren bleibt und zum Schluss alles auf den neuen Datenbank-Server umzustellen!
Der gestrige Tag war voll mit falschen Fehlermeldungen, Trugschlüssen, und ein Tappen im Dunkeln! Wir haben um die 50 unterschiedliche Methoden probiert und hätten noch viel mehr tun können. Letztendlich alle Fehlermeldungen an der Datenbank zu verstehen, diese in jedem Fall auf ihre Besonderheit runterzubrechen, und dann zu verstehen wo der Fehler wirklich ist, hat uns zum „Erfolg” gebracht! Auch wenn Martin bereits sehr glücklich war gibt es noch keinen Grund zu feiern, erst wenn wir das ganze in Echt durchgeführt haben!
Ein Beispiel eines solchen Trugschlusses war die unterschiedliche Größe der Datenbank nach dem Importieren. Auf troet.cafe ist die Datenbank 99GB, auf unserem Server war sie nur 33GB, dabei hatte dies einen anderen Grund. Wir dachten viele Daten waren verloren und versuchten einen Fehler zu finden wo gar keiner war! Im Nachhinein realisierten wir dann, dass wir die Lösung schon lange hatten.
Die Datenbanksoftware belügte uns auch zwischenzeitlich über die Anzahl der gespeicherten Beiträge! Das war echt witzig.
Eine vollständige Erklärung der zwei Fehler wird es demnächst geben — fürs erste ist hier der exakte Schritt für Schritt Weg, den Ich aus meinem ~40.000 Zeichen Protokoll des gestrigen Tages, herausgearbeitet habe, als das was wir tatsächlich mache müssen:
1. Troet.Cafe herunterfahren
2. Datenbank-Dump erstellen und Server offline lassen.
3. Datenbank-Schema-Clear-Text-Dump erstellen und Server offline lassen.
4. Beides auf neuen Server übertragen auf dem eine psql Datenbank der Version 15.7 eingerichtet ist.
5. Das clear-text Datenbank-Schema so editieren, dass „CREATE UNIQUE INDEX [...]” für index_preview_cards_on_url auskommentiert ist.
6. Das clear-text Datenbank-Schema importieren mit folgenden Befehl:
(In der Zukunft nach jedem Datenbank-Update den REINDEX Befehl aus Punkt 9 verwenden um dieses Problem zu vermeiden.)
13. Troet.Cafe wieder hochfahren und alles läuft wie vorher nur besser und auf einer neuen Version!
Dies ist ein klarer Schritt für Schritt Weg wie wir die Datenbank heute retten — wenn diese Hürde überwunden ist dann wird jedes Update und jede Migration in der Zukunft extrem einfach!