MySQL pour votre serveur FiveM : bien configurer oxmysql
Un serveur freeroam ne retient rien, et ce n'est pas un problème. Mais dès que vous construisez un vrai serveur roleplay avec un framework comme ESX ou QBCore, tout doit être conservé : personnages, soldes bancaires, véhicules, objets dans les poches et les coffres. Pour cela, pratiquement chaque serveur FiveM utilise une base de données MySQL, et le pont entre votre serveur et cette base s'appelle aujourd'hui oxmysql. Dans cet article, vous mettez cette liaison en place correctement, et vous veillez à ce que les données de vos joueurs restent en sécurité.
Pourquoi un serveur RP ne peut pas se passer de base de données
Chaque fois qu'un joueur se déconnecte, votre framework enregistre sa progression : position, argent, métier, inventaire. Quand le joueur se reconnecte le lendemain, le framework relit tout. Sans base de données, chacun repart de zéro à chaque session, et pour le roleplay, c'est fatal. La base de données est donc littéralement la mémoire de votre ville, et tous les scripts qui doivent retenir quelque chose (garages, maisons, téléphones) se branchent sur cette même base.
oxmysql : le standard actuel
Pendant des années, mysql-async a été le connecteur standard, rejoint plus tard par ghmattimysql. Aucun des deux n'est encore activement maintenu. Le successeur est oxmysql : activement développé, et le connecteur que les frameworks et scripts modernes attendent aujourd'hui. Si vous croisez encore mysql-async dans un tutoriel, c'est le signe que ce tutoriel est dépassé. Bon à savoir : oxmysql dispose d'une couche de compatibilité, grâce à laquelle beaucoup de scripts plus anciens qui réclament mysql-async continuent simplement de fonctionner.
L'installation demande peu de travail par ailleurs : oxmysql est une ressource ordinaire que vous placez dans votre dossier resources et que vous démarrez avec une ligne ensure. Si vous utilisez une recette txAdmin pour ESX ou QBCore, oxmysql est souvent déjà inclus et il ne vous reste qu'à renseigner correctement les informations de la base.
La chaîne de connexion dans server.cfg
oxmysql doit savoir où se trouve votre base de données et comment s'y connecter. Cela se règle avec une seule convar dans server.cfg, qui doit se trouver avant le ensure d'oxmysql :
set mysql_connection_string "mysql://utilisateur:[email protected]/nom_base?charset=utf8mb4"
ensure oxmysql
ensure es_extendedVous recevez ces informations (utilisateur, mot de passe, hôte et nom de la base) lors de la création de votre base de données. Si vous commandez un serveur FiveM chez MC-Node, la gestion des bases de données fait simplement partie du panel ; la base de connaissances explique comment créer une base de données et comment la relier à votre serveur.
Un avertissement que nous ne répéterons jamais assez : cette ligne contient le mot de passe de votre base de données. Ne partagez donc jamais votre server.cfg complet quand vous demandez de l'aide quelque part, mais retirez d'abord la chaîne de connexion. Et respectez l'ordre : d'abord la chaîne de connexion, puis ensure oxmysql, et seulement ensuite votre framework. Si oxmysql ne démarre pas en premier, votre framework se lance avec des erreurs de base de données et les joueurs ne peuvent même pas se connecter.
Comment ESX et QBCore utilisent votre base de données
Vous n'avez pas besoin de devenir administrateur de bases de données, mais une vue d'ensemble aide énormément à résoudre les problèmes. Lors de l'installation de votre framework, vous importez un fichier .sql fourni qui crée les tables de base. ESX conserve par exemple les joueurs dans une table users et les véhicules dans owned_vehicles ; QBCore utilise entre autres players et player_vehicles. Chaque script conséquent que vous installez ensuite (garages, maisons, métiers) livre souvent son propre fichier .sql avec des tables supplémentaires. Importez-les proprement, sinon vous aurez des erreurs de console sur des tables manquantes dès que le script voudra enregistrer quelque chose.
Si vous voulez consulter les données vous-même, c'est possible via la gestion de bases de données de votre panel ; la base de connaissances explique comment créer et gérer une base de données. Regarder est toujours permis, mais soyez prudent avec les modifications manuelles. Modifier de l'argent ou des objets directement dans une table pendant que le serveur tourne sera écrasé à la prochaine sauvegarde, ou pire, produira des données incohérentes. Pour ce genre d'interventions, utilisez plutôt les outils d'administration de votre framework.
Repérer les requêtes lentes
Une base de données qui répond lentement donne l'impression d'un lag serveur : des accrocs à la connexion, des objets qui apparaissent paresseusement dans votre inventaire, une ville qui semble lourde alors que le processeur n'a presque rien à faire. Voici comment déterminer si la base est la coupable :
- Les métriques txAdmin. Le tableau de bord de txAdmin montre les performances de votre serveur et les ressources qui consomment du temps. Si les pics coïncident avec les moments où beaucoup de données sont enregistrées, comme les sauvegardes planifiées ou l'affluence, cela pointe vers la base de données.
- La console. oxmysql peut signaler les requêtes lentes dans la console de votre serveur, y compris la ressource qui les a déclenchées. C'est de l'or en barre : vous voyez immédiatement quel script cause le problème.
- Tester après chaque installation. Si vous remarquez des accrocs juste après l'ajout d'un nouveau script, vous avez déjà trouvé votre suspect. Ajoutez donc les gros scripts un par un et surveillez les métriques de près les premiers jours.
La cause n'est pratiquement jamais "MySQL est lent", mais presque toujours un script qui écrit trop ou trop souvent, par exemple en sauvegardant des inventaires complets toutes les quelques secondes. La solution se trouve alors dans le script : un intervalle de sauvegarde plus large, ou une alternative mieux écrite. Une offre plus puissante ne fait que masquer un tel problème pendant un temps.
Les sauvegardes : le sujet le plus ennuyeux, jusqu'au jour où vous en avez besoin
Votre base de données contient tout ce que votre communauté a construit. Une mise à jour de framework ratée ou un script qui vide une table, et des mois de personnages et de biens disparaissent. Par conséquent :
- Faites une sauvegarde avant chaque changement majeur. Mise à jour de framework, nouveau script d'inventaire, grande migration : exportez d'abord, installez ensuite.
- Automatisez des sauvegardes récurrentes via la fonction de sauvegarde de votre panel, et téléchargez-en régulièrement une sur votre propre ordinateur.
- Testez une restauration de temps en temps. Une sauvegarde que vous n'avez jamais restaurée est une supposition, pas une certitude.
Cela semble excessif, jusqu'au jour où ça tourne mal. Dans une communauté RP, la base de données n'est pas de simples données : c'est la progression de tous vos joueurs, et ils comptent sur vous pour en prendre soin.