Bonjour Invité, vous êtes ici : Connexion

Isotools Wiki

RSS RSS

Navigation







Rechercher dans le wiki
»

Image

Option -repair dans les synchronisations

RSS
Modifié le 02/01/2012 10:21 par Nicolas Paris Catégorisé comme Boutique, Synchro

Synchronisation incrémentale

La synchronisation fonctionne de manière incrémentale pour éviter de retransmettre à chaque synchronisation l'intégralité des enregistrements de toutes les tables d'une source de données.

Le mécanisme de la gestion de l'incrémentalité est basée sur l'existence de la base miroir qui permet de stocker l'état supposé des enregistrements stockés dans le site. Cette base contient une table pour chaque table cible à synchroniser du site, respectant le modèle de cette dernière.

Colonne status

Une colonne supplémentaire de nom status permet de conserver l'état de synchronisation entre la base miroir et de celle du site. Les valeurs suivantes codent différents états:

1) 'A' comme Acknowledge ou Aquitté indique que l'enregistrement courant est à jour sur le site

2) 'M' comme Modified ou Modifié indique que l'enregistrement courant n'est pas à jour sur le site et qu'il faudra donc l'envoyer pour mettre à jour le site

3) 'D' comme Deleted ou Détruit indique que l'enregistrement courant n'existe plus dans la source de donnée mais qu'il existe encore sur le site et qu'il faut envoyer un ordre de destruction.

Reprise sur erreur réseau

Comme le réseau n'est pas toujours disponible, il arrive qu'une synchronisation s'arrête en cours de traitement. La colonne status permet alors de garder trace du travail partiellement effectué. La synchronisation suivante, si le réseau est rétabli permettra de transmettre la fin de travail de synchronisation, contenant à la fois les mouvements nécessités par la première synchronisation non traitée et la synchronisation courante. Ce mécanisme de reprise à chaud permet d'achever le travail comme si l'erreur réseau n'avait pas eu lieu.

Il se peut qu'on observe une désynchronisation au bout d'un certain temps: le contenu connu du site stocké dans la base miroir n'est pas le même que celui du site. La base miroir et la base du site sont alors désynchronisés.

Lorsque cela se produit, chaque synchronisation indique cet état de fait avec un message suggérant d'utiliser l'option -repair pour procéder à la réparation des tables désynchronisées.

Option -repair

Lorsqu'une table a été synchronisée avec succès, tous les enregistrements de la base miroir ont la valeur 'A' comme status, ce qui signifie qu'en thèorie tous les enregistrements existants dans la base miroir ont été transmis au site avec succès. Dans cet état, la synchronisation va demander au site le compte d'enregistrements de la table issus de cette source de données. Deux cas de figure peuvent arriver:

1) les deux comptes coïncident: il y a autant d'enregistrements dans la table du site que dans celle de la base miroir et on peut alors penser que ces deux tables sont bien en phase

2) les deux sont différents: il peut alors manquer des enregistrements sur le site ou à l'inverse, il peut y avoir trop d'enregistrement, voir même les deux.

Dans ce dernier, pour une synchronisation normale un message d'alerte est émis notifiant cet état de fait et suggérant l'utilisation de l'option -repair

Si l'option -repair est utilisée alors la synchronisation va chercher à renvoyer tous les enregistrements pour s'assurer que le site recevra l'intégralité de l'information. Pour être sûr qu'il ne restera pas d'enregistrements surnuméraires sur le site, tous les enregistrements stockés dans la table concernée du site vont être marqués en identifiant la réparation courante.

Le script de synchronisation renvoie alors par lot tous les enregistrements de la table et lorsque ceux-ci sont synchronisés dans la table du site, s'ils correspondent à des enregistrements existants (et donc marqués), la marque est alors enlevée.

Si cette synchronisation se termine avec succès, alors la table du site va contenir les enregistrements à jour et éventuellement des enregistrements marqués correspondant à des enregistrements sur-numéraires qu'il convient alors de détruire. Le script de synchronisation envoie au site l'ordre de faire ce ménage et on dispose alors d'une table parfaitement à jour.

Doit-on activer systématiquement l'option -repair?

Cette option semble assez magique et le web-master est souvent tenté de systématiser son utilisation. En tant normal la réparation ne se fait et donc cela ne va induire un traitement supplémentaire que lorsque la désynchronisation est constatée.

Néanmoins, nous suggérons de ne pas systèmatiser cette usage et de le faire que lorsque c'est nécessaire. En fait, lorsqu'une table contient un nombre très importants d'enregistrements, la réparation d'une telle table va être longue et va consommer quelques ressources sur le serveur du site ainsi que sur celui de synchronisation.

En fonction du traffic sur le site, il peut être préférable de choisir le meilleur moment pour consommer ces ressources et ainsi éviter de perturber le site à un moment critique.

De plus, pour être sûr ne pas nettoyer trop rapidement des enregistrements, le marquage des enregistrements utilisent une clé unique. Si le script de synchronisation est utilisé en mode -repair, le nettoyage final des enregistrements sur-numéraires n'est fait que si la synchronisation n'a pas été interrompue. Dans le cas d'une table de grande taille, le temps de synchronisation peut être assez long. C'est pourquoi il est important de contrôler le moment de cette réparation pour se placer dans les meilleurs conditions

Pourquoi l'option repair est-elle nécessaire?

En principe, si tout fonctionne correctement cette option devrait être inutile. Nous allons néanmoins lister les cas de figure connu qui peuvent provoquer cette desynchronisation:

1) problème de base de donnée. Si un backup est amené à être fait sur la base de données du site, l'état de celle-ci ne sera plus la même que l'état atteint lors de la dernière synchronisation.

2) L'appartenance d'un enregistrement à une source de données peut être modifié.

3) la disparition accidentelle d'enregistrements sur la base du site due soit à l'application d'une requête (manuelle ou automatique) mal maitrisée.

Nous allons détailler le dernier point. La base de données du site contient des données issues de différentes sources. Il peut s'agir de données issues du studio (et contenu dans le fichier .isdx). Il peut s'agir de données issues de sources de données. Enfin des enregistrements pour être créés en ligne soit en front-office soit en back-office.

Une même table (par exemple la table des utilisateurs) peut être alimentée par des enregistrements provenant de plusieurs sources. Il est donc important que l'option -repair ne supprime pas les enregistrements qui sont venus par une autre source (ou bien ceux créés en ligne). C'est pourquoi il existe dans chaque table du site deux colonnes (iso_clientId et iso_action) permettant d'identifier l'origine des enregistrements. Cette information indique alors une notion d'appartenance de l'enregistrement à une source particulière.

On tient compte de cette information lors de la réparation des tables pour ne traiter que l'information vraiment lié à la source de données.

Il peut arriver que cette notion soit perturbée de deux manières:

1) deux sources de données peuvent faire venir une même information. L'usage des clés de synchronisation fait que l'enregistrement cible sera unique et donc réputé n'appartenir qu'à la dernière source de données qui l'a synchronisé.

2) une action en back-office ou en front-office a conduit à l'écriture de cet enregistrement et donc à son appropriation par le site. La synchronisation suivante va alors réclamer une réparation qui n'est pas forcément nécessaire car elle dénote uniquement ce changement de propriétaire.

L'option -repair réapproiera l'enregistrement à la source de données et vera disparaitre des synchronisations suivantes ce message de besoin de répération.

Retour à la documentation Isotools

WikiMarkup Reference

(note : l'aperçu ne permet pas de voir certains formatages qui seront pourtant corrects une fois la page enregistrée)