IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration MySQL Discussion :

Backup 'en live' et accès non prioritaire aux archives


Sujet :

Administration MySQL

  1. #1
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut 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
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    351
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 351
    Points : 432
    Points
    432
    Par défaut
    Voici un lien sur les options de mysldump qui pourrait résoudre ton problème.

    http://www.sens-interdit.fr/2007/07/...b-grosse-table

Discussions similaires

  1. ADOQuery avec Checkbox non liée aux données
    Par StarMusic dans le forum Delphi
    Réponses: 6
    Dernier message: 25/05/2007, 17h45
  2. Réponses: 6
    Dernier message: 06/01/2007, 19h07
  3. Chemin d'acces non valide
    Par Alex063 dans le forum Access
    Réponses: 13
    Dernier message: 28/03/2006, 12h29
  4. Accès non autorisé à l'exécution d'une procédure stockée
    Par celine33 dans le forum Bases de données
    Réponses: 6
    Dernier message: 11/01/2006, 11h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo