Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
1400 lines (1146 sloc) 42.6 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="adminscripts">
<title>Scripts d'administration</title>
<indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>
<para>
Un certain nombre de scripts ont été développés tout au long de l'histoire de
&slony1; pour aider les utilisateurs à gérer leurs clusters. Cette section
ainsi que celle sur le <xref linkend="monitoring"/> et la <xref
linkend="maintenance"/> décrit leur utilisation.
</para>
<sect2 id="altperl">
<title>Les scripts altperl</title>
<indexterm><primary>Script altperl pour &slony1;</primary></indexterm>
<para>
Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
instances &slony1;. Ces scripts supportent une nombre variable de n&oelig;uds.
Ils peuvent être installés pendant le processus d'installation&nbsp;:
</para>
<para>
<command>./configure --with-perltools</command>
</para>
<para>
Ceci va produire un certain nombre de scripts avec le préfixe
<command>slonik_</command>. Ils éliminent les risques de confusion en se
référençant à un fichier central de configuration qui contient les détails
de la configuration de votre site. Un exemple documenté de ce fichier est
fourni dans <filename>altperl/slon_tools.conf-sample</filename>. La plupart
dispose également d'une aide en ligne grâce à l'option "--help", ce qui les
rend plus facile à prendre en main et à utiliser.
</para>
<para>
La plupart des scripts de génération Slonik utilise la sortie STDOUT. Pendant
un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop
<quote>agressive</quote> car de légères coquilles dans la ligne de commande
peuvent conduire, dans certains cas, à des situations calamiteuses. Tout
administrateur qui se respecte doit relire le script
<emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.
</para>
<sect3>
<title>Gestion de multiples clusters</title>
<indexterm><primary>gérer de multiples clusters avec les outils altperl</primary></indexterm>
<para>
La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour
déterminer le fichier de configuration Perl qui sera utilisé pour contrôler
les n&oelig;uds du cluster &slony1;. Si elle n'est pas fournie, le fichier
<filename>slon_tools.conf</filename> situé dans l'emplacement par défaut
sera utilisé.
</para>
<para>
Voici la liste des variables qui peuvent être configurées&nbsp;:
<itemizedlist>
<listitem>
<para>
<envar>$CLUSTER_NAME</envar>=orglogs; # Quel est le nom du cluster de
réplication&nbsp;?
</para>
</listitem>
<listitem>
<para>
<envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire
des logs&nbsp;?
</para>
</listitem>
<listitem>
<para>
<envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs";
# Si ce paramètre est défini, il indique où trouver le gestionnaire de
gestion des traces d'Apache
</para>
</listitem>
<listitem>
<para>
<envar>foldCase</envar> # Si la valeur est 1, les noms d'objet (y
compris les noms de schéma) sont transformés en minuscule. Par
défaut, les noms d'objets restent inchangés. Notons que &postgres;
lui-même transforme les noms d'objets en minuscule. Si vous créez
une table avec la commande <command>CREATE TABLE MA_TABLE (Id INTEGER,
MoNChamp text);</command>, le résultat sera équivalent à
<command>create table ma_table (id integer, monchamp text);</command>,
le nom de la table et celui de ses champs seront transformés en
minuscule.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Vous pouvez ensuite définir un ensemble de n&oelig;uds qui participeront à
la réplication en utilisant plusieurs appels à la fonction
<function>add_node()</function>.
</para>
<para>
<command>add_node (host => '10.20.30.40', dbname => 'orglogs',
port => 5437, user => 'postgres', node => 4, parent => 1);</command>
</para>
<para>
Les paramètres de la fonction <function>add_node()</function> sont les
suivants&nbsp;:
</para>
<programlisting>my %PARAMS = (host=> undef, # nom de l'hôte
dbname => 'template1', # nom de la base
port => 5432, # numéro du port
user => 'postgres', # utilisateur de la connexion
node => undef, # numéro du n&oelig;ud
password => undef, # mot de passe de l'utilisateur
parent => 1, # l'identifiant du n&oelig;ud père
noforward => undef # ce n&oelig;ud doit-il retransmettre les modifications ?
sslmode => undef # mode SSL - détermine la priorité
# d'utilisation de la couche SSL
# = disable,allow,prefer,require
);</programlisting>
</sect3>
<sect3>
<title>Configuration d'un ensemble de réplication</title>
<indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication
pour les outils Perl</primary></indexterm>
<para>
La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour
déterminer le fichier de configuration à lire pour connaître les objets qui
sont contenus dans un ensemble donné.
</para>
<para>
Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour
<emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
celle-ci n'est nécessaire que lorsqu'on exécute <filename>create_set</filename>
car il s'agit du seul script qui contrôle le placement des tables dans les
différents ensembles de réplication.
</para>
</sect3>
<sect3>
<title>slonik_build_env</title>
<indexterm><primary>slonik_build_env</primary></indexterm>
<para>
Cette commande interroge la base de données et produit un résultat qui peut
être utilisé dans <filename>slon_tools.conf</filename>, notamment&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
une série d'appel à <function>add_node()</function> pour configurer le
cluster
</para>
</listitem>
<listitem>
<para>
les tableaux <envar>@KEYEDTABLES</envar>, <envar>@SERIALT</envar>
et <envar>@SEQUENCES</envar>
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>slonik_print_preamble</title>
<para>
Cette commande produit simplement le <quote>préambule</quote> qui est
nécessaire à chaque script slonik. En fait, elle fournit un
<quote>squelette</quote> de script slonik qui ne fait pas d'action
particulière.
</para>
</sect3>
<sect3>
<title>slonik_create_set</title>
<para>
Cette commande nécessite que les variables <envar>SLONYSET</envar> et
<envar>SLONYNODES</envar> soient configurées. Elle permet de produire
le script <command>slonik</command> qui configure un ensemble de
réplication en décrivant les tables et les séquences qui seront
répliquées.
</para>
</sect3>
<sect3 id="slonik-drop-node">
<title>slonik_drop_node</title>
<para>
Cette commande produit un script Slonik qui supprime un n&oelig;ud du
cluster &slony1;.
</para>
</sect3>
<sect3 id="slonik-drop-set">
<title>slonik_drop_set</title>
<para>
Cette commande produit un script Slonik qui supprime un ensemble de
réplication (<emphasis>c'est-à-dire</emphasis> un groupe de tables et de
séquences).
</para>
<para>
Ceci représente un risque potentiellement très dangereux car cela élimine
un ensemble de réplication complet en une commande. Une erreur de saisie qui
indiquerait un mauvais ensemble serait dévastateur. À comparer avec <xref
linkend="slonik-unsubscribe-set"/> et <xref linkend="slonik-drop-node"/>&nbsp;;
avec ces deux-là, tenter de supprimer un abonnement ou un n&oelig;ud vital à
vos opérations sera bloqué (via une constrainte de clé étrangère) s'il existe
un abonné qui pourrait être affecté. En contraste, il n'y aura pas de
messages d'avertissements ou d'erreurs si vous supprimez un ensemble&nbsp;;
l'ensemble disparaitra tout simplement de la réplication.
</para>
</sect3>
<sect3 id="slonik-drop-table">
<title>slonik_drop_table</title>
<para>
Cette commande produit un script Slonik qui supprime une table de la réplication.
Elle nécessite en entrée l'identifiant de la table (disponible dans la table
<envar>sl_table</envar>).
</para>
</sect3>
<sect3>
<title>slonik_execute_script</title>
<para>
Cette commande produit un script pour effectuer des changements DDL sur un
ensemble de réplication.
</para>
</sect3>
<sect3>
<title>slonik_failover</title>
<para>
Cette commande produit un script qui demande une bascule d'urgence entre un
n&oelig;ud mort et une nouvelle origine.
</para>
</sect3>
<sect3>
<title>slonik_init_cluster</title>
<para>
Cette commande produit un script Slonik qui intialise un cluster &slony1;
tout entier, y compris les n&oelig;uds, les voies de communications et les
voies d'écoute.
</para>
</sect3>
<sect3>
<title>slonik_merge_sets</title>
<para>
Cette commande produit un script Slonik qui fusionne deux ensembles de
réplication.
</para>
</sect3>
<sect3>
<title>slonik_move_set</title>
<para>
Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de
réplication vers un autre n&oelig;ud.
</para>
</sect3>
<sect3>
<title>réplication_test</title>
<para>
Ce script vérifie que &slony1; réplique correctement les données.
</para>
</sect3>
<sect3>
<title>slonik_restart_node</title>
<para>
Cette commande produit un script Slonik qui demande le redémarrage d'un
n&oelig;ud. Elle était particulièrement utile avant la version 1.0.5,
lorsque les n&oelig;uds étaient bloqués suite à la mort du démon slon.
</para>
</sect3>
<sect3>
<title>slonik_restart_nodes</title>
<para>
Cette commande produit un script Slonik qui redémarre tous les n&oelig;uds
du cluster. Elle n'est pas très utile.
</para>
</sect3>
<sect3>
<title>slony_show_configuration</title>
<para>
Cette commande affiche la configuration de l'environnement (c'est-à-dire
la variable <envar>SLONYNODES</envar>).
</para>
</sect3>
<sect3>
<title>slon_kill</title>
<para>
Cette commande tue le chien de garde slony et tous les démons slon pour un
ensemble de réplication donné. Elle ne fonctionne que si ces processus
fonctionnent sur l'hôte local, bien sûr&nbsp;!
</para>
</sect3>
<sect3>
<title>slon_start</title>
<para>
Cette commande démarre le démon slon pour un cluster et un n&oelig;ud donnés,
elle utilise le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.
</para>
</sect3>
<sect3 id="slonwatchdog">
<title>slon_watchdog</title>
<para>
Processus utilisé par <command>slon_start</command>.
</para>
</sect3>
<sect3>
<title>slon_watchdog2</title>
<para>
Ce script est un chien de garde plus malin&nbsp;; il surveille un n&oelig;ud
donné et relance le processus slon s'il constate qu'aucune modification ne
s'est produite depuis 20 minutes ou plus.
</para>
<para>
Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon
s'arrête sans crier gare.
</para>
</sect3>
<sect3>
<title>slonik_store_node</title>
<para>
Cette commande ajoute un n&oelig;ud dans un cluster.
</para>
</sect3>
<sect3>
<title>slonik_subscribe_set</title>
<para>
Ce script génère un script Slonik script pour abonner un n&oelig;ud donné à
un ensemble donné.
</para>
</sect3>
<sect3>
<title>slonik_uninstall_nodes</title>
<para>
Cette commande parcourt le cluster et supprime le schéma &slony1; sur tous
les n&oelig;uds. Vous pouvez utiliser cet outil si vous souhaitez détruire
la réplication sur l'ensemble du cluster. Comme ses effets sont
nécessairement destructeurs, ce script peut devenir très dangereux.
</para>
</sect3>
<sect3 id="slonik-unsubscribe-set">
<title>slonik_unsubscribe_set</title>
<para>
Cette commande produit un script Slonik qui désabonne un n&oelig;ud d'un
ensemble de réplication.
</para>
</sect3>
<sect3>
<title>slonik_update_nodes</title>
<para>
Cette commande produit un script Slonik qui incite tous les n&oelig;uds
à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue
un changement de version de &slony1;.
</para>
</sect3>
</sect2>
<sect2 id="mkslonconf"><title>mkslonconf.sh</title>
<indexterm><primary>générer le fichier slon.conf pour &slony1;</primary></indexterm>
<para>
Ce script shell est conçu pour parcourir un cluster &slony1; et produire un
ensemble de fichiers <filename>slon.conf</filename> qui pourront être
utilisés via l'option <command>slon -f slon.conf</command>.
</para>
<para>
Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
on peut alors facilement les invoquer, sans risquer d'oublier l'option
<command>-a</command>, ce qui peut provoquer le crash d'un n&oelig;ud en mode
<link linkend="logshipping">log shipping</link>.
</para>
<para>
Pour lancer le script, il faut configurer l'environnement de la manière
suivante&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Tout d'abord, l'environnement doit être configuré avec les paramètres
adéquats pour que libpq puisse se connecter à une des bases de données
du cluster. Vous devez donc définir une combinaison parmi les variables
d'environnement suivantes&nbsp;:
</para>
<itemizedlist>
<listitem><para><envar>PGPORT</envar></para></listitem>
<listitem><para><envar>PGDATABASE</envar></para></listitem>
<listitem><para><envar>PGHOST</envar></para></listitem>
<listitem><para><envar>PGUSER</envar></para></listitem>
<listitem><para><envar>PGSERVICE</envar></para></listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
<envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui doit être
<quote>parcouru</quote>.
</para>
</listitem>
<listitem>
<para>
<envar>MKDESTINATION</envar> - un répertoire qui accueillera la
configuration&nbsp;; le script crée un dossier
<filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers
de configuration des démons &lslon; et un dossier
<filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y
stocke les fichiers PID.
</para>
</listitem>
<listitem>
<para>
<envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers de
log&nbsp;; un dossier nommé
<command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour
chaque n&oelig;ud.
</para>
</listitem>
</itemizedlist>
<para>
Pour chaque <quote>nouveau</quote> n&oelig;ud qu'il découvre, ce script va
créer un nouveau fichier de configuration &lslon;.
</para>
<warning>
<para>
Il est important de préciser que ce script présente quelques particularités
qu'il faut connaître, mais aucune n'est vraiment surprenante.
</para>
<itemizedlist>
<listitem>
<para>
Le DSN est positionné à la plus petite valeur trouvé pour chaque
n&oelig;ud dans le table <envar>sl_path</envar>. Vous devrez
probablement modifier cette valeur.
</para>
</listitem>
<listitem>
<para>
Plusieurs paramètres sont initialisés avec leur valeur par défaut&nbsp;;
Vous devrez probablement les réajuster à la main.
</para>
</listitem>
<listitem>
<para>
Si vous exécutez les processus &lslon; sur de multiples n&oelig;uds
(<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers
un réseau WAN), ce script va joyeusement créer des fichiers de
configuration pour des &lslon;s que vous comptez lancer sur un hôte
différent.
</para>
<para>
Vérifiez bien les n&oelig;uds configurés avant de redémarrer les &lslon;s.
</para>
<para>
En général, cela provoque des inconvénients mineurs comme, par exemple,
un &lslon; fonctionnant de manière inapproprié, échouant suite à un
problème de connectivité (ce qui ne provoque pas de dégâts&nbsp;!), ou
fonctionnant moins efficacement vu qu'il se trouve du mauvais coté du
<quote>tuyau</quote>.
</para>
<para>
D'un autre côté, si vous faites fonctionner un n&oelig;ud en mode log
shipping sur le site distant, l'arrivée d'un &lslon; qui <emphasis>ne
collecte pas</emphasis> les logs peut ruiner une semaine complète
d'activité.
</para>
</listitem>
</itemizedlist>
</warning>
<para>
Les fichiers produits par <filename>mkslonconf.sh</filename> sont
spécifiquement conçus pour gérer des &lslon;s sur de multiples clusters avec
le script décrit dans la section suivante...
</para>
</sect2>
<sect2 id="startslon">
<title>start_slon.sh</title>
<para>
Ce script du style <filename>rc.d</filename> est disponible à partir de la
version 2.0 de &slony1;&nbsp;; il fournit un moyen automatique de&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Démarrer &lslon;, via la commande <command>start_slon.sh start</command>
</para>
</listitem>
</itemizedlist>
<para>
Il essaie de démarrer &lslon;, en vérifiant au préalable qu'il n'est pas
déjà en cours d'exécution, que la configuration existe et qu'il dispose des
droits pour écrire sur le journal applicatif associé. Voici les échecs
possibles&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Il n'y a pas de <link linkend="runtime-config">fichier de configuration
slon</link>.
</para>
</listitem>
<listitem>
<para>
Un processus &lslon; est trouvé avec le PID indiqué via la configuration.
</para>
</listitem>
<listitem>
<para>
L'emplacement spécifié via <envar>SLON_LOG</envar> n'est pas disponible en
écriture.
</para>
</listitem>
<listitem>
<para>
Arrêt du &lslon;, via <command>start_slon.sh stop</command>
</para>
<para>
Ceci échoue (ne fait rien) si le PID (indiqué via le fichier de
configuration) n'existe pas.
</para>
</listitem>
<listitem>
<para>
Surveiller le statut de &lslon;, via <command>start_slon.sh status</command>
</para>
<para>
Ceci indique si le processus &lslon; est en cours d'exécution et, dans ce
cas, affiche l'identifiant du processus.
</para>
</listitem>
</itemizedlist>
<para>
Les variables d'environnement suivantes sont utilisées pour contrôler la
configuration de &lslon;&nbsp;:
</para>
<glosslist>
<glossentry>
<glossterm>
<envar>SLON_BIN_PATH</envar>
</glossterm>
<glossdef>
<para>
Ceci indique où trouver le programme &lslon;.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>
<envar>SLON_CONF</envar>
</glossterm>
<glossdef>
<para>
Ceci indique l'emplacement du <link linkend="runtime-config">fichier
de configuration slon</link> contrôlant le comportement de &lslon;.
</para>
<para>
Notez que ce fichier <emphasis>doit</emphasis> contenir la valeur de
l'option <link linkend="slon-config-logging-pid-file">log_pid_file</link>&nbsp;;
c'est nécessaire pour permettre à ce script de détecter si &lslon; est
en cours d'exécution.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>
<envar>SLON_LOG</envar>
</glossterm>
<glossdef>
<para>
Cette option indique l'emplacement où les journaux applicatifs de &lslon;
sont stockés. Il existe une option <xref
linkend ="slon-config-logging-syslog"/> pour que &lslon; utilise
<application>syslog</application> pour gérer ses journaux
applicatifs&nbsp;; dans ce cas, vous pouvez configurer
<envar>SLON_LOG</envar> à <filename>/dev/null</filename>.
</para>
</glossdef>
</glossentry>
</glosslist>
<para>
Notez que ces variables d'environnement peuvent être configurées soit dans le
script soit dans les valeurs passées dans l'environnement. Ce dernier rend
l'utilisation de ce script plus simple lorsqu'il combine <xref linkend="testbed"/>
pour être régulièrement testé.
</para>
</sect2>
<sect2 id="launchclusters">
<title>launch_clusters.sh</title>
<indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf</primary></indexterm>
<para>
Voici un autre script shell qui utilise la configuration produite par
<filename>mkslonconf.sh</filename> et qui a pour but de supporter une
approche sur l'exécution de &slony1; consistant à vérifier régulièrement
(<emphasis>c'est-à-dire</emphasis> avec un cron) que les processus &lslon;
sont en cours d'exécution.
</para>
<para>
Il utilise les variables d'environnement suivantes&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
<envar>PATH</envar> qui doit contenir, de préférence au début, le chemin
vers les binaires &lslon; qui doivent être exécutés.
</para>
</listitem>
<listitem>
<para>
<envar>SLHOME</envar> indique le répertoire <quote>home</quote> qui
contient les fichiers de configuration de &lslon;&nbsp;; ces fichiers
doivent être rangés en sous-répertoires, un pour chaque cluster, avec
un nom de fichier du type <filename>node1.conf</filename>,
<filename>node2.conf</filename> et ainsi de suite.
</para>
<para>
Le script utilise la commande <command>find $SLHOME/$cluster/conf
-name "node[0-9]*.conf"</command> pour trouver les fichiers de
configuration &lslon;.
</para>
<para>
Si vous déplacez ces fichiers ou si vous les renommez, ils ne seront pas
trouvés&nbsp;; c'est une façon très simple de supprimer des n&oelig;uds.
</para>
</listitem>
<listitem>
<para>
<envar>LOGHOME </envar> indique le répertoire <quote>home</quote> pour le
stockage des journaux applicatifs.
</para>
<para>
Ce script ne nécessite pas l'utilisation du gestionnaire de journaux
applicatifs d'Apache, sachant que &postgres; version 8 gère lui-même la
rotation des journaux applicatifs, il semble inopportun de garder une
dépendance à une <quote>technologie</quote> de rotation spécifique.
</para>
</listitem>
<listitem>
<para>
<envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont
gérés.
</para>
</listitem>
</itemizedlist>
<para>
En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il
relancera tous les processus &lslon; manquants.
</para>
</sect2>
<sect2 id="extractschema">
<title><filename>slony1_extract_schema.sh</filename></title>
<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
<para>
Si vous souhaitez créer un nouveau n&oelig;ud, après la création du cluster,
le script <filename>slony1_extract_schema.sh</filename> vous aidera dans
cette tache.
</para>
<para>
La commande d'exécution peut ressembler à la ligne suivante&nbsp;:
</para>
<para>
<command>PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll</command>
</para>
<para>
Elle réalise les actions suivantes&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Elle fait un dump du schéma du n&oelig;ud origine, y compris les
informations du schéma du cluster &slony1;.
</para>
<para>
Notons que les variables d'environnement <envar>PGPORT</envar> et
<envar>PGHOST</envar> fournissent des informations additionnelles sur
l'emplacement de la base de données.
</para>
</listitem>
<listitem>
<para>
Ces informations sont chargées dans une table temporaire fraîchement
créée&nbsp;: <envar>temppayroll</envar>.
</para>
</listitem>
<listitem>
<para>
Les OID de table et de séquence dans les tables &slony1; sont corrigées
pour pointer vers la configuration de la base temporaire.
</para>
</listitem>
<listitem>
<para>
Un script slonik est lancé pour effectuer l'action <xref
linkend="stmtuninstallnode"/> sur la base temporaire. Ceci élimine toutes
les tables et le schéma spécifique à &slony1;, et supprime les triggers
&slony1; des tables répliquées.
</para>
</listitem>
<listitem>
<para>
Enfin, la commande <application>pg_dump</application> est lancée sur la
base temporaire, et produit une copie nettoyée du schéma sur la sortie
standard.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>slony-cluster-analysis</title>
<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
<para>
Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters
&slony1;, il peut devenir pénible de suivre et de documenter votre
architecture. L'outil suivant peut vous y aider.
</para>
<para>
<application>slony-cluster-analysis.sh</application> est un script shell
conçu pour fournir une analyse à long terme de la configuration d'un cluster
&slony1;. Vous passez les variables d'environnement
<application>libpq</application> habituelles (<envar>PGHOST</envar>,
<envar>PGPORT</envar>, <envar>PGDATABASE</envar> et ainsi de suite) pour se
connecter à un membre du cluster &slony1;, et passer le nom du cluster comme
argument.
</para>
<para>
Le script effectue alors les actions suivantes&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir
la liste des n&oelig;uds, des voies de communication, des ensembles de
réplication et des tables.
</para>
</listitem>
<listitem>
<para>
Ces données sont stockées dans un fichier temporaire situé dans
<filename>/tmp</filename>.
</para>
</listitem>
<listitem>
<para>
Une comparaison est effectuée entre la configuration présente et la
configuration trouvée lors de la dernière exécution du script. Si la
configuration a changé, un courriel contenant les différences (produit
avec <application>diff</application>) est envoyée à l'adresse spécifiée.
</para>
</listitem>
<listitem>
<para>
Si la configuration a changé, l'ancien fichier de configuration est
renommé pour indiquer quand le script a remarqué le changement.
</para>
</listitem>
<listitem>
<para>
Finalement, la configuration courante est stockée dans le dossier
<envar>LOGDIR</envar> dans un fichier nommé
<filename>cluster.last</filename>.
</para>
</listitem>
</itemizedlist>
<para>
Il existe un exemple de script <quote>d'encapsulation</quote>,
<filename>slony-cluster-analysis-mass.sh</filename>, qui permet de pointer
vers un ensemble de clusters &slony1;.
</para>
<para>
Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux
plans&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>la documentation de l'état courant du système&nbsp;</para>
</listitem>
<listitem>
<para>la surveillance des changements de configuration.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="configurereplication">
<title>Génération de scripts slonik avec <filename>configure-replication.sh</filename></title>
<indexterm><primary>générer des scripts slonik pour un cluster</primary></indexterm>
<para>
Le script <filename>configure-replication.sh</filename>, situé dans le
répertoire <filename>outil</filename>, est conçu pour automatiser la
génération de scripts slonik de configuration de la réplication. La
configuration de ce script reprend la même approche que le <xref
linkend="testbed"/>.
</para>
<para>
Ce script utilise beaucoup (peut-être énormément, si votre configuration est
particulièrement complexe) de variables d'environnement pour déterminer la
forme de la configuration du cluster. Il utilise massivement les valeurs par
défaut et, dans la plupart des cas, peu de valeurs doivent être positionnées
afin d'obtenir une configuration viable.
</para>
<sect3>
<title>Valeurs globales</title>
<para>
Certaines valeurs sont utilisées universellement partout sur le cluster&nbsp;:
</para>
<variablelist>
<varlistentry>
<term><envar>CLUSTER</envar></term>
<listitem><para>Nom du cluster Slony-I</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>NUMNODES</envar></term>
<listitem><para>Nombre de n&oelig;uds à configurer</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>PGUSER</envar></term>
<listitem><para>Nom du super-utilisateur qui contrôle la réplication</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>PGPORT</envar></term>
<listitem><para>Numéro du port par défaut</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>PGDATABASE</envar></term>
<listitem><para>Nom de la base de données par défaut</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>TABLES</envar></term>
<listitem>
<para>
Liste de noms complets de tables (<emphasis>par exemple</emphasis> - un
nom incluant le schéma tel que <command>public.ma_table</command>)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><envar>SEQUENCES</envar></term>
<listitem>
<para>
Liste de noms complets de séquences (<emphasis>par exemple</emphasis>
- un nom incluant le schéma tel que <command>public.ma_sequence</command>)
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Des valeurs par défauts sont fournies pour <emphasis>chacune</emphasis> de
ces valeurs, si bien que si vous lancez <filename>configure-replication.sh</filename>
sans configurer aucune variable d'environnement, vous obtiendrez un ensemble
de scripts slonik. Bien sûr, ils ne correspondront pas aux bases que vous
voudrez configurer...
</para>
</sect3>
<sect3>
<title>Valeur spécifique à un n&oelig;ud</title>
<para>
Pour chaque n&oelig;, il y a également quatre variables d'environnement&nbsp;;
pour le n&oelig;ud 1&nbsp;:
</para>
<variablelist>
<varlistentry>
<term><envar>DB1</envar></term>
<listitem><para>La base de données à laquelle les scripts doivent se connecter</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>USER1</envar></term>
<listitem><para>Le super-utilisateur utilisé pour la connexion</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>PORT1</envar></term>
<listitem><para> Le port</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>HOST1</envar></term>
<listitem><para>L'hôte</para></listitem>
</varlistentry>
</variablelist>
<para>
Il est très probable que <envar>DB*</envar>, <envar>USER*</envar> et
<envar>PORT*</envar> correspondent aux variables globales
<envar>PGDATABASE</envar>, <envar>PGUSER</envar> et
<envar>PGPORT</envar> décrites précédemment&nbsp;; conserver cette
correspondance est souvent une bonne chose.
</para>
<para>
En revanche, les valeurs <envar>HOST*</envar> doivent être définies
explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...
car il n'est pas très malin de mettre en place un système de réplication
si toutes les bases redondantes se trouvent sur le même serveur&nbsp;!
</para>
</sect3>
<sect3>
<title>Les scripts slonik générés</title>
<para>
Les scripts de configuration slonik sont générés dans un répertoire temporaire
à l'intérieur de <filename>/tmp</filename>. Leur usage est le suivant&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
<filename>preamble.slonik</filename> est un fichier <quote>préambule</quote>
contenant les informations de connexion utilisées par les autres scripts.
</para>
<para>
Vérifier attentivement celui-ci&nbsp;; vous pourrez le réutiliser pour
les futures opérations de maintenance que vous effectuerez sur le cluster.
</para>
</listitem>
<listitem>
<para>
<filename>create_nodes.slonik</filename>
</para>
<para>
Ce script est le premier qu'il faut lancer&nbsp;; il configure les
n&oelig;uds spécifiés en n&oelig;ud &slony1;, en y ajoutant les tables
et les autres objets spécifiques de &slony1;.
</para>
<para>
Vous pouvez/devez lancer les processus slon juste après cette étape.
</para>
</listitem>
<listitem>
<para>
<filename>store_paths.slonik</filename>
</para>
<para>
Le second script à exécuter&nbsp;; il indique comment les &lslon;
doivent communiquer entre eux. Ce script suppose que tous les &lslon;
peuvent parler à tous les n&oelig;uds, ce qui n'est peut-être pas exact
dans un environnement peuplé de pare-feu complexes. Si cette supposition
n'est pas correcte, vous devez modifier ce script pour corriger les voies
de communications.
</para>
</listitem>
<listitem>
<para>
<filename>create_set.slonik</filename>
</para>
<para>
Ce script configure l'ensemble de réplication composé de toutes les
tables et les séquences présentes dans le schéma de la base de données
de votre application.
</para>
<para>
Lorsque vous lancez ce script, la seule action menée est l'ajout de
triggers sur le n&oelig;ud origine (n&oelig;ud #1) qui vont commencer
à collecter les mises à jours. La réplication ne commencera qu'à l'étape
#5...
</para>
<para>
Il y a deux suppositions dans ce scripts qui peuvent ne pas être valides
dans certaines circonstances&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
que toutes les tables et les séquences soit répliquées
</para>
<para>
Ceci n'est pas valide lorsque de nouvelles tables sont ajoutée dans
votre schéma et qu'elles ne sont pas ajoutées dans la liste
<envar>TABLES</envar>.
</para>
</listitem>
<listitem>
<para>
que toutes les tables sont définies avec des clefs primaires
</para>
<para>
La bonne pratique est de toujours créer et utiliser de vraies clefs
primaires. Si vous avez des tables qui nécessitent de choisir une
clef primaire candidate ou qui nécessite la création d'une clef
additionnelle avec la commande <xref linkend="stmttableaddkey"/>,
vous devez modifier ce script à la main pour l'accommoder.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
<filename>subscribe_set_2.slonik</filename>
</para>
<para>
et 3, 4, 5, si vous configurez d'autres n&oelig;uds...
</para>
<para>
Ceci est l'étape qui <quote>déclenche</quote> la réplication.
</para>
<para>
Ce script fait la supposition que tous les n&oelig;uds abonnés voudront
s'abonner directement au n&oelig;ud origine. Si vous souhaitez mettre en
place des <quote>sous-clusters</quote> avec peut-être un n&oelig;ud
maître dans chaque centre de données, vous devez modifier ces scripts.
</para>
<para>
Les processus slon doivent fonctionner au moment où vous réalisez cette
étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 id="bsd-ports-profile">
<title><filename>slon.in-profiles</filename></title>
<subtitle>profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename></subtitle>
<indexterm>
<primary>profiles dans le style d'Apache pour FreeBSD</primary>
<secondary>FreeBSD</secondary>
</indexterm>
<para>
Dans le répertoire <filename>tools</filename>, le script
<filename>slon.in-profiles</filename> permet de lancer des instances &lslon;
lors du démarrage du système. Il est conçu pour interagir avec le système des
ports de FreeBSD.
</para>
</sect2>
<sect2 id="duplicate-node">
<title><filename>duplicate-node.sh</filename></title>
<indexterm><primary>dupliquer un n&oelig;ud</primary></indexterm>
<para>
Dans le répertoire <filename>tools</filename>, le script
<filename>duplicate-node.sh</filename> aide à créer un nouveau n&oelig;ud
en dupliquant un des n&oelig;uds du cluster.
</para>
<para>
Ce script attend les paramètres suivants&nbsp;:
</para>
<itemizedlist>
<listitem><para>le nom du cluster&nbsp;;</para></listitem>
<listitem><para>le numéro du nouveau n&oelig;ud&nbsp;;</para></listitem>
<listitem><para>le n&oelig;ud origine&nbsp;;</para></listitem>
<listitem><para>le n&oelig;ud répliqué&nbsp;;</para></listitem>
<listitem><para>le nouveau n&oelig;ud&nbsp;;</para></listitem>
</itemizedlist>
<para>
Pour chaque n&oelig;ud spécifié, le script permet de préciser les paramètres
de type <function>libpq</function> pour <envar>PGHOST</envar>,
<envar>PGPORT</envar>, <envar>PGDATABASE</envar> et <envar>PGUSER</envar>. Le
fichier <filename>.pgpass</filename> peut être utilisé pour le stockage des
mots de passe, ce qui est généralement considéré comme une bonne pratique.
Lorsqu'elles ne sont pas définies, ces valeurs peuvent hériter des variables
d'environnement <function>libpq</function>, ce qui est pratique quand on
réalise des tests. Toutefois, lorsque que ce script est utilisé <quote>de
manière brutale</quote>, il est souvent nécessaire de définir les 14
paramètres disponibles.
</para>
<para>
Ce script prépare des fichiers, placés dans <filename>/tmp</filename>, et
annonce le nom du répertoire qu'il a créé pour les scripts SQL et &lslonik;
de configuration du nouveau n&oelig;ud.
</para>
<itemizedlist>
<listitem>
<para><filename>schema.sql</filename></para>
<para>
Ce script est tiré du n&oelig;ud origine et contient le schéma de données
<quote>originel</quote> qui doit être appliqué au départ.
</para>
</listitem>
<listitem>
<para><filename>slonik.preamble</filename></para>
<para>
Ce fichier <quote>preambule</quote> est utilisé par l'ensemble des scripts
slonik ci-dessous.
</para>
</listitem>
<listitem>
<para><filename>step1-storenode.slonik</filename></para>
<para>
Un script &lslonik; qui configure le nouveau n&oelig;ud.
</para>
</listitem>
<listitem>
<para><filename>step2-storepath.slonik</filename></para>
<para>
Un script &lslonik; qui met en place des voies de communication entre
le n&oelig;ud fournisseur et le nouveau n&oelig;ud.
</para>
</listitem>
<listitem>
<para><filename>step3-subscribe-sets.slonik</filename></para>
<para>
Un script &lslonik; qui demande la souscription à tous les ensembles de
réplication.
</para>
</listitem>
</itemizedlist>
<para>
Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner un
nouveau n&oelig;ud. La configuration ne doit pas forcément correspondre à une
configuration finale, notamment&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Il est souhaitable de construire des voies de communication
supplémentaires afin d'assurer leur redondance.
</para>
</listitem>
<listitem>
<para>
Les scripts générés supposent que le nouveau n&oelig;ud doit être un
n&oelig;ud transmetteur («&nbsp;forwarding&nbsp;»), ce qui n'est pas
forcément vrai.
</para>
</listitem>
<listitem>
<para>
Il est parfois souhaitable, une fois que le processus d'abonnement est
réalisé complètement, de modifier les abonnements.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="slonikconfdump"> <title>slonikconfdump.sh</title>
<indexterm><primary>Export de la configuration slonik</primary></indexterm>
<para> L'outil <filename>tools/slonikconfdump.sh</filename> a été créé
pour qu'il soit plus facile d'exporter un script &lslonik; afin de dupliquer
la configuration d'un cluster &slony1; fonctionnel.</para>
<para> L'outil exporte : </para>
<itemizedlist>
<listitem><para>Le nom du cluster</para> </listitem>
<listitem><para>Les informations sur de connexion au noeud</para>
<para> Notez qu'il utilise la première valeur qu'il trouve (<emphasis>par exemple</emphasis> -
le plus petit numéro de noeud client). </para> </listitem>
<listitem><para>Les noeuds </para> </listitem>
<listitem><para>Les ensembles de réplication ("sets") </para> </listitem>
<listitem><para>Les tables </para> </listitem>
<listitem><para>Les séquences </para> </listitem>
<listitem><para>Les abonnements </para>
<para> Notez que les abonnements sont ordonnées par ensemble de réplication, puis
par fournisseur, pour par recepteur. Ce classement n'indique pas forcément l'ordre
dans lequel les abonnements doivent être effectués. </para></listitem>
</itemizedlist>
<para> Le script fonctionne de la façon suivante : </para>
<programlisting>
chris@dba2:Slony-I/CMD/slony1-2.0/tools> SLONYCLUSTER=slony_regress1 PGDATABASE=slonyregress1 bash slonikconfdump.sh
# building slonik config files for cluster slony_regress1
# generated by: slonikconfdump.sh
# Generated on: Tue Jun 9 17:34:12 EDT 2009
cluster name=slony_regress1;
include <admin-conninfos.slonik>; # Draw in ADMIN CONNINFO lines
node 1 admin conninfo='dbname=slonyregress1 host=localhost user=chris port=7083';
node 2 admin conninfo='dbname=slonyregress2 host=localhost user=chris port=7083';
init cluster (id=1, comment='Regress test node');
store node (id=2, comment='node 2');
store path (server=1, client=2, conninfo='dbname=slonyregress1 host=localhost user=chris port=7083', connretry=10);
store path (server=2, client=1, conninfo='dbname=slonyregress2 host=localhost user=chris port=7083', connretry=10);
create set (id=1, origin=1, comment='All test1 tables');
set add table (id=1, set id=1, origin=1, fully qualified name='"public"."table1"', comment='accounts table, key='table1_pkey');
set add table (id=2, set id=1, origin=1, fully qualified name='"public"."table2"', comment='public.table2, key='table2_id_key');
set add table (id=4, set id=1, origin=1, fully qualified name='"public"."table4"', comment='a table of many types, key='table4_pkey');
set add table (id=5, set id=1, origin=1, fully qualified name='"public"."table5"', comment='a table with composite PK strewn across the table, key='table5_pkey');
subscribe set (id=1, provider=1, receiver=2, forward=YES);
chris@dba2:Slony-I/CMD/slony1-2.0/tools>
</programlisting>
<para> Le résultat doit être vérifié avant qu'il soit appliqué ailleurs.
Une attention particulière doit être portée à la commande <command>ADMIN
CONNINFO</command>, car elle contient la première valeur que le script a trouvé
pour chacun des noeuds. Dans un environement complexe, où la visibilité des noeuds
peut varier d'un sous-ensemble à un autre, il est possible que les bonnes valeurs ne
soient pas prises en compte. De plus, la commande
<command>SUBSCRIBE SET</command> n'indique pas forcément l'ordre dans lequel les
abonnements doivent être appliqués.
</para>
</sect2>
</sect1>