Le paramètre log_level spécifie le niveau de messages de débogage que slon doit afficher dans son journal d'activité.

Il y a neuf niveaux de débogage :

Les cinq premiers niveaux de débogage (de Fatal à Info) sont toujours affichés dans les traces. Dans les précédentes versions de Slony-I™, la valeur « suggérée » pour log_level était 2, qui fournit toutes les traces jusqu'au niveau de débogage 2. Dans Slony-I™ version 2, il est recommandé de configurer log_level à 0 ; la plupart des informations intéressantes dans les traces est générée à des niveaux supérieurs.

Le paramètre sync_interval, exprimé en millisecondes, indique à quelle fréquence slon doit vérifier si un événement SYNC doit être produit. La valeur par défaut est 2000 ms. La boucle principale dans sync_Thread_main() est endormie pendant des intervalles de sync_interval millisecondes entre chaque itération.

Un intervalle de vérifications très court garantit que le nœud origine soit « très suivi » car il met à jour les abonnés plus fréquemment. Si vous avez des séquences répliquées qui sont souvent mises à jour sans que certaines tables ne soient affectées, cela évite que des opérations qui mettent à jour uniquement ces séquences soient effectuées, et ainsi évite la génération d'événements de synchronisation.

Si un nœud n'est pas l'origine d'un ensemble de réplication, et donc qu'il ne reçoit aucune mise à jour des données répliquées, alors il est un peu inutile de mettre une valeur inférieure à celle du paramètre sync_interval_timeout.

À la fin de chaque période sync_interval_timeout, un événement SYNC est produit sur le nœud « local » même s'il n'y eu aucune mise à jour des données répliquées et qu'aucun SYNC n'a été généré.

Si l'activité de l'application s'arrête, soit parce que l'application a été éteinte, soit parce que les utilisateurs humains sont rentrés chez eux et arrêtés les mises à jour, alors le démon slon(1) continue de tourner et se réveille toutes les sync_interval millisecondes, et si aucune mise à jour ne s'est produite, alors aucun événement SYNC n'est généré. Sans ce paramètre « timeout », aucun événement SYNC ne pourrait être produit, et cela entraînerait la chute du système de réplication.

Le paramètre sync_interval_timeout provoque la génération de SYNC, même s'il n'y a pas réellement de travail de réplication a faire. Plus la valeur de ce paramètre est bas, plus les évènements SYNC lorsque l'application n'est pas active. Ceci a deux effets :

La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms. Par défaut, vous pouvez prévoir que chaque nœud soit « synchronisé » par un SYNC toutes les dix secondes.

Notez que des événements SYNC sont aussi générés sur chaque nœud abonné. Cependant, puisqu'ils ne contiennent pas de données à répliquer par les autres nœuds, les évènements SYNC des nœuds abonnés ne sont pas terriblement intéressants.

L'option sync_group_maxsize contrôle la taille maximale d'un groupe SYNC. La valeur par défaut est 6. Ainsi, si un nœud particulier a 200 événements SYNC de retard, il essaiera de les regrouper par groupes dont la taille maximale sera sync_group_maxsize. Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : « overhead ») en réduisant le nombre de transactions à « valider ».

La valeur par défaut, 6, est probablement adéquate pour les petits systèmes qui ne peuvent allouer que des quantités limitées de mémoire à slon. Si vous avez beaucoup de mémoire, il est raisonnable d'augmenter cette valeur car cela augmentera la quantité de travail réalisée à chaque transaction, et cela permettra à un nœud abonné de rattraper plus vite son retard.

Les processus Slon sont souvent très petits ; même en cas de valeurs très fortes pour cette option, slon devrait simplement grossir de quelques Mo.

Le gros avantage d'augmenter ce paramètre est que cela divise le nombre de transactions COMMIT ; passer de 1 à 2 aura probablement un impact considérable, mais le bénéfice se réduit progressivement lorsque la taille des groupes est suffisamment large. Il n'y aura probablement pas de différence notable entre 80 et 90. Rendu à ce niveau, l'augmentation de cette valeur dépend du fait que les grands ensembles de SYNC perturbent les curseurs de LOG en consommant de plus en plus de mémoire et nécessitant plus d'efforts lors des tris.

Dans Slony-I™ version 1.0, slon essaie toujours de regrouper un maximum de SYNC ensemble, ce qui n'est pas idéal si la réplication a été déstabilisée par de grosses mises à jour (par exemple, une transaction unique qui met à jour des centaines de milliers de lignes) ou lorsque les SYNC ont été interrompus sur un nœud origine, ce qui fait que les suivants sont volumineux. Vous rencontrerez ce problème : en regroupant des SYNC très larges, le processus slon peut échouer. Au redémarrage, il essaie à nouveau de traiter ce large ensemble de SYNC et il retombe sur le même problème encore et encore jusqu'à ce qu'un administrateur interrompe tout cela et change la valeur de l'option -g pour sortir de cette situation d'« inter-blocage ».

Au contraire, avec Slony-I™ 1.1 et les versions ultérieures, le démon slon s'adapte en augmentant « progressivement » le nombre de SYNC par groupe, de 1 jusqu'à la valeur maximale. Ainsi, si quelques SYNC posent problème, le démon slon pourra (s'il est surveillé par un processus chien de garde) traiter un par un ces évènements SYNC problématiques, et ainsi éviter l'intervention d'un administrateur.

La période « maximale » pour un groupe de SYNC.

Si la réplication est en retard, le démon slon va progressivement augmenter le nombre de SYNC groupés ensemble, dans le but de ne pas dépasser le temps spécifié par desired_sync_time (pour cela, Slon se base sur le temps pris par le dernier groupe de SYNC).

La valeur par défaut est 60000ms, c'est-à-dire une minute.

Ainsi, vous pouvez prévoir (en tout cas espérer !) que vous aurez un COMMIT environ toutes les minutes.

Cela n'est pas complètement prévisible car il est possible de demander une très grosse mise à jour qui fera « exploser » la taille du SYNC. Dans ce cas-là, l'heuristique sera rétablie pour le prochain groupe.

L'effet final est d'améliorer la façon dont Slony-I™ gère les variations du trafic. En commençant avec un événement SYNC, puis en augmentant progressivement, même si certaines variations seront assez grandes pour provoquer un crash du processus PostgreSQL™, Slony-I™ redémarrera en traitant un seul SYNC à la fois, afin que poursuivre le processus de réplication autant que possible.

La valeur vac_frequency indique la fréquence des opérations VACUUM lors des cycles de nettoyage.

Positionnez cette valeur à zéro pour désactiver les nettoyages initiés par slon. Si vous utilisez un mécanisme tel que pg_autovacuum pour lancer les VACUUM, vous n'aurez probablement pas besoin que slon initie des VACUUM de lui-même. Sinon, il existe des tables utilisées par Slony-I™ qui collectent beaucoup de lignes mortes et qui doivent être nettoyées fréquemment, en particulier pg_listener.

À partir de Slony-I™ version 1.1, cela change un peu ; le processus de nettoyage cherche, d'itération en itération, l'identifiant de la plus ancienne transaction encore active dans le système. Si l'identifiant ne change pas entre deux itérations, alors il existe une vieille transaction en activité, et donc un VACUUM n'apportera rien de bon. À la place, le processus de nettoyage déclenche simplement une opération ANALYZE sur ces tables afin de mettre à jours les statistiques dans pg_statistics.

La variable pid_file contient le nom du fichier dans lequel le PID (identifiant du processus) du démon slon est stocké.

Cela simplifie la création de scripts de surveillance des processus slon qui s'exécutent sur un hôte.

Fichier qui contient la configuration slon.

La configuration est détaillée plus loin dans le chapitre Configuration de Slon. Si vous avez défini un ensemble complexe de paramètre ou si vous ne voulez pas que les paramètres soient visibles dans les variables d'environnement (notamment les mots de passe), il est plus pratique de placer une partie, voire l'ensemble des paramètres dans un fichier de configuration. Vous pouvez également placer les paramètres communs à tous les processus slon dans un fichier de configuration partagé et définir en ligne de commande d'autres paramètres que les informations de connexions. Vous pouvez aussi créer un fichier de configuration pour chaque nœud.

L'option archive_dir indique le dossier dans lequel on place la séquence de fichiers archives contenant les événements SYNC utilisés en mode log shipping.

Le paramètre command_on_logarchive indique la commande qui doit être exécutée à chaque fois qu'un fichier SYNC est correctement généré.

Voir le chapitre slon_conf_command_on_log_archive pour plus de détails.

L'option quit_sync_provider indique quel processus fournisseur doit être surveilleé afin d'arrêter la réplication après un événement donné. Ceci doit être utilisé conjointement avec l'option -r ci-dessous...

Cela permet de stopper la réplication sur un processus slon après un certain point.

Le paramètre quit_sync_finalsync indique le numéro de l'événement après lequel un processus de réplication doit se terminer. Ceci doit être utilisé conjointement avec l'option -q ci-dessus...

L'option lag_interval spécifie une valeur temporelle (en anglais) telle que 3 minutes, 4 hours ou 2 days qui indique le temps de retard que doit avoir un nœud par rapport à son fournisseur. Cela implique que les événements seront ignorés tant que leur âge sera inférieur à cet intervalle.

Avertissement

Il y a un effet secondaire à ce retard ; Les événements qui demandent que tous les nœuds se synchronisent, notamment ceux qui sont produits lors d'une opération SLONIK FAILOVER(7) et d'un SLONIK MOVE SET(7), devront attendre pendant cet interval de temps.

C'est un comportement qui n'est pas idéal dans le cas d'une bascule après une panne, ou lorsque l'on veut exécuter des scripts DDL (SLONIK EXECUTE SCRIPT(7) ).