9. Voix d'écoute
![[Note]](images/note.png)
Note
Si vous utilisez une version Slony-I™ 1.2 ou ultérieure, il est complètement inutile de lire cette section car cette version dispose d'une méthode de gestion automatique de cette partie de la configuration. Pour les versions antérieures, cependant, ce qui va suivre est nécessaire.
Si vous avez plus de deux ou trois nœuds et un niveau d'abonnement en cascade (c'est-à-dire des nœuds qui s'abonnent à des nœuds abonnés), vous devez être très prudent avec la configuration des « voix d'écoute » par les commandes Slonik SLONIK STORE LISTEN(7) et SLONIK DROP LISTEN(7) qui contrôlent le contenu de la table sl_listen.
Les entrées de cette table contrôlent où chaque nœuds doit écouter afin d'obtenir les événements propagés par les autres nœuds. Vous vous dîtes peut-être que chaque nœud doit simplement écouter le nœud « parent » qui leur transmet les mise à jours mais, en réalité, ils doivent pouvoir recevoir des messages de la part de tous les nœuds afin de pouvoir déterminer si les SYNCs ont été reçues partout et que les entrées de sl_log_1 et sl_log_2 ont été appliquées partout et qu'elles peuvent être purgées. Ces communications supplémentaires permettent à Slony-I™ de déplacer les origines vers d'autres nœuds.
9.1. Comment l'écoute peut être rompue
À une occasion, j'ai eu besoin de supprimer un nœud abonné (#2) et de la recréer. Ce nœud était le fournisseur d'un autre abonné (#3) qui était, de facto, un « esclave en cascade ». La suppression du nœud abonné ne fonctionna pas, en effet slonik(1) m'informa qu'il existait un nœud dépendant. Je fis pointer le nœud dépendant vers le nœud « maître » de l'ensemble de réplication, ce qui se déroula, pour un temps, sans difficultés.
Je supprimais alors l'abonnement du « nœud 2 », et tentais de l'abonner de nouveau. Cela déclencha un événement Slony-I™ set_subscription, qui commença à copier les tables. À ce moment, les événements ne furent plus propagés au « nœud 3 », et tandis qu'il était en parfait état de fonctionnement, plus aucun événement ne lui parvenait.
Le problème était que le nœud #3 attendait de recevoir des événements de la part du nœud #2, qui était occupé par le traitement de l'événement set_subscription et ne transmettait aucune autre information.
Nous avons supprimé les règles qui ordonnaient au nœud #3 d'écouter le nœud #2, en les remplaçant par des règles qui lui indiquaient d'attendre les événements en provenance du nœud #1 (le nœud origine de la réplication). À ce moment, « comme par magie », le nœud #3 recommença à répliquer car il avait découvert une source où écouter les évènements SYNC.
9.2. Comment configurer les écoutes
Les cas simples sont facile à gérer. Intéressons-nous plutôt à une configuration plus complexe.
Considérons un ensemble de nœuds, de 1 à 6, où 1 est l'origine, 2-4 sont abonnés directement à l'origine, 5 est abonné à 2, et 6 est abonné à 5.
Voici un « réseau d'écoute » qui montre où chaque nœud doit écouter les messages en provenance des autres nœuds :
1| 2| 3| 4| 5| 6|
--------------------------------------------
1 0 2 3 4 2 2
2 1 0 1 1 5 5
3 1 1 0 1 1 1
4 1 1 1 0 1 1
5 2 2 2 2 0 6
6 5 5 5 5 5 0
La ligne 2 indique toutes les règles d'écoute pour le nœud 2 ; il obtient les événements des nœuds 1, 3 et 4 chez le nœud 1 et il écoute sur le nœud 5 les événements des nœuds 5 et 6.
La dernière ligne composée de 5, celle du nœud 6, indique que le nœud 6 écoute le nœud 5 pour obtenir les événements des nœuds 1 à 5.
Les commandes slonik set listen qui expriment ce « réseau d'écoute » sont les suivantes :
store listen (origin = 1, receiver = 2, provider = 1); store listen (origin = 1, receiver = 3, provider = 1); store listen (origin = 1, receiver = 4, provider = 1); store listen (origin = 1, receiver = 5, provider = 2); store listen (origin = 1, receiver = 6, provider = 5); store listen (origin = 2, receiver = 1, provider = 2); store listen (origin = 2, receiver = 3, provider = 1); store listen (origin = 2, receiver = 4, provider = 1); store listen (origin = 2, receiver = 5, provider = 2); store listen (origin = 2, receiver = 6, provider = 5); store listen (origin = 3, receiver = 1, provider = 3); store listen (origin = 3, receiver = 2, provider = 1); store listen (origin = 3, receiver = 4, provider = 1); store listen (origin = 3, receiver = 5, provider = 2); store listen (origin = 3, receiver = 6, provider = 5); store listen (origin = 4, receiver = 1, provider = 4); store listen (origin = 4, receiver = 2, provider = 1); store listen (origin = 4, receiver = 3, provider = 1); store listen (origin = 4, receiver = 5, provider = 2); store listen (origin = 4, receiver = 6, provider = 5); store listen (origin = 5, receiver = 1, provider = 2); store listen (origin = 5, receiver = 2, provider = 5); store listen (origin = 5, receiver = 3, provider = 1); store listen (origin = 5, receiver = 4, provider = 1); store listen (origin = 5, receiver = 6, provider = 5); store listen (origin = 6, receiver = 1, provider = 2); store listen (origin = 6, receiver = 2, provider = 5); store listen (origin = 6, receiver = 3, provider = 1); store listen (origin = 6, receiver = 4, provider = 1); store listen (origin = 6, receiver = 5, provider = 6);
Ces lignes de commandes d'écoute sont lues lorsque...
... le nœud « récepteur » cherche un nœud « fournisseur » pour obtenir les événements en provenance du nœud d'« origine ».
L'outil init_cluster parmi les scripts altperl produit un réseau d'écoute optimisé sous forme de tableau et ainsi qu'une liste de commandes slonik(1).
Il y a trois « épines » dans ce bouquet de roses :
-
Si vous changez la structure de l'ensemble de nœuds, alors les nœuds sont abonnés différemment et vous devez supprimer les entrées de la table sl_listen et en créez de nouvelles pour décrire les nouvelles voies d'écoute entre les nœuds. Jusqu'à Slony-I™ 1.2, il n'y a aucune manière automatique de réaliser cette « restructuration ».
-
Si vous ne changez pas les entrées de sl_listen, les événements se propageront tant que les nœuds fonctionnent correctement. Le problème se déclenchera lorsqu'un nœud sera retiré, rendant « orphelin » les nœuds qui l'écoutaient.
-
Vous pouvez essayer de multiples ensembles de réplication qui ont des structures différentes pour leur arborescence d'abonnés. Il n'y aucune configuration d'écoute qui convienne parfaitement dans ce cas.
-
Afin de créer une voie sl_listen, il doit exister une série d'entrées sl_path qui connectent l'origine au récepteur. Cela implique que si le contenu de sl_path ne définit pas que le réseau est « connecté » de nœuds, alors certains nœuds ne seront pas accessibles. Typiquement, cela peut se produire, lorsque vous avez deux ensembles de nœuds, placés sur deux sous-réseaux séparés, avec simplement deux nœuds « pare-feu » qui communiquent d'un sous-réseau à l'autre. Couper un de ces nœuds et les sous-ensembles de réplication s'arrêtent.
Dans Slony-I™ version 1.1, une règle heuristique est introduite pour générer automatiquement les entrées sl_listen. Cela se fait en fonction de trois types d'informations :
-
Les entrées de sl_subscribe sont des informations primordiales et vitales sur qui doit écouter quoi ; nous savons qu'il doit y avoir une voie directe entre chaque abonné et son fournisseur.
-
Les entrées sl_path sont le second indicateur ; si la table sl_subscribe n'indique pas « comment écouter », alors un nœud peut écouter directement l'origine s'il existe une voie praticable dans sl_path.
-
Enfin, si aucune indication n'a été obtenue à partir des informations précédentes. alors les nœuds peuvent écouter indirectement via un nœud qui est fournisseur de l'abonné, ou qui utilise l'abonné comme fournisseur.
À chaque fois que les tables sl_subscribe ou sl_path sont modifiées, la fonction RebuildListenEntries() est appelée pour mettre à jour les voies d'écoute.
Effectuer une bascule
d'urgence avec Slony-I
