SLONIK SUBSCRIBE SET

Description

Cette commande réalise une des deux opérations suivantes :

Initie la réplication pour un ensemble de réplication.

Ceci déclenche la réplication sur un nœud (abonné) soit à partir de l'origine soit à partir du fournisseur, qui doit être lui-même un nœud abonné actif et transmetteur (« forwarding subscriber »).

Les tables de l'application contenues dans l'ensemble de réplication doivent déjà exister et, idéalement, elles sont vides. La version courante de Slony-I™ ne tente pas de copier le schéma de l'ensemble de réplication. Le démon de réplication démarre et commence à copier le contenu de l'ensemble de réplication à partir du fournisseur spécifié, puis essaie de rattraper son retard en rejouant les mises à jour qui se sont produites lors du processus de copie. Un fois que l'abonnement a réussi, les tables sont protégées avec des triggers contre les mises à jour en provenance de l'application.

Si les tables sur l'abonné ne sont pas vides, alors l'événement COPY SET (qui fait partie du processus d'abonnement) devra effectuer quelques taches supplémentaires :
- Il tente d'effectuer une TRUNCATE sur la table, ce qui devrait être efficace.
- Si cela ne fonctionne pas (une relation sur une clef étrangère empêche peut-être le fonctionnement de TRUNCATE), il utilise la commande DELETE pour effacer toutes les « anciennes » entrées de la table.
- Ces anciennes données encombrent encore l'espace disque jusqu'à ce qu'un VACUUM soit effectué après la fin du processus d'abonnement.
- Les index de la table contiendront des références aux anciennes données, ce qui ralentira l'insertion de nouvelles données dans les index.
Avertissement
Le temps d'exécution de cette opération n'est pas négligeable. Si vous avez un grand volume de données dans un ensemble particulier de tables, cela peut prendre plusieurs heures, voire plusieurs jours pour que l'opération aboutisse (ici « un grand volume » signifie « des dizaines ou des centaines de gigaoctets de données »).

Cependant, la requête SUBSCRIBE SET se terminera presque immédiatement, même si les travaux, gérés par l'événement COPY SET, sont encore en cours. Si vous devez configurer les abonnements sur des nœuds en cascade, vous devez attendre que chaque abonné ait terminé son abonnement avant de soumettre des requête d'abonnement qui utilisent ce nœud comme fournisseur. Si vous ne le faites pas, ce n'est pas très grave : slonik va vérifier le nœud, découvrir qu'il n'est pas encore un fournisseur actif et reporter l'erreur suivante :
```
 Slony-I: provider 2 is not an active forwarding node for replication set 1
```
En pratique, de telles requêtes d'abonnement seront ignorées jusqu'à ce que le fournisseur soit prêt.
Modifier les informations d'abonnement pour les nœuds qui sont déjà abonnés.

Si vous devez modifier les informations d'abonnement pour un nœud donné, vous devez également soumettre les nouvelles informations avec cette commande, et la nouvelle configuration sera propagée à travers le réseau de réplication. En général, on modifie les informations d'abonnement lorsqu'on veut abonner un nœud à un fournisseur différent ou transformer un nœud en « transmetteur » afin qu'il puisse à son tour devenir le fournisseur d'un autre abonné.

ID = ival

Identifiant de l'ensemble auquel on s'abonne

PROVIDER = ival

Identifiant du nœud fournisseur qui transmet les données à ce nœud

RECEIVER = ival

Identifiant du nouveau nœud abonné

FORWARD = boolean

Indique si le nouvel abonné doit stocker les logs pendant la réplication afin de pouvoir devenir fournisseur pour de futurs nœuds. Tout nœud qui a pour but d'être un candidat pour le FAILOVER doit avoir FORWARD = yes.

OMIT COPY = boolean

Indique si le processus d'abonnement doit omettre la commande COPY pour les données pré-existante dans l'ensemble. En effet, utiliser cette option indique clairement « Faites-moi confiance, les données sont déjà synchronisées ! »

Ceci est particulièrement utile dans les cas suivants :

Une mise à jour de version majeure (par exemple de Slony-I™ 1.2 à 2.0) pourra être beaucoup plus rapide.
Cloner un « nœud maître ». SLONIK CLONE PREPARE(7)/SLONIK CLONE FINISH(7)

Cette commande utilise schemadocsubscribeset( integer, integer, integer, boolean ).

Exemple

SUBSCRIBE SET (
   ID = 1,
   PROVIDER = 1,
   RECEIVER = 3,
   FORWARD = YES
);

Transmission

Le paramètre FORWARD=boolean indique si le l'abonné doit conserver les informations dans les tables sl_log_1 et sl_log_2. Ceci implique plusieurs choses...

Stocker les données dans ces tables sur l'abonné représente une charge supplémentaire. Si vous êtes certain(e) que vous n'effectuerez jamais les opérations SLONIK MOVE SET(7) ou SLONIK FAILOVER(7) sur un abonné particulier, il vaut mieux désactiver la transmission sur ce nœud.

Cela étant dit, dans certains cas, le fait de désactiver cette option peut poser des problèmes lorsqu'on se trouve dans une situation inattendue. De manière empirique, on considère qu'il est préférable que tout nœud connecté directement à l'origine soit un « nœud transmetteur ». Il est possible que ce nœud soit perdu lors d'une bascule d'urgence. Le problème survient lorsque ce nœud est en avance sur les autres nœuds.

Supposons que l'origine, le nœud 1, est au numéro de SYNC 88901, un nœud non-transmetteur, le nœud 2 en est arrivé au numéro 88897, tandis que les autres nœuds transmetteur, 3, 4, et 5, en sont seulement au SYNC numéro 88895. À ce moment, le disque système sur le nœud origine prend feu. Le nœud 2 possède les données à jour jusqu'à 88901, mais aucun nœud transmetteur ne dispose, dans les tables sl_log_1 ou sl_log_2, des données correspondant aux événements SYNCs numérotés 88896 et 88897. Il n'y a donc aucun moyen de ramener les nœuds 3-5 à ce niveau.

À ce stade, vous avez deux choix : supprimer le nœud2 car il n'existe aucun moyen de le maintenir, ou supprimer tous les nœuds sauf le nœud 2, car il n'existe aucun moyen de les amener jusqu'à l'événement SYNC 88897.

Ce dilemme peut être évité en s'assurant que tous les nœuds directement abonnés à l'origine sont des transmetteurs.

Comportement dangereux et non-intuitif

Le fait que la requête se termine immédiatement même si l'abonnement prend un temps considérable est parfois surprenant.

Le traitement des abonnements implique deux événements ; l'opération SUBSCRIBE_SET, initié sur le nœud fournisseur, et une opération ENABLE_SUBSCRIPTION, qui est initiée sur le nœud abonné. Cela signifie que SLONIK WAIT FOR EVENT(7) ne peut pas attendre la fin d'une souscription. Si vous souhaitez attendre la fin d'un abonnement, alors vous devez soumettre une requête SLONIK SYNC(7) et attendre que cet événement s'achève.
Cette commande a deux objectifs : mettre en place des abonnements (ce qui n'est très surprenant) et modifier des abonnements, ce qui n'est pas forcément intuitif.
Les nouveaux abonnements sont définis en utilisant DELETE ou TRUNCATE pour vider les tables sur l'abonné. Si vous avez créé un nouveau nœud en recopiant les données à partir d'un nœud existant, il peut « paraître évident » que ces données seront conservées. Ce n'est pas le cas, l'ancien contenu est détruit et le nœud est re-peupler à partir de zéro.
L'option OMIT COPY est un très gros risque car il permet à l'administrateur d'avoir des ensembles de réplication non synchronisés.

Utilisation de verrous

Cette opération ne nécessite pas de verrous sur le nœud fournisseur.

Sur le nœud abonné, l'opération placera un verrou sur toutes les table de l'ensemble de réplication. Dans la version 1.2, les verrous exclusifs sont placés au début du processus ; dans les versions antérieures, les verrous sont placés implicitement uniquement lorsque qu'une activité le demande, ce qui laisse une possibilité d'inter-blocage (« deadlock ») si d'autres applications peuvent accéder à la base à ce moment-là.

Note de version

Cette commande fut introduite dans Slony-I™ 1.0.

L'option OMIT COPY a été introduit dans Slony-I™ 2.0.3.

Documentation Slony-I 2.0.3 -

Commande de configuration et d'action