 Voies de communication Slony-I
|
 
|
Problèmes de verrous
|
Slony-I™ a connu deux « types » de gestion pour les triggers
Jusqu'à la version 1.2, PostgreSQL™ n'avait pas conscience de la réplication, ce qui impliquait que Slony-I™ avait besoin que l'on « modifie directement » le catalogue système afin de désactiver, sur les nœuds abonnés, les triggers qui ne devaient pas être exécutés.
Ceci provoquait un certain nombre d'effets secondaires pénibles, tels que :
La corruption du catalogue système sur les nœuds abonnés car les triggers existants, qui sont généralement placés en cache, sont « modifiés directement » en changeant pg_catalog.pg_trigger pour qu'il désigne les index utilisés par Slony-I™ comme « clé primaire ».
Ceci est également vrai pour les règles (« rules »).
L'effet secondaire était que pg_dump ne pouvait pas être utilisé pour récupérer proprement les schémas des nœuds abonnés.
Cela introduit la nécessité de poser des verrous exclusifs sur toutes les tables répliquées lors de la commande Section 17, « Changements du schéma de la base (DDL) » puisque les triggers de chaque table répliquée devaient être supprimés et ajoutés à nouveau par cette opération.
Avec PostgreSQL™ version 8.3, il y a de nouvelles fonctionnalités qui permettent de modifier le comportement des triggers et des règles via la commande ALTER TABLE, et de spécifier une des options de triggers suivantes :
DISABLE TRIGGER nom_du_declencheur
ENABLE TRIGGER nom_du_declencheur
ENABLE REPLICA TRIGGER nom_du_declencheur
ENABLE ALWAYS TRIGGER nom_du_declencheur
DISABLE RULE nom_de_la_regle
ENABLE RULE nom_de_la_regle
ENABLE REPLICA RULE nom_de_la_regle
ENABLE ALWAYS RULE nom_de_la_regle
Une nouvelle variable GUC, session_replication_role contrôle si la session est en mode 'origin', 'replica' ou 'local', ce qui combiné avec les options d'activation/désactivation permet de contrôler si un trigger est effectivement exécuté.
On peut déterminer quand les triggers se déclenchent dans une réplication Slony-I™ en utilisant la table suivante ; le même principe s'applique aux règles.
Tableau 1. Comportement du trigger
| Type de trigger | Condition de déclenchement | Trigger de log | Trigger denyaccess | Action - origin | Action - replica | Action - local |
|---|---|---|---|---|---|---|
| DISABLE TRIGGER | requête utilisateur | désactivé sur les nœuds abonnés | activé sur les nœuds abonnés | ne se déclenche pas | ne se déclenche pas | ne se déclenche pas |
| ENABLE TRIGGER | par défaut | activé sur les nœuds abonnés | désactivé sur les nœuds abonnés | se déclenche | ne se déclenche pas | se déclenche |
| ENABLE REPLICA TRIGGER | requête utilisateur | inapproprié | inapproprié | ne se déclenche pas | se déclenche | ne se déclenche pas |
| ENABLE ALWAYS TRIGGER | requête utilisateur | inapproprié | inapproprié | se déclenche | se déclenche | se déclenche |
Il y a désormais plusieurs façons pour Slony-I™ d'interagir avec cela. Précisons les cas intéressants :
Avant que la réplication ne soit en place, chaque base de données démarre avec le statut « origin » et, par défaut, tous les triggers sont du type ENABLE TRIGGER afin qu'ils soient exécutés, comme dans un système non répliqué.
Lorsqu'un abonnement Slony-I™ est mis en place, sur le nœud d'origine, les triggers logtrigger et denyaccess sont ajoutés, le premier est activé et exécuté, le second est désactivé.
Au niveau des verrous, chaque instruction SLONIK SET ADD TABLE(7) demande brièvement un verrou exclusif sur les table où sont attachés les triggers, ce qui a toujours été le cas avec Slony-I™.
Sur le nœud abonné, le processus d'abonnement ajoutera les même triggers, mais avec une polarité « inversée » pour protéger les données d'une corruption accidentelle.
Au niveau des verrous, encore une fois, cela fait peu de différences avec l'ancien comportement car le processus d'abonnement, qui utilise TRUNCATE copie les données et altère le schéma des tables, nécessite de nombreux verrous exclusifs sur les tables, et les changements dans le comportement des triggers ne modifie pas ce besoin.
Toutefois, notez que la capacité d'activer ou désactiver les triggers d'une manière supportée par PostgreSQL™ signifie qu'il n'est pas nécessaire de « corrompre » le catalogue système, ainsi nous avons l'avantage considérable de pouvoir utiliser pg_dump pour obtenir une sauvegarde complète et cohérente sur n'importe quel nœud du cluster Slony-I™.
Si vous effectuez un pg_dump sur un nœud Slony-I™ et supprimez le namespace Slony-I™, cela supprime tous les composants Slony-I™ et laisse la base de données, y compris son schéma, dans un état cohérent et « vierge », prêt pour n'importe quelle utilisation.
L'opération Section 17, « Changements du schéma de la base (DDL) » est désormais réalisée d'une façon toute à fait différente : plutôt que d'altérer chaque table répliquée pour la « retirer du mode répliqué », Slony-I™ glissera simplement en statut local le temps de l'opération.
Sur le nœud origine, cela désactive le trigger logtrigger.
Sur chaque nœud abonné, cela désactive le trigger denyaccess.
Ceci devrait rendre les modifications DDL énormément moins coûteuses car, plutôt que de poser des verrous exclusifs sur toutes les tables répliquées (nécessaire pour les opérations de suppression et re-création des triggers Slony-I™), seules les tables impactées par le script DDL sont verrouillées.
Au moment d'invoquer SLONIK MOVE SET(7) sur l'ancien nœud origine, Slony-I™ doit transformer ce nœud en nœud abonné, ce qui nécessite de supprimer les triggers lockset, de désactiver les triggers logtrigger et d'activer les triggers denyaccess.
Au même moment, en réalisant SLONIK MOVE SET(7) sur le nouveau nœud origine, Slony-I™ doit transformer ce nœud en origine, ce qui implique la désactivation des triggers denyaccess, et d'activer les triggers logtrigger.
Au niveau des verrous, ceci ne change pas par rapport aux nouvelles versions de Slony-I™ car le verrouillage effectué ici est tout à fait nécessaire.
De le même manière que SLONIK MOVE SET(7), SLONIK FAILOVER(7) transforme un nœud abonné en nœud origine, ce qui nécessite de désactiver les triggers denyaccess, et d'activer les triggers logtrigger. Encore une fois, l'implémentation des verrous est quasiment identique.