Backup 'en live' et accès non prioritaire aux archives
Bonjour,
étant un joli newbie en matière de BdD, je suis totalement perdu concernant les pistes à explorer pour mes soucis d'évolution. D'où mon post:
Le contexte:
Dans le cadre de mon petit projet de jeu du moment (cf. signature), j'utilise MySQL. J'ai deux 'services principaux' qui attaquent la base:
- mon serveur de jeu (via du JDBC) qui utilise la base pour stocker un peu tout ce qui se passe (joueurs inscrits, connexions/déconnexions, paties jouées, leur contenu, ...) + récupérer et mettre à jour les infos des profils des joueurs.
- mon serveur web (via PHP) qui ne fait pas grand chose pour le moment mais qui à terme fera tourner un site Drupal et utilisera la base en plus pour des stats avancées et publiques sur les parties jouées par chaque utilisateur depuis le lancement du jeu (elle 'tapera' donc dans les données générées par le serveur de jeu en plus de Drupal).
Le tout tourne en permanence sur un serveur dédié type Pentium Dual Core et 2Go de RAM.
Il y a toujours du monde connecté au jeu et au site web (24h/24, 100 joueurs minimum) qui sollicite donc en permanence la BdD.
Mes services (web et de jeu) ont absolument besoin que la base reste relativement réactive: si on perd une fois 1 seconde pour une requête c'est pas dramatique, mais si la base devient inaccessible (lockée, ...) pendant plus de 10 secondes, ça devient (très) problématique pour le serveur (de jeu notamment).
Concernant son contenu, je stocke dans la base à peu près tout ce qui se passe:
- les comptes utilisteurs, classement, ...
- les logs de toutes les connexions déconnexions, etc...
- les logs de tout ce qui s'est passé pendant chaque partie jouée.
Pour un ordre d'idée, la plus grosse table étant celle des parties jouées, avec actuellement 480 000 enregistrements (420Mo) et environ 50 000 enregistrements (50Mo) de plus chaque jour.
Les besoins:
1/ Je voudrais faire une sauvegarde quotidienne de l'ensemble de la base sans pour autant interrompre le serveur. Que la sauvegarde prenne (très) longtemps n'est pas un souci, mais l'important est que:
- ça ne bloque aucune table pendant la sauvegarde
- ça ne ralentisse pas de façon trop marquée la bonne marche des services
- ça n'accapare ni toutes les ressources CPU, ni les IO sur le disque du serveur.
Bref, je préfèrerais que la sauvegarde mette 10x plus de temps mais qu'elle n'utilise que très peu de ressources supplémentaires pour son backup.
J'utilise pour le moment un mysqldump, mais j'ai l'impression qu'il me bloque toute la base pendant tout le temps où il la 'dumpe', ce qui n'est pas acceptable pour moi. Même idée pour les ressources utilisées: j'ai l'impression qu'il accapare un peu tout alors que je voudrais qu'il n'utilise que ce dont les autres services n'ont pas besoin (CPU et surtout disque).
2/ Je voudrais pouvoir éventuellement séparer les enregistrements récents (journée en cours) des 'archives' (jours précédents) en 'siphonnant' les tables prinicpales (parties, logs, connexion) et en les recopiant dans une autre table et/ou un autre base et/ou sur un autre serveur MySQL, le tout sans le faire dans une seule grosse requête qui rendrait la base indisponible pendant trop longtemps.
3/ A terme l'ensemble des archives devra être accessible (via le site web pour les utilisateurs) pour générer des stats. Par exemple le joueur voudra connaître le nombre de parties jouées depuis son inscription, l'évolution de son classement au fil du temps, les adversaires avec lesquels il a le plus joué et le ratio vistoire/défaite pour chacun d'eux, ...
D'où mes questions:
- il me faut clairement être capable de définir des 'priorités' entre chaque service: ceux qui ont besoin d'une base réactive (serveur de jeu) doit être prioritaire sur les services moins 'temps-réel' (archives, ...). Est-ce possible ?
- pour chaque solution (déplacement de données pour archivage, backup, ...), il faut que dans tous les cas rien ne me locke les tables pendant une durée de plusieurs secondes. Quelle solution ?
- Y a-t-il un intérêt 'technique' (lock, réactivité, mémoire, CPU, IO disque, ...) à séparer mes différents types de données (drupal, données du jeu courantes, données 'archivées') dans:
* plusieurs tables distinctes dans la même base (cf. données de jeu 'courantes' vs archives) ?
* plusieurs bases distinctes sur le même serveur ?
* des serveurs carrément distincts (deux démons MySQL qui tournent sur le même serveur physique) ?
Bref, vos avis là dessus et les pistes que je devrait d'emblée laisser tomber et celles à regarder de plus près.
PS: désolé pour ce roman fleuve mais c'est assez dur pour moi d'expliquer le contexte sans rentrer un minimum dans les détails. En espérant que ça ne vous décourage pas de me donner quelques pistes ;)
