Redis Datenbank

[Kasjo]

Grüße.

Ich brauch bitte eure Hilfe.

Wir spielen/Hosten bei uns einen Atlas Spiel Server.
Atlas nutzt die Redis Datenbank um so ziemlich alles was Spielerdaten und reisen betrifft in der Datenbank. Leider legt das Programm auch keys an die wieder gelöscht werden müssen da bei anschwellen sonst ein Reisen in andere Grids(Server) nicht mehr möglich ist.

Atlas Server bestehen in der Regel aus einzelnen Grids (Server) die im Verbund einen großen ganzen ergeben.

Um die Daten, explizit handelt es sich hier bei um RawTravelData keys zu löschen wurde ein Script genutzt.
https://github.com/Impulse87/ATLAS-RawTravelDataCleaner

Hierbei wurde aber ein Fehler meinerseits gemacht und ich habe vergessen "node" zu installieren und das script darin zu integrieren. Stattdessen wurde das Script direkt ausgeführt.

Unser Problem ist nun das auch die Spieler Daten und IDs so wies aussieht einen timer bekommen haben und bei auslaufen gelöscht werden. Das hat zur folge das der Server sich zumindest was die Spielerdaten betrifft selbst wiped. Das nehme ich zumindest an.

Gibt es eine Möglichkeit alle aktuellen keys wieder persistent zu machen? Ich habe bereits das persist command probiert, bekam aber Interger 0 als Antwort was wohl bedeutet, das es nicht funktioniert hat.

Wir setzten nun alle 1-2 Tage den Server komplett zurück weil wir sonst nicht weiter spielen können. Ein Login schlägt fehl bzw. man starrt auf einen ladebildschirm bis ein timeout kommt und der server registriert auch keinen login. Des verlorenen keys sind nur ein Anhaltspunkt.
So sieht die DB aus wenn alles funktioniert.

Ab dem punkt wo wir uns nicht mehr einloggen können fehlen alle keys die in bezug auf Player Daten IDs, Company, tribe usw. betrifft. Die Datenbank ist quasi fast leer geräumt.


Ich würde gerne mehr Informationen geben, weiß aber nicht wo ich anfangen soll. Deshalb die bitte, wenn sich wer mit der Redis Datenbank auskennt, ob er mir helfen kann. Ich geb so viel infos wie ich kann.

Nutzen tun wir aktuell den "Another redis Datenbank manager" wenn das was hilft.


Hoffe jemand weiß was ich machen kann. Wäre echt dankbar dafür. Ich muss nun zur Arbeit, werd aber danach wieder da sein für infos.

Server läuft unter Windows Server.

 

[tRITON]

Ich kann Dir zu deinem erzeugten Problem nicht helfen, aber ich verstehe auch deinen Text nicht.

Wenn Du den Server doch "komplett zurück setzt", dann lief dort ja auch NIE das Script. Warum hast Du denn den Fehler nie behoben, mit dem fehlenden "NODE" Script?

 

[ReignInBlo0d]

Vorab: ich habe keine Ahnung von Atlas und diesen Travel-Daten. Ich bin mir nicht ganz sicher ob ich dich richtig verstehe. Ein JS-Skript kann man nicht "einfach so" ausführen. Node ist ja auch nur eine Laufzeitumgebung. Also wenn da was ausgeführt wurde, dann wäre meine Vermutung dass es mit Node das gleiche Resultat gehabt hätte.

Wenn Du den Server doch "komplett zurück setzt", dann lief dort ja auch NIE das Script. Warum hast Du denn den Fehler nie behoben, mit dem fehlenden "NODE" Script?

Der Server ist wohl nicht das Problem, sondern dass die Keys in Redis durch das Skript alle "expired" werden, also quasi einen Timer bekommen nachdem sie (bzw. deren Werte) entfernt werden. Das sieht man im verlinkten JS-Skript in Zeile 36-43.

Lösung: entweder Redis einmal neu aufsetzen (alle Daten sind dann weg), oder aber manuell bzw. per Skript für jeden Key, den ihr dauerhaft behalten wollt, den Timer aufheben. Wie das geht, steht z.B. hier: https://stackoverflow.com/questions/40358231/redis-how-to-remove-expiry-from-a-key

 

[Kasjo]

Wir setzten in der Regel den server nicht komplett zurück sondern nur auf einen zeitpunkt auf dem wir noch spielen konnten. Das script ist schon länger her als wir das genutzt hatten, hatten aber erst mods und der gleichen in verdacht. Atlas ist halt Atlas... da kommen so viele andere Dinge zuerst in frage. Vor allem weil wir eben das script auch schon vorher mal nutzen (andere Server Installation) letztes jahr und da lief das über Monate hinweg. Auf meinen fehler bin ich erst kürzlich gestoßen.

Allerdings hab ich nun im Datanbank manager den Timer gefunden der herunterzählt. Bei 0 wird der gelöscht.

Wipen komplett wollten wir uns eigentlich ersparen weil wir eben schon relativ lange spielen und gekommen sind. Wenns aber nicht anders geht müssen wirs ja.

@ReignInBlo0d

Ja wie gesagt das war bisher nur meine Vermutung. Ausgeführt wirds in der Powershell letztendlich. Danke für den Link. Den schaue ich mir direkt an wenn ich daheim bin.
Bei oben gezeigten timer kann ich was eintragen, versuche ich aber z.B. -1, dessen wert steht auch bei den keys drinnen die übrig bleiben, bekomme ich die Meldung das dies 0 sei und der key direkt gelöscht wird.

Ich lese mich in den link von dir ein. Danke dafür. Bis nachher.

 

[ReignInBlo0d]

Ich bin dennoch etwas verwundert, warum alle Keys bei euch betroffen sind. Im Skript steht ja wörtlich, dass "expire" nur für alle Keys mit dem Namensmuster "RawTravelData:*" gesetzt wird (Zeile 31). Am Skript oder einer "fehlerhaften Ausführung" kann es eigentlich nicht liegen, hätte ich gesagt.

Kannst ja mal später bescheid geben wenn du weitergekommen bist, interessiert mich

 

[DerDummePunkt]

oh wei.
OP, kannst du bitte erstmal beschreiben, wie ihr das Skript überhaupt benutzt habt, wenn du node nicht installiert hast?

War auf dem Server schon ne andere node version installiert?

Ich glaube nicht, dass ihr das Skript "einfach so" laufen lassen konntet, dass skript hat ne Abhängigkeit auf das NPM Redis package, wenn das nicht zufällig schon systemweit verfügbar war, ist das Skript mit Sicherheit nicht gelaufen.

Wenn ich das Skript richtig interpretiere, wird auf alle Keys unterhalb von RawTravelData eine TTL gesetzt, alles andere fast das Skript garnicht an.

Die TTL auf den anderen Keys kommt glaube ich nicht von dem Skript.

Dabei ist das Skript ned so wirklich clever geschrieben.
keys z.B. ist eins der teuersten Kommands in Redis, das sollte man im produktiven Betrieb tunlichst nicht benutzen, weil es sau lange blockieren kann, wenn Menge der Keys in einer DB bissl größer ist, aber gut.

Another redis Datenbank manager kenne ich nicht, hat das Ding evtl ne Konsole? siehst du, was für ein Befehl genau abgefeuert wird, wenn du versuchst die TTL neu zu setzen?

Wie schon beschrieben wurde, eine TTL von einem Key zu entfernen geht am besten mit dem PERSIST Kommando, andernfalls muss man den Key samt Inhalt komplett neu setzen, einfach -1 als TTL setzen geht nicht, eine bestehende TTL kann nur durch eine andere TTL >0 ersetzt, werden das liegt an den Interna von Redis.

Wenn PERSIST als Antwort 0 liefert, heißt das, dass der Key entweder nicht gefunden wurde, oder der Key garkeine TTL hatte.
Ich vermute ersteres, vermutlich wird versucht ein PERSIST auf RawTravelData:* abzufeuern, das geht aber nicht, man muss alle Blattknoten direkt ansprechen.

 

[ReignInBlo0d]

@DerDummePunkt danke für die Erläuterungen, ich bin auch wahrlich kein Redis-Profi aber habe hier schon wieder was dazugelernt!

Wenn man eine einmal gesetzte TTL nicht mehr aufheben kann, dann ist mein StackOverflow-Link oben aber Quatsch. Oder verstehe ich da was falsch? Vielleicht könntest du mich hierzu einmal aufklären

 

[DerDummePunkt]

Nene, der Beitrag auf Stackoverflow ist schon richtig, da steht auch das gleiche wie in meinem Post:

• entweder per SET den ganzen Key inkl. Value aber ohneTTL neu setzen
  • Das macht dann Sinn, wenn man den Wert eh schon kennt oder verändern möchte
• oder per PERSIST die TTL entfernen

Warum die Redis Macher es einem jetzt erlauben, auf nem Key ohne TTL mittels EXPIRE eine TTL zu setzen, aber umgekehrt PERSIST verwenden muss, ja mei, das ist ne Stilfrage, ich finde es gut so, für mein Verständis ist es so eindeutiger, expire setzt ne TTL, persists, naja, persistiert eben.

 

[Kasjo]

War auf dem Server schon ne andere node version installiert?

Bei genauerem Überlegen könnte das ggf. sein. Immerhin läuft der seit nem jahr ungefähr.

Ich hab jetzt mal ein backup vom letzten Jahr ausgepackt. Dort hatten wir nie Solche Probleme. Lief selbst da ein Jahr sauber.

Folgendes.

Also die PlayerDataID Timer sind wohl normal. Nachgerechnet sind das knapp 30 Tage nach dem der Client quasi da rausfliegt. Demnach kann ich das erst mal über Bord werfen da wohl die essenziellen Informationen in en darunter liegenden Ordnern Playerinfo usw. liegen welche keinen timer besitzen. Bzw. steht da bei TFL -1 sowohl bei dem backup als auch bei der aktuellen.

Ich habe also in die Redis geschaut aus dem Backup und den Inhalt mit der bereits zerstörten aus nem aktuellen stand verglichen. Ebenfalls mit einer Funktionierenden von gestern.
Alle werte scheinen soweit identisch.

Warum sieht nach zwei tagen die Redis DB dann so aus?

Normalzustand mit allen Einträgen:

Und zwei Tage später, wenn sich dann niemand mehr einloggen kann usw.

Wieso geht da so viel verloren? Die Configs sind auch identisch. Die wird in der Regel frisch mit dem Spiele Server geladen und is eigentlich rdy to use.
Auch das das Game an sich nirgends irgendwo auch nur ne log Datei für das anlegt. Ich nutze sonst keinerlei tools oder sonst was da irgendwie mit der DB in Verbindung gebracht werden könnte.

Ich kenn mich mit so Datenbank Geschichten nicht aus und auch nicht welche Tools am besten wären, aber gibt's es irgendwie ne Möglichkeit, das man da logs erstellen lassen kann oder anderweitig herausfinden was da im argen ist?


@DerDummePunkt

Dabei ist das Skript ned so wirklich clever geschrieben.

Soweit leuchtet deine Erklärung ein.
Zu dem Script: Ja das kann sein, das is 4 Jahre alt glaub ich. Und soweit ich weiß das einzige. Leider hat man keine Wahl wenn man nach zwei drei Wochen noch hin und her reisen will im Spiel und ich gehe jede wette ein die Entwickler nutzen das oder etwas selbst geschriebenes.

Wenn die DB mit diesen Daten zugemüllt ist, und man einen Grid/Server Wechsel macht steckt man dazwischen fest, bekommt einen timeout und kommt auch so nicht mehr auf den Server es sei den man fängt bei 0 mit neuem Character an. Selbst Modder haben dahingehend mods gebastelt die genau das erkennen und eben ingame warnen das der GridTravel nicht mehr sicher sei. Und für diesen mod, weil der selbst die db zumüllt wurde das Script geschrieben. Zumindest hat der Ersteller das auch so bei github geschrieben.

Scripten kann ich nich ^^ und die dies können und auf ihren Servern betreiben, teilen das niemanden mit. Getreu nach dem Motto, es kann nur einen geben (Server der sauber läuft)

Support Technisch bekommt man von den Entwicklern nichts wenn man nicht gerade bei Nitrado für Unsummen einen Server mietet oder auf deren offiziellen Servern Spielt. Die Entwickeln ohnehin das ganze game an der Community vorbei und feiern sich nach jedem update das sie bringen selbst.

Aber eine Alternative gibts halt auch nich ^^ 🤷‍♂️

 

[DerDummePunkt]

Ich glaube ehrlich gesagt nicht, dass das Skript die anderen Daten löscht.

Um das aber auszuschließen: Könnt ihr das Skript einfach mal stoppen? Oder Läuft man dann schneller als in 2 Tagen in das Problem mit den TravelLogs?

Wenn die anderen Probleme nach 2 Tagen nicht mehr auftauchen, dann hätte man zumindest mal den Übeltäter identifiziert

 

[Kasjo]

Ne das Script is bereits gestoppt. Ich glaube auch nicht das dies schuld ist. Aber ich glaube das ich wohl besser bedient bin komplett frisch zu machen. Ohne das man sich mit der Materie Atlas ein wenig auseinander gesetzt hat ist es auch schwer irgendwas nach zu vollziehen. Dazu müsste man wissen was genau auch atlas mit der DB anstellt.

Zumindest nach meinen bescheidenen versuchen hab ich feststellen können das die DB eigentlich so ist wie sie soll. Nur eben löscht sie von sich aus irgendwann einfach n großteil ihres bestandes. Ohne logs oder der gleichen werd ich so oder so nie dahinter kommen wieso sie das macht.