#mastoadmins #mastoadmin #mastodev I have a question about a broken #Mastodon instance,maybe someone can help.The admin of embassy.social told me that he deleted many rows from the users table of his database because there were many users without toots or followers.Now the instance is broken in a way that no new user rows can be created,affecting federation in a way that no posts from users the instance hasn't seen before can arrive and following/getting followed by unknown users doesn't work,too.We were investigating this problem just now but we didn't find a solution to repair the instance.Here is the part of a log file,we get dozens of errors of this type per minute: paste.bka.li/view/c68f6cfd Maybe someone can help here?

@nipos
Nicht dass ich eine spezielle Ahnung hätte, aber ich würde wie folgt vorgehen:
- DB dumpen
- DB neu und clean aufsetzen
- alte DB importieren, so dass keine Tabellen gelöscht werden, sondern nur die alten Einträge eingetragen werden.

@x2ero Das wuerde die fehlenden Daten trotzdem nicht mehr zurueck bringen.Und genau die sind es hoechstwahrscheinlich,die jetzt die Probleme verursachen.

@nipos
Aber zumindest wäre die Datenbank Struktur wieder wie die sein soll.

@x2ero Die Datenbankstruktur ist wie sie sein soll,nur einige Datensaetze fehlen halt.

@nipos
Naja... Was soll ich sagen..... Weg ist weg, oder?

@x2ero ja. Aber die Folgefehler könnte man vielleicht fixen, so zumindest meine Hoffnung. Alle Daten die weg sind sind eigentlich nicht direkt erforderlich.

@nipos

@thalon @x2ero Ich befuerchte ja,dass diese Daten sehr wohl erforderlich sind,ansonsten wuerde ihr Fehlen keine so grossen Probleme verursachen.Dass es alleine daran liegt,dass die IDs nicht direkt aufeinander folgen,halte ich fuer eher unwahrscheinlich.Und das waere das einzige,was diese Idee veraendern wuerde.Gut,wenn du kein Backup hast,waere es wohl einen Versuch wert.Was besseres faellt mir auch nicht ein.

@nipos @x2ero Naja, was ich meine, ist, dürfen Daten in der Theorie eigentlich nicht erforderlich sein *sollten*. In der Praxis gibt es offensichtlich anders aus, aber das hängt natürlich von der konkreten Implementation ab. Ich hab ja nur User gelöscht, von denen sonst nichts im System war (keine Verfolgungen, Toots, Blocks, nichts). Meine Überlegung war, dass diese Datensätze bei einer frischen Instanz ja auch fehlen würden und dann gegebenenfalls aus der Federation geholt werden können.

Follow

@nipos Mit diesen seltsamen Seiteneffekten habe ich ehrlich gesagt nicht gerechnet. Um zu verstehen, was genau schief läuft, müsste man aber erst mal wissen, was genau abläuft und wie man das am besten debuggen kann. Im besten Fall entsteht zu etwas robusterer Code, der eine teilweise korrupte Datenbank wieder aus der Föderation herstellen könnte. Das würde letztenendes ja allen helfen, denn Datenbank-Fehler können ja immer mal wieder auftreten. @x2ero

@nipos
Ich hab übrigens gerade festgestellt, dass, wenn ich einen tweet an @nipos@toot.koeln sende, dass beim Absenden ein 404 zurückkommt. Normalerweise kommt da ein 200...
@x2ero@pforzelona.club

@thalon Ich werde mir das zeitnah nochmal anschauen.Ich stimme dir schon zu,dass robusterer Code besser waere.Aber vielleicht bekommen wir es tatsaechlich hin,dass die fehlenden Daten wieder neu eingetragen werden

@thalon
Offenbar gibt es Querverweise in andere Tabellen, die laufen jetzt und leere.
Sowas sollte man halt nicht tun wenn man die Struktur nicht kennt.
@nipos

.@x2ero
Konsistenz auf der Anwendungsebene herzustellen ist schlechter Programmierstil. Das ist eigentlich Aufgabe der DB, Stichwort ACID. Und in der Tat sind dort auch einige Fremdschlüsselbeziehungen und die sind alle mit ON DELETE CASCATE/ON DELETE SET NULL abgesichert. Von der Seite her sollte das also funktionieren.
@nipos

Sign in to participate in the conversation
Embassy of Awesomeness

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!