 Problèmes de verrous
|
 
|
Ajouter des objets à la
réplication
|
Non, il ne s'agit pas compétitions sportives ; Wikipedia décrit ce terme ainsi : « Une situation de compétition, plus couramment nommée race condition, est un défaut dans un système électronique ou informatique, non prévu lors de la conception, caractérisé par un résultat différent selon l'ordre dans lequel sont effectuées certaines opérations du système. Lorsqu'une situation de compétition se produit, cela peut avoir des effets néfastes pendant une longue période, et le système peut nécessiter d'être réinitialisé. » Dans les applications informatiques, les situations de compétitions arrivent la plupart du temps au sein d'applications distribuées ou multiprocesseurs lorsque différentes parties de l'application dépendent de certains éléments partagé ; si ce partage est mal géré, des confusions (erreurs !) apparaissent. Plus précisément, cela implique en général des situations où l'état de partage peut être changé entre le moment où il est vérifié et le moment où il est utilisé.
Slony-I™ a connu un certain nombre de situations de compétition au cours de son histoire :
Entre la version 1.0 et la version 1.1, SLONIK MOVE SET(7) avait un problème car les nœuds n'avaient aucun moyen d'empêcher le traitement des événements SYNC en provenance du nœud origine (qu'ils considéraient comme un simple fournisseur, et pas comme une source de données à répliquer) avant de reconnaître le changement de rôle (d'abonné à fournisseur).
Ceci fût corrigé en introduisant un nouvel événement ACCEPT SET qui était soumis par le nouveau nœud origine; Ceci permettait aux abonnés d'être conscients qu'ils devaient attendre l'événement MOVE SET.
Dans un certain nombre d'emplacements, Slony-I™ utilise la commande SQL lock table sl_config_lock; afin d'éviter les situations de compétitions lorsque la valeur de la séquence sl_log_status est changée.
L'option slon(1) slon_conf_sync_interval_timeout est utilisée pour éviter les situations de compétition dans lesquelles la séquence d'action est dégagée par le trigger au moment de l'insertion de ligne de log, ce qui rend le « dégagement » immédiatement visible au processus de synchronisation, alors que la ligne de log correspondante n'est pas encore visible.
L'approche dite de « visibilité des images » utilisée par Slony-I™ pour déterminer quelle donnée répliquée doivent être associée avec un SYNC spécifique, évite les situations de compétition qui se produisent lorsque l'on essaie d'utiliser simplement des horodatages ou des plages d'identifiants pour déterminer quelles données doivent être répliquées.
Dans la branche 1.2, jusqu'à la version 1.2.11 qui corrige ce bogue, le log shipping avait une situation de compétition à chaque fois que la configuration était rechargée par le slon(1) (comme cela arrive souvent, notamment avec ???), il y avait un risque que les identifiants de SYNC utilisés pour l'ordonnancement correct et pour l'exécution du log shipping soient décalées d'une unité.
Ceci fut corrigé dans la version 1.2.11 en transformant le numéro d'identifant, qui était une variable située en mémoire (donc génératrice de problèmes) en une donnée transactionnelle, stockée dans la base de donnée de l'abonné.
Ce problème ne fut jamais découvert lors des bancs d'essai démontrant simplement que les situations de compétitions sont souvent très dépendantes du type de données stockée ou du rythme de l'application.