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

SQL Procédural MySQL Discussion :

[InnoDB] Déroulement d'une transaction


Sujet :

SQL Procédural MySQL

  1. #1
    Membre éclairé Avatar de jp_rennes
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    72
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Mars 2006
    Messages : 72
    Par défaut [InnoDB] Déroulement d'une transaction
    Je viens d'installer une BD Mysql 5 en moteur innodb
    après avoir lu différentes documentations en ligne, je ne suis pas sûr d'avoir tout compris sur le systéme de transactions :
    d'après ce que j'ai compris une transaction qui commence par un begin et se termine soit par un commit soit par un rollback
    je sais que le moteur utilise des fichiers de log ib_logfile
    Question : pendant le déroulement de la transaction, ou quand et comment les informations passent-elles par le cache, les fichiers de log et quand sont elles vraiment écrites sur le disque.....?

    Merci par avance........


    [Titre édité par Maximilian]

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 414
    Par défaut
    je connais pas bien Mysql mais je connais bien DB2 et Oracle, je vais donc répondre avec mes connaissaces.

    Lors de la transaction, les données sont ramenées dans le cache, les informations dans les logs sont écrites de manière synchrone. Les données sont écrites sur disque de manière asynchrone après le commit.

  3. #3
    Membre Expert Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Par défaut
    Pour être plus précis, il faut qu'en cas de panne on puisse tout retrouver sur le disque. Donc :

    - Les journaux de transactions sont flushés sur le disque à chaque COMMIT (comportement modifiable avec la variable innodb_flush_log_at_trx_commit mais au risque de perdre des données en cas de crash).

    - Le buffer principal InnoDB est quant à lui partiellement flushé vers les fichiers de données sur le disque lorsqu'il devient plein.

    Rassemblés, ces deux éléments forment l'état de la base à un instant T et permettent une reprise sur panne.

  4. #4
    Membre éclairé Avatar de jp_rennes
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    72
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Mars 2006
    Messages : 72
    Par défaut
    Merci beaucoup pour les réponses : cela m'aide à mieux optimiser le back office que je suis entrain d'installer.
    Si j'ai bien compris et en reformulant :
    A chaque transaction, les données sont remontées du disque dans le cache innodb(( celui dont on peut modifier la valeur avec innodb_buffer_pool_size) puis les données sont modifiées en cache pendant le déroulement de la transaction).
    En parallèle, à chaque instruction, le cache du journal innodb est également rempli.
    Quand le commit est fait, le cache du journal innodb est écrit sur disque (dans les fichier ib_logfile0 et 1) sauf si on a modifié la valeur par défaut de innodb_flush_log_at_trx.
    Enfin quand le cache principal innodb est plein, il est écrit sur disque.

    Question 1 : ce cache du journal innodb est-il paramètrable ?
    Question 2 : En cas de crah du serveur, à la relance de celui-ci il va automatiquement lire les fichiers journaux et mettre à jour la base ?
    Question 3 : En cas de rollback de la part de l'utilisateur, les données sont-elles simplement effacées du cache du journal innodb ?
    Question 4 : il y a t'il quelque part, une doc précise expliquant les résultats de la commande show engine innodb (j'ai déjà lu celle proposée par le site officel de mysql) ?
    par exemple en savoir plus sur les deadlocks les sémaphores.....

  5. #5
    Membre Expert Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Par défaut
    Citation Envoyé par jp_rennes
    A chaque transaction, les données sont remontées du disque dans le cache innodb
    Oui, quand elles n'y sont pas déjà.

    Citation Envoyé par jp_rennes
    Question 1 : ce cache du journal innodb est-il paramètrable ?
    Au niveau de la taille ? Oui, ce qui peut permettre de faire rentrer de plus ou moins grosses transactions dedans.

    Citation Envoyé par jp_rennes
    Question 2 : En cas de crah du serveur, à la relance de celui-ci il va automatiquement lire les fichiers journaux et mettre à jour la base ?
    Oui, les changements commités mais qui n'avaient pas été écrits sur le disque vont l'être (redo log) et les modifications non commitées vont être annulées (undo log).

    Citation Envoyé par jp_rennes
    Question 3 : En cas de rollback de la part de l'utilisateur, les données sont-elles simplement effacées du cache du journal innodb ?
    Effacées s'il s'agit d'une insertion, remises dans l'état précédent pour une modification ou une suppression.

    Citation Envoyé par jp_rennes
    Question 4 : il y a t'il quelque part, une doc précise expliquant les résultats de la commande show engine innodb (j'ai déjà lu celle proposée par le site officel de mysql) ?
    par exemple en savoir plus sur les deadlocks les sémaphores.....
    Tu peux regarder ici : http://dev.mysql.com/doc/internals/en/index.html il y a peut-être plus de précisions sur les mécanismes système derrière les transactions.

    Sinon pour les sémaphores, deadlocks, etc. tu dois pouvoir trouver des cours de programmation système sur le net...

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. utiliser une transaction avec le composant DBExpress
    Par vbcasimir dans le forum Bases de données
    Réponses: 1
    Dernier message: 09/06/2005, 14h10
  2. Fonctionnement simplifié d'une transaction Oracle
    Par jack554 dans le forum Oracle
    Réponses: 7
    Dernier message: 21/04/2005, 10h25
  3. comment identifier une transaction http?
    Par didier.cabale dans le forum Développement
    Réponses: 5
    Dernier message: 13/04/2005, 16h42
  4. [SGBD]Evaluation du temps d'une transaction
    Par vsavoir dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 26/10/2004, 17h53
  5. Utilisation d'une transaction
    Par Bernard M dans le forum Bases de données
    Réponses: 6
    Dernier message: 21/04/2004, 23h31

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