MySQL für deinen FiveM-Server: oxmysql richtig einrichten
Ein Freeroam-Server merkt sich nichts, und das ist völlig okay. Aber sobald du mit einem Framework wie ESX oder QBCore einen echten Roleplay-Server baust, muss alles gespeichert bleiben: Charaktere, Kontostände, Fahrzeuge, Sachen in Taschen und Kofferräumen. Dafür nutzt praktisch jeder FiveM-Server eine MySQL-Datenbank, und die Brücke zwischen deinem Server und dieser Datenbank heißt heutzutage oxmysql. In diesem Artikel richtest du diese Verbindung sauber ein und sorgst dafür, dass die Daten deiner Spieler auch sicher bleiben.
Warum ein RP-Server nicht ohne Datenbank auskommt
Jedes Mal, wenn ein Spieler sich ausloggt, schreibt dein Framework seinen Fortschritt weg: Position, Geld, Job, Inventar. Loggt sich der Spieler morgen wieder ein, liest das Framework alles zurück. Ohne Datenbank fängt jeder in jeder Session von vorn an, und das ist für Roleplay tödlich. Die Datenbank ist damit buchstäblich das Gedächtnis deiner Stadt, und alle Scripts, die sich etwas merken müssen (Garagen, Häuser, Handys), docken an derselben Datenbank an.
oxmysql: der aktuelle Standard
Jahrelang war mysql-async die Standardanbindung, später kam ghmattimysql dazu. Beide werden nicht mehr aktiv gepflegt. Der Nachfolger ist oxmysql: aktiv weiterentwickelt, und die Anbindung, die moderne Frameworks und Scripts heute erwarten. Stößt du in einem Tutorial noch auf mysql-async, ist das ein Zeichen, dass das Tutorial veraltet ist. Gut zu wissen: oxmysql hat eine Kompatibilitätsschicht, wodurch viele ältere Scripts, die nach mysql-async verlangen, einfach weiterlaufen.
Die Installation ist ansonsten wenig Arbeit: oxmysql ist eine gewöhnliche Resource, die du in deinen resources-Ordner legst und mit einer ensure-Zeile startest. Nutzt du ein txAdmin-Rezept für ESX oder QBCore, ist oxmysql oft schon dabei und du musst nur noch die Datenbankdaten richtig setzen.
Der Connection String in der server.cfg
oxmysql muss wissen, wo deine Datenbank liegt und wie es sich einloggen darf. Das regelst du mit einer einzigen Convar in der server.cfg, und die muss vor dem ensure von oxmysql stehen:
set mysql_connection_string "mysql://benutzer:[email protected]/datenbankname?charset=utf8mb4"
ensure oxmysql
ensure es_extendedDie Daten (Benutzer, Passwort, Host und Datenbankname) bekommst du beim Anlegen deiner Datenbank. Bestellst du einen FiveM-Server bei MC-Node, ist die Datenbankverwaltung einfach im Panel enthalten; in der Knowledgebase steht, wie du eine Datenbank anlegst und wie du sie mit deinem Server verbindest.
Eine Warnung, die wir nicht oft genug wiederholen können: Diese Zeile enthält dein Datenbankpasswort. Teile also niemals einfach so deine komplette server.cfg, wenn du irgendwo um Hilfe bittest, sondern schneide den Connection String vorher heraus. Und halte die Reihenfolge ein: erst der Connection String, dann ensure oxmysql, und erst danach dein Framework. Startet oxmysql nicht als Erstes, kommt dein Framework mit Datenbankfehlern hoch und Spieler können sich nicht einmal einloggen.
Wie ESX und QBCore deine Datenbank nutzen
Du musst kein Datenbankadministrator werden, aber ein grobes Bild hilft enorm beim Lösen von Problemen. Bei der Installation deines Frameworks importierst du eine mitgelieferte .sql-Datei, die die Basistabellen anlegt. ESX speichert Spieler zum Beispiel in einer users-Tabelle und Fahrzeuge in owned_vehicles; QBCore nutzt unter anderem players und player_vehicles. Jedes größere Script, das du danach installierst (Garagen, Häuser, Jobs), liefert oft eine eigene .sql-Datei mit zusätzlichen Tabellen mit. Importiere die sauber, sonst bekommst du Konsolenfehler über fehlende Tabellen, sobald das Script etwas speichern will.
Willst du selbst in die Daten schauen, geht das über die Datenbankverwaltung deines Panels; in der Knowledgebase steht, wie du eine Datenbank anlegst und verwaltest. Schauen ist immer erlaubt, aber sei zurückhaltend mit manuellen Änderungen. Geld oder Items direkt in einer Tabelle zu ändern, während der Server läuft, wird beim nächsten Save einfach wieder überschrieben, oder sorgt schlimmer noch für schiefe Daten. Nutze für solche Eingriffe lieber die Admin-Tools deines Frameworks.
Langsame Queries erkennen
Eine Datenbank, die träge antwortet, fühlt sich an wie Serverlag: Ruckler beim Einloggen, Items, die nur zögerlich im Inventar erscheinen, eine Stadt, die sich schwer anfühlt, während der Prozessor kaum etwas zu tun hat. So findest du heraus, ob die Datenbank der Übeltäter ist:
- txAdmin-Metriken. Das Dashboard von txAdmin zeigt, wie dein Server performt und welche Resources Zeit fressen. Fallen Spitzen mit Momenten zusammen, in denen viel gespeichert wird, etwa geplante Saves oder Stoßzeiten, deutet das Richtung Datenbank.
- Die Konsole. oxmysql kann langsame Queries in deiner Serverkonsole melden, inklusive der Resource, die sie abgefeuert hat. Das ist Gold wert: Du siehst sofort, welches Script das Problem verursacht.
- Testen nach jeder Installation. Merkst du Ruckler direkt nach dem Hinzufügen eines neuen Scripts, hast du den Verdächtigen schon gefunden. Füge große Scripts deshalb einzeln hinzu und behalte die Metriken die ersten Tage besonders im Auge.
Die Ursache ist praktisch nie "MySQL ist langsam", sondern fast immer ein Script, das zu viel oder zu oft schreibt, zum Beispiel alle paar Sekunden komplette Inventare speichert. Die Lösung liegt dann im Script: ein großzügigeres Save-Intervall oder eine besser geschriebene Alternative. Ein stärkeres Paket überdeckt so ein Problem höchstens eine Weile.
Backups: das langweiligste Thema, bis du eins brauchst
Deine Datenbank enthält alles, was deine Community aufgebaut hat. Ein missglücktes Framework-Update oder ein Script, das eine Tabelle leerräumt, und Monate an Charakteren und Besitztümern sind weg. Deshalb:
- Mach ein Backup vor jeder großen Änderung. Framework-Update, neues Inventarscript, große Migration: erst exportieren, dann installieren.
- Automatisiere wiederkehrende Backups über die Backup-Funktion deines Panels, und lade regelmäßig eins auf deinen eigenen Rechner herunter.
- Teste ab und zu eine Wiederherstellung. Ein Backup, das du nie zurückgespielt hast, ist eine Annahme, keine Gewissheit.
Es klingt übertrieben, bis es schiefgeht. In einer RP-Community ist die Datenbank nicht einfach nur Daten: Sie ist der Fortschritt all deiner Spieler, und die vertrauen darauf, dass du gut darauf aufpasst.