MySQL voor je FiveM-server: oxmysql goed instellen
Een freeroam-server onthoudt niets, en dat is prima. Maar zodra je met een framework als ESX of QBCore een echte roleplay-server bouwt, moet alles bewaard blijven: characters, banksaldo's, voertuigen, spullen in zakken en kofferbakken. Daarvoor gebruikt vrijwel elke FiveM-server een MySQL-database, en de brug tussen je server en die database heet tegenwoordig oxmysql. In dit artikel zet je die koppeling goed op, en zorg je dat de gegevens van je spelers ook veilig blijven.
Waarom een RP-server niet zonder database kan
Elke keer dat een speler uitlogt, schrijft je framework diens voortgang weg: positie, geld, job, inventaris. Logt de speler morgen weer in, dan leest het framework alles terug. Zonder database begint iedereen elke sessie opnieuw, en dat is voor roleplay dodelijk. De database is daarmee letterlijk het geheugen van je stad, en alle scripts die iets moeten onthouden (garages, huizen, telefoons) prikken op diezelfde database in.
oxmysql: de huidige standaard
Jarenlang was mysql-async de standaardkoppeling, later kwam ghmattimysql erbij. Beide worden niet meer actief onderhouden. De opvolger is oxmysql: actief doorontwikkeld, en de koppeling die moderne frameworks en scripts tegenwoordig verwachten. Kom je in een tutorial nog mysql-async tegen, dan is dat een teken dat de tutorial verouderd is. Goed om te weten: oxmysql heeft een compatibiliteitslaag, waardoor veel oudere scripts die om mysql-async vragen gewoon blijven werken.
Installeren is verder weinig werk: oxmysql is een gewone resource die je in je resources-map zet en met een ensure-regel start. Gebruik je een txAdmin-recept voor ESX of QBCore, dan zit oxmysql er vaak al bij en hoef je alleen de databasegegevens nog goed te zetten.
De connection string in server.cfg
oxmysql moet weten waar je database staat en hoe hij mag inloggen. Dat regel je met één convar in server.cfg, en die moet vóór de ensure van oxmysql staan:
set mysql_connection_string "mysql://gebruiker:[email protected]/databasenaam?charset=utf8mb4"
ensure oxmysql
ensure es_extendedDe gegevens (gebruiker, wachtwoord, host en databasenaam) krijg je bij het aanmaken van je database. Bestel je een FiveM-server bij MC-Node, dan zit databasebeheer gewoon in het paneel; in de kennisbank staat hoe je een database aanmaakt en hoe je hem aan je server koppelt.
Eén waarschuwing die we niet vaak genoeg kunnen herhalen: deze regel bevat je databasewachtwoord. Deel dus nooit zomaar je complete server.cfg als je ergens hulp vraagt, maar knip de connection string er eerst uit. En houd de volgorde aan: eerst de connection string, dan ensure oxmysql, en pas daarna je framework. Start oxmysql niet als eerste, dan komt je framework met databasefouten omhoog en kunnen spelers niet eens inloggen.
Hoe ESX en QBCore je database gebruiken
Je hoeft geen databasebeheerder te worden, maar een globaal beeld helpt enorm bij het oplossen van problemen. Bij de installatie van je framework importeer je een meegeleverd .sql-bestand dat de basistabellen aanmaakt. ESX bewaart spelers bijvoorbeeld in een users-tabel en voertuigen in owned_vehicles; QBCore gebruikt onder meer players en player_vehicles. Elk groter script dat je daarna installeert (garages, huizen, jobs) levert vaak een eigen .sql-bestand mee met extra tabellen. Importeer die netjes, anders krijg je consolefouten over ontbrekende tabellen zodra het script iets wil opslaan.
Wil je zelf in de data kijken, dan kan dat via het databasebeheer van je paneel; in de kennisbank staat hoe je een database aanmaakt en beheert. Kijken mag altijd, maar wees terughoudend met handmatig aanpassen. Geld of items rechtstreeks in een tabel wijzigen terwijl de server draait, wordt bij de eerstvolgende save zo weer overschreven, of zorgt erger nog voor scheve data. Gebruik voor dat soort ingrepen liever de admin-tools van je framework.
Trage queries herkennen
Een database die traag reageert, voelt als serverlag: haperingen bij het inloggen, spullen die traag in je inventaris verschijnen, een stad die zwaar aanvoelt terwijl de processor weinig te doen heeft. Zo kom je erachter of de database de boosdoener is:
- txAdmin-metrics. Het dashboard van txAdmin laat zien hoe je server presteert en welke resources tijd opslokken. Vallen pieken samen met momenten waarop veel wordt opgeslagen, zoals geplande saves of drukte, dan wijst dat richting database.
- De console. oxmysql kan trage queries in je serverconsole melden, inclusief de resource die ze afvuurde. Dat is goud waard: je ziet meteen welk script het probleem veroorzaakt.
- Testen na elke installatie. Merk je haperingen direct na het toevoegen van een nieuw script, dan heb je de verdachte al gevonden. Voeg grote scripts daarom één voor één toe en houd de metrics de eerste dagen extra in de gaten.
De oorzaak is vrijwel nooit "MySQL is traag", maar bijna altijd een script dat te veel of te vaak schrijft, bijvoorbeeld elke paar seconden complete inventarissen opslaan. De oplossing zit dan in het script: een ruimer save-interval, of een beter geschreven alternatief. Een zwaarder pakket verhult zo'n probleem hooguit even.
Back-ups: het saaiste onderwerp, tot je er een nodig hebt
Je database bevat álles wat je community heeft opgebouwd. Eén mislukte framework-update of één script dat een tabel leegtrekt, en maanden aan characters en bezittingen zijn weg. Daarom:
- Maak een back-up vóór elke grote wijziging. Framework-update, nieuw inventarisscript, grote migratie: eerst exporteren, dan pas installeren.
- Automatiseer terugkerende back-ups via de back-upfunctie van je paneel, en download er regelmatig een naar je eigen computer.
- Test af en toe een herstel. Een back-up die je nooit hebt teruggezet, is een aanname, geen zekerheid.
Het klinkt overdreven, tot het misgaat. In een RP-community is de database niet zomaar data: het is de voortgang van al je spelers, en die vertrouwen erop dat jij er zuinig op bent.