Follow

I have a question about a broken 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.

@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

@nipos Don't delete manually! You mess around with the inner workings of the application. That is what I always tell all people. Write a proper "view" for it which does the work for you correctly.

@roland I know.I didn't delete it and I didn't tell him to do it.He had few storage free and tried that to get some more disk space free.Now we need to make this undone which isn't that easy I guess.

I've just had an idea: it seems like the user id -99 is somehow hardcoded as 'representative' when the actual account is not found locally by username and domain - thus the name of the method. Maybe there is usually a dummy row with that id in the users table, which is being inserted on setup - and I deleted that one. It would have met my search criteria for the DELETE statement, as it wouldn't have any toots, follows, blocks etc since it is only a dummy record.
@nipos

Can someone check with
SELECT * FROM users WHERE id=-99;

@nipos

@nipos ich glaube ich hab es. Die Spur war gut, nur die table falsch. Es muss accounts sein, nicht users. Und dann hab ich noch etwas hilfreiches in live/db/seeds.rb gefunden. Da wird nämlich tatsächlich der Account -99 initialisiert. Das hab ich dann händisch auf der cli nachgeholt und jetzt findet Account.find(-99) wieder etwas.

@thalon Ah,sehr schoen.Wenn man weiss,wonach man suchen muss,ist es manchmal erstaunlich einfach.Freut mich,dass es wieder richtig funktioniert 🎉

@thalon Hab ich gerne gemacht.Und wenn es wieder mal Probleme gibt,einfach fragen.Ich bin zwar immer gestresst,aber wenn es irgendwie machbar ist,schau ich es mir an.

@thalon
Uih, hast Du es wieder hinbekommen? 😍 Du bist mein Held! 😘
@nipos

Sign in to participate in the conversation
Mastodon

Generiere Instanz-Beschreibung... ... ... ... ... ERROR 418!