Find file
Fetching contributors…
Cannot retrieve contributors at this time
2402 lines (1978 sloc) 68.3 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="loganalysis">
<title>Analyses des traces</title>
<indexterm><primary>analyse des traces</primary></indexterm>
<para>
Voici un tour d'horizon des informations que vous trouverez dans les traces
de &slony1;, ainsi que des explications sur leur signification.
</para>
<sect2>
<title>Notification CONFIG</title>
<para>
Ces lignes sont assez triviales. Ce sont des messages d'information à propos
de la configuration.
</para>
<para>
Voici quelques lignes typiques que vous pouvez rencontrer :
<screen>CONFIG main: local node id = 1
CONFIG main: loading current cluster configuration
CONFIG storeNode: no_id=3 no_comment='Node 3'
CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
CONFIG main: configuration complete - starting threads</screen>
</para>
</sect2>
<sect2>
<title>Notifications INFO</title>
<para>
Les événements, qui semblent avoir un intérêt au niveau INFO et qui sont
toujours listés, tout comme les notifications CONFIG.
</para>
</sect2>
<sect2>
<title>Notifications DEBUG</title>
<para>
Les messages de débogage sont de peu d'intérêt. Vous en aurez seulement besoin
si vous avez des problèmes avec &slony1;.
</para>
</sect2>
<sect2>
<title>Nom du thread</title>
<para>
Les notifications DEBUG sont moins intéressantes et ne vous seront utiles
que lorsque vous rencontrez une problème avec &slony1;.
</para>
</sect2>
<sect2>
<title>Nom du processus </title>
<para>
Les notifications sont toujours précédées par le nom du processus qui produit
cette notification. Vous verrez des messages en provenance des processus
suivants&nbsp;:
<variablelist>
<varlistentry>
<term>localListenThread</term>
<listitem>
<para>
Le processus local qui écoute les événements sur le n&oelig;ud local.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>remoteWorkerThread-X</term>
<listitem>
<para>
Les processus qui traitent les événements distants. Vous verrez un de
ces processus pour chaque n&oelig;ud qui est en communication avec le
n&oelig;ud local.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>remoteListenThread-X</term>
<listitem>
<para>
Les processus qui écoutent les événements distants. Vous verrez un
de ces processus pour chaque n&oelig;ud du cluster.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cleanupThread</term>
<listitem>
<para>
Le processus qui prend en charge les opérations telles que les
VACUUM, le nettoyage des tables confirm et event et la suppression
des données périmées.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>syncThread</term>
<listitem>
<para>
Le processus qui produit les événements SYNC.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
La quantité d'information que ces processus affichent est contrôlée par le
paramètre <envar>log_level</envar> de &lslon;. Les messages de type
ERROR/WARN/CONFIG/INFO seront toujours affichés. Augmenter la valeur de 1 à
4 affichera des plus en plus de messages de niveau DEBUG.
</para>
</sect2>
<sect2>
<title>Comment lire les traces de &slony1;</title>
<indexterm><primary>lire et comprendre les traces de &slony1;</primary></indexterm>
<para>
Notons que, du point de vue d'un processus slon, il n'y a pas de
<quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des
n&oelig;uds.
</para>
<para>
On s'attend, de prime abord, à voir sur chaque n&oelig;uds des événements se
propager dans les deux sens. Dans un premier temps, il doit y avoir des
événements publiés qui témoignent de la création des n&oelig;uds et des
voies de communications. Si vous ne les voyez pas, alors les n&oelig;uds
ne communiquent pas correctement entre eux et rien ne va se passer...
</para>
<itemizedlist>
<listitem>
<para>Créer les deux n&oelig;uds.</para>
<para>
Aucun slon ne fonctionne à ce stade, donc il n'y a aucune trace à
consulter.
</para>
</listitem>
<listitem>
<para>Lancer les deux n&oelig;uds</para>
<para>
Les traces de chaque n&oelig;ud n'auront pas une activité débordante
car aucun des n&oelig;uds n'a pas grand chose à dire et qu'ils ne savent
pas comment communiquer entre eux. Chaque n&oelig;ud génère périodiquement
un événement <command>SYNC</command>, mais ne perçoit
<emphasis>rien</emphasis> de ce qui se passe sur les autres n&oelig;uds.
</para>
</listitem>
<listitem>
<para>
Lancer <xref linkend="stmtstorepath"/> pour configurer les voies de
communications. Ceci devrait permettre aux n&oelig;uds de prendre
conscience de l'existence de leurs voisins.
</para>
<para>
Les traces de slon doivent maintenant indiquer la réception des événements
en provenance des n&oelig;uds <quote>étrangers</quote>.
</para>
<para>
Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
automatiquement, donc les traces vont rester calmes tant que vous n'aurez
pas soumis explicitement les requêtes <command>STORE LISTEN</command>.
Dans la version 1.1, les <quote>voies d'écoute</quote> sont configurées
automatiquement, ce qui nous donne un réseau de communication
opérationnel plus rapidement.
</para>
<para>
Si vous consultez le contenu des tables <xref linkend="table.sl-node"/>,
<xref linkend="table.sl-path"/> et <xref linkend="table.sl-listen"/> sur
chaque n&oelig;ud, cela vous donnera une bonne idée de l'état du réseau
de communication. Jusqu'à ce que les <xref linkend="slon"/> démarrent,
chaque n&oelig;ud est partiellement configuré. Si le cluster contient
deux n&oelig;uds, alors il doit y avoir deux entrées dans chacune des
trois tables une fois que les communications sont correctement
configurées. S'il y a moins d'entrées, vous devriez pouvoir deviner ce
qui manque.
</para>
</listitem>
<listitem>
<para>
Si nécessaire (<emphasis>c'est-à-dire</emphasis> - si votre version est
antérieure à la version 1.1), lancez des requêtes <xref
linkend="stmtstorelisten"/> pour indiquer comment les n&oelig;uds
utiliseront les voies de communications.
</para>
<para>
Une fois que c'est fait, les traces des n&oelig;uds afficheront un niveau
d'activité supérieur, notamment les événements produits périodiquement
sur les différents n&oelig;uds, ainsi que leur propagation.
</para>
</listitem>
<listitem>
<para>
Configurez l'ensemble de réplication avec (<xref
linkend="stmtcreateset"/>), ajoutez les tables avec (<xref
linkend="stmtsetaddtable"/>), les séquences avec (<xref
linkend="stmtsetaddsequence"/>), puis vérifiez que vous retrouvez des
traces adéquates avec <xref linkend="logaddobjects"/> uniquement dans
les traces du n&oelig;ud d'origine de l'ensemble de réplication.
</para>
</listitem>
<listitem>
<para>
Soumettre une requête <xref linkend="stmtsubscribeset"/>, l'événement
devrait être visible sur les deux n&oelig;uds.
</para>
<para>
Il reste quelques actions à mener sur le n&oelig;ud origine... L'abonné
doit ensuite recevoir un événement <command>COPY_SET</command>, ce qui
doit afficher des informations dans les traces à propos de l'ajout de
chaque table et de la copie de leurs données. Consultez la section
<xref linkend="logsubtime"/> pour plus de détails.
</para>
</listitem>
</itemizedlist>
<para>
À partir de là, vous constaterez deux types de comportements&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Sur le n&oelig;ud origine, peu d'informations seront enregistrés dans
les traces, juste des indications sur les événements <command>SYNC</command>
générés et confirmés par les autres n&oelig;uds. Consultez la section
<xref linkend="lognormalsync"/> pour plus d'informations sur les
différents types de traces que vous pouvez rencontrer.
</para>
</listitem>
<listitem>
<para>
Sur le n&oelig;ud abonné, vous trouverez des rapports sur les événements
<command>SYNC</command> et sur les données que l'abonné obtient du
fournisseur. Ceci se produit peu fréquemment si le n&oelig;ud origine ne
reçoit pas de mises à jour&nbsp;; c'est au contraire très fréquent si le
n&oelig;ud origine reçoit beaucoup de modifications.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Les traces et leurs implications</title>
<para>
Cette section énumère les nombreux messages d'erreurs que l'on peut trouver
dans les traces de &slony1;, ainsi qu'une brève explication de leur
implication. Il s'agit d'une liste relativement compréhensible, qui omet
simplement certains messages de niveau <command>DEBUG4</command> qui sont
presque toujours inintéressants.
</para>
<sect3 id="logshiplog">
<title>Traces associées au Log Shipping</title>
<para>
La plupart de ces messages concernent des erreurs qui se produisent lorsque
le mécanisme de <xref linkend="logshipping"/> échoue. En général, cela se
produit si le système de fichiers utilisé pour le log shipping est plein ou
si les droits d'un répertoire sont mal définies.
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command>
</para>
<para>
Ce message indique qu'une erreur a été rencontrée en essayent d'écrire
un fichier de log shipping. Normalement, le démon &lslon; essaie à
nouveau jusqu'à ce qu'il réussisse.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command>
</para>
<para>
Ce message indique qu'un fichier d'archive est écrit pour un ensemble de
<command>SYNC</command> particulier.
</para>
</listitem>
<listitem>
<para>
<command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command>
</para>
<para>
Si &lslon; est configuré (avec l'option <option>-x</option>, c'est-à-dire
<envar>command_on_logarchive</envar>) pour lancer une commande après
chaque génération de fichier d'archive, ce message indique quand cette
commande est effectuée via la fonction <function>system()</function>.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not open COPY SET archive file %s - %s</command>
</para>
<para>
Ce message semble assez explicite...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command>
</para>
<para>
Ce message signifie probablement que vous avez saturé le système de fichier...
</para>
</listitem>
<listitem>
<para>
<command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command>
</para>
<para>
Ce message se produit occasionnellement lorsqu'on utilise le log
shipping&nbsp;; il se produit généralement lorsque que le cluster
contient trois n&oelig;uds ou plus, et que le démon tente d'exécuter
simultanément des événements en provenance de différents n&oelig;uds.
Ceci ne représente pas un problème sérieux&nbsp;; &slony1; tentera à
nouveau de traiter l'événement qui a échoué, sans que l'intervention
d'un administrateur ne soit nécessaire.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="ddllogs">
<title>Traces à propose des scripts DDL</title>
<para>
La gestion des ordres DDL est un peu fragile, comme indiqué dans la section
<xref linkend="ddlchanges"/>&nbsp;; voici des messages à caractère informatif
et des messages d'erreur qui se produisent lors de l'exécution d'une requête
<xref linkend="stmtddlscript"/>.
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: DDL préparation failed - set %d - only on node %</command>
</para>
<para>
Quelque chose s'est cassé lors du traitement d'un script DDL sur un des
n&oelig;uds. Ceci indique probablement que le schéma du n&oelig;ud était
différent de celui du n&oelig;ud origine&nbsp;; vous devez probablement
effectuer une modification à la main sur ce n&oelig;ud pour que
l'événement puisse être traité. Une alternative très regrettable consiste
à supprimer l'événement bloquant, sachant qu'il est possible que cette
suppression ne fonctionne pas...
</para>
</listitem>
<listitem>
<para>
<command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command>
</para>
<para>
Ce message est informatif, il indique combien de commandes SQL ont été traitées.
</para>
</listitem>
<listitem>
<para>
<command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command>
</para>
<para>
Ce message se produit lorsque le nombre de commandes traitées est
inférieure à 0 (ce qui est théoriquement impossible) ou supérieure à
MAXSTATEMENTS. Ceci indique que le script DDL est probablement mal
écrit...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: malloc() failure in DDL_SCRIPT - could not allocate %d bytes of memory</command>
</para>
<para>
Ceci se produit uniquement si vous soumettez un script DDL
extraordinairement long, qui sature la mémoire allouée à &lslon;
&nbsp;out of memory&nbsp;»).
</para>
</listitem>
<listitem>
<para>
<command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command>
</para>
<para>
Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils
sont soumis.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: DDL Statement failed - %s</command>
</para>
<para>
Un des ordres DDL a fonctionné sur le n&oelig;ud origine mais il a
échoué sur le n&oelig;ud local...
</para>
</listitem>
<listitem>
<para>
<command>CONFIG: DDL Statement success - %s</command>
</para>
<para>
Tout va bien...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command>
</para>
<para>
Apparemment, le script DDL ne peut pas être écrit dans le fichier de log
shipping...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command>
</para>
<para>
Le script ne peut pas être écrit dans un fichier de log shipping.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command>
</para>
<para>
Impossible de fermer un fichier de log shipping contenant un script DDL.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I ddlScript_prepare(): set % not found</command>
</para>
<para>
L'ensemble de réplication est introuvable sur ce n&oelig;ud; Vous avez
probablement spécifié un mauvais identifiant de n&oelig;ud...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command>
</para>
<para>
L'ensemble de réplication est introuvable sur ce n&oelig;ud. Vous avez
probablement spécifié un mauvais identifiant de n&oelig;ud...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command>
</para>
<para>
Apparemment, la table n'a pas été trouvée. Le schéma est peut-être erroné&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command>
</para>
<para>
Curieux... Le script tente de répliquer une table une
<emphasis>seconde</emphasis> fois&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command>
</para>
<para>
Ce message se produit lorsqu'une table est en cours de restauration vers
un état <quote>non-repliqué</quote>&nbsp;; apparemment, la table
répliquée n'a pas été trouvée.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command>
</para>
<para>
La table n'est pas dans un état répliqué. Cela ne devrait pas se produire
si la réplication fonctionne correctement...
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command>
</para>
<para>
Ceci se produit en général lorsque vous avez une table avec des triggers
que la réplication a dû cacher lors de l'abonnement du n&oelig;ud et que
vous avez ajouté un triggrer portant le même nom. Maintenant, lorsque l'on
tente de réactiver le trigger caché, les deux triggers entrent en conflit.
</para>
<para>
Le script DDL continuera a tourner, encore et encore, ou la commande
UNINSTALL NODE échouera, jusqu'à ce que vous supprimiez le trigger
<quote>visible</quote> à la main puisque vous l'avez probablement ajouté
à la main un peu plus tôt.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: Unable to disable triggers</command>
</para>
<para>
Cette erreur se produit à la suite du problème de <quote>triggers
multiples</quote>.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Problèmes avec les processus</title>
<para>
Le modèle de gestion des processus ("threading") de &slony1; n'est pas
directement <quote>paramétrable par les utilisateurs</quote>. Chaque démon
&lslon; crée un ensemble pré-défini de processus pour gérer les différentes
connexions nécessaires. La seule occasion où la gestion des processus peut
poser problème est lorsque les bibliothèques de &postgres; n'ont pas été
compilées <quote>correctement</quote>, auquel cas il sera de toute façon
impossible de compiler &slony1;.
</para>
<itemizedlist>
<listitem>
<para>
<command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command>
</para>
<para>
Impossible de créer un nouveau processus de traitement des événements distants.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command>
</para>
<para>
Ceci se produit en général lorsque le démon &lslon; démarre&nbsp;: un
processus est créé pour chaque n&oelig;ud que le n&oelig;ud local doit
écouter.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command>
</para>
<para>
Si un abonnement est modifié et qu'un n&oelig;ud n'est plus un n&oelig;ud
fournisseur, alors le processus qui traite les événements sur ce
n&oelig;ud peut être arrêté.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: disconnecting from data provider %d</command>
</para>
<para>
Un n&oelig;ud fournisseur qui n'est plus utilisé peut être supprimé&nbsp;;
si les informations de connexion sont changées, le démon &lslon; doit se
déconnecter et se reconnecter.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command>
</para>
<para>
Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événements.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command>
</para>
<para>
Curieux&nbsp;: il est impossible de réveiller le processus de
traitement&nbsp;; pourtant il devrait déjà y en avoir un...
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="logsubtime">
<title>Traces au moment d'un abonnement</title>
<para>
Un abonnement est une opération très spéciale pour &slony1;. Si vous avez un
grand volume de données à copier sur l'abonné, cela peut prendre un temps
considérable. &slony1; enregistre une quantité considérable d'informations
lors de ce processus, qui sera probablement très utile aux utilisateurs. En
particulier, il produit des traces à chaque fois qu'il commence et termine
la copie des données d'une table et lorsqu'il finit l'indexation de la table.
Cela ne rend pas un abonnement de 28 heures plus rapide, mais au moins cela
vous aide à suivre son déroulement.
</para>
<itemizedlist>
<listitem>
<para>
<command>DEBUG1: copy_set %d</command>
</para>
<para>
Ceci indique le départ de la copie de données pour un nouvel abonnement.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: set %d not found in runtime configuration </command>
</para>
<para>
&lslon; a tenté de lancer un abonnement&nbsp;; il n'a pas trouvé les
informations de connexion à la source des données. Peut-être que les
chemins ne sont pas correctement propagés&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: node %d has no pa_conninfo</command>
</para>
<para>
Apparemment, les informations de connexion sont
<emphasis>fausses</emphasis>...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: copy set %d cannot connect to provider DB node %d</command>
</para>
<para>
&lslon; n'a pas pu se connecter au fournisseur. Est-ce que les
informations de connexion sont fausses&nbsp;? Peut-être que
l'authentification est mal configurée&nbsp;? Peut-être que la base de
donnée ne fonctionne pas&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: connected to provider DB</command>
</para>
<para>
Excellent&nbsp;: le processus de copie a pu se connecter au fournisseur.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: sequenceSetValue(): sequence % not found</command>
</para>
<para>
Curieux&nbsp;; la séquence de l'objet est absente. Est-ce que quelqu'un
l'a supprimé à la main du schéma&nbsp;? (<emphasis>c'est-à-dire</emphasis>
sans utiliser <xref linkend="stmtddlscript"/>)
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: subscribeSet() must be called on provider</command>
</para>
<para>
Cette fonction devrait être appelée sur le n&oelig;ud fournisseur.
Normalement, &lslonik; gère correctement ce cas, à moins qu'il y ait de
mauvais DSN dans un script &lslonik;...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: subscribeSet(): set % not found</command>
</para>
<para>
Le n&oelig;ud fournisseur ne connaît pas cet ensemble de réplication.
Un mauvais paramètre dans un script &lslonik;&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: subscribeSet(): set origin and receiver cannot be identical</command>
</para>
<para>
Un n&oelig;ud origine ne peut pas être abonné à lui-même.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: subscribeSet(): set provider and receiver cannot be identical</command>
</para>
<para>
Un n&oelig;ud récepteur doit s'abonner à un n&oelig;ud
<emphasis>différent</emphasis>...
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: subscribeSet(): provider % is not an active forwarding node for replication set %</command>
</para>
<para>
Vous devez utiliser un n&oelig;ud fournisseur actif et en cours de
fonctionnement comme source des données.
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: subscribeSet_int(): set % is not active, cannot change provider</command>
</para>
<para>
Vous ne pouvez pas changer le fournisseur pour le moment...
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: subscribeSet_int(): set % not found</command>
</para>
<para>
Ce n&oelig;ud ne connaît pas l'ensemble de réplication... Vous avez
peut-être soumis un mauvais paramètre&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: unsubscribeSet() must be called on receiver</command>
</para>
<para>
Cela parait trivial... Ceci indique probablement un mauvais DSN &lslonik;
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: Cannot unsubscribe set % while being provider</command>
</para>
<para>
Cela semble évident&nbsp;; <xref linkend="stmtunsubscribeset"/> va
échouer si un n&oelig;ud est dépendant des abonnés dont il est le
fournisseur.
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: cleanupEvent(): Single node - deleting events &lt; %</command>
</para>
<para>
S'il n'y a qu'un seul n&oelig;ud, l'événement de nettoyage va supprimer
les anciens événements afin de ne pas récupérer le <quote>crud</quote>.
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: tableAddKey(): table % not found</command>
</para>
<para>
Peut-être que vous n'avez pas copié le schéma proprement&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: tableDropKey(): table with ID% not found</command>
</para>
<para>
Cela paraît curieux&nbsp;; cette table est probablement déjà en cours de
réplication&nbsp;; il est donc étrange que cette table ait disparue.
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: determineIdxnameUnique(): table % not found</command>
</para>
<para>
Avez-vous correctement copié le schéma sur le nouveau n&oelig;ud&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: table % has no primary key</command>
</para>
<para>
Ceci signifie probablement que le chargement du schéma s'est mal passé...
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: table % has no unique index %</command>
</para>
<para>
Ceci signifie probablement que le chargement du schéma s'est mal passé...
</para>
</listitem>
<listitem>
<para>
<command>WARN: remoteWorkerThread_%d: transactions earlier than XID %s are still in progress</command>
</para>
<para>
Ceci indique qu'une vieille transaction est en cours d'exécution et
qu'elle a débutée avant le plus vieil événement <command>SYNC</command>
disponible sur le fournisseur. &slony1; ne peut pas lancer une réplication
tant que cette transaction n'est pas achevée. Ce message sera répété
jusqu'à ce que la transaction aboutisse...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: prepare to copy table %s</command>
</para>
<para>
Ceci indique que &lslon; commence les préparatifs pour mettre en place un
abonnement pour une table.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: table %s will require Slony-I serial key</command>
</para>
<para>
Évidemment, cette table est définie avec <xref linkend="stmttableaddkey"/>
et &slony1; a ajouté une clef primaire supplémentaire.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not lock table %s on subscriber</command>
</para>
<para>
Pour une certaine raison, la table ne peut pas être verrouillée, donc la
réplication doit être redémarrée. Si le problème concerne un inter-blocage
&nbsp;deadlock&nbsp;»), essayer la commande à nouveau peut fonctionner.
S'il s'agit d'un autre problème, vous devez intervenir...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: all tables for set %d found on subscriber</command>
</para>
<para>
Ce message d'information indique que lors du premier passage sur les tables,
aucun problème n'a été trouvé...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: copy sequence %s</command>
</para>
<para>
Ce message indique qu'une séquence est traitée...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: copy table %s</command>
</para>
<para>
&lslon; commence la copie d'une table...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
</para>
<para>
Une nouvelle colonne vient d'être ajoutée dans la table afin qu'elle
dispose d'une clef primaire.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: local table %s already has Slony-I serial key</command>
</para>
<para>
Il n'est pas nécessaire d'ajouter une clef de type 'serial'&nbsp;;
apparemment, elle existe déjà.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: table %s does not require Slony-I serial key</command>
</para>
<para>
Apparemment, cette table n'a pas besoin d'une clef primaire supplémentaire...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command>
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: Begin COPY of table %s</command>
</para>
<para>
&lslon; va lancer la commande COPY des deux côtés pour copier la table...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: Could not generate copy_set request for %s - %s</command>
</para>
<para>
Ceci indique que la requête <command>delete/copy</command> a échouée sur
l'abonné. Le &lslon; va répéter la tentative de
<command>COPY_SET</command>&nbsp;; il est probable que l'opération continue
d'échouer...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: copy to stdout on provider - %s %s</command>
</para>
<para>
Évidemment, quelque chose ne fonctionne pas au niveau de l'opération
COPY vers la sortie <filename>stdout</filename> sur le n&oelig;ud
fournisseur... l'événement va être lancé à nouveau...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: copy from stdin on local node - %s %s</command>
</para>
<para>
Évidemment, quelque chose n'a pas fonctionné lors de l'opération COPY
dans la table sur le n&oelig;ud abonné... L'événement va être lancé à
nouveau...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: %d bytes copied for table %s</command>
</para>
<para>
Ce message indique que l'opération COPY sur la table est achevée. Ceci
est suivi d'un <command>ANALYZE</command> et d'une réindexation de la
table sur l'abonné.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: %.3f seconds to copy table %s</command>
</para>
<para>
Après ce message, la copie, la réindexation et l'analyse sont terminées sur l'abonné.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: set last_value of sequence %s (%s) to %s</command>
</para>
<para>
Sans surprise, cela indique qu'une séquence a été traitée sur l'abonnée.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: %.3 seconds to copy sequences</command>
</para>
<para>
Ce message indique le temps passé pour le traitement de l'événement
<command>COPY_SET</command>.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: query %s did not return a result</command>
</para>
<para>
Ceci indique qu'une requête, exécutée lors du traitement final de
l'événement <command>COPY_SET</command>, a échoué. La copie est
redémarrée...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: copy_set no previous SYNC found, use enable event</command>
</para>
<para>
Ceci se produit si aucun événement SYNC n'a été trouvé&nbsp;; l'événement
courant est positionné au niveau de l'événement
<command>ENABLE_SUBSCRIPTION</command>.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: copy_set SYNC found, use event seqno %s</command>
</para>
<para>
Ceci se produit si un événement SYNC est trouvé&nbsp;; l'événement
courant est positionné à la valeur indiquée.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: sl_setsync entry for set %d not found on provider</command>
</para>
<para>
Une information de synchronisation était attendue en provenance d'un
n&oelig;ud abonné existant, mais elle n'a pas été trouvée. Il s'agit
probablement d'une erreur capable de bloquer la réplication...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: could not insert to sl_setsync_offline</command>
</para>
<para>
Après la configuration d'un abonné et presque tout est en place, des
écritures dans un fichier de log shipping ont échouées. Peut-être que
le disque est plein...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: %.3f seconds to build initial setsync status</command>
</para>
<para>
Ce message indique le temps total nécessaire pour que l'événement copy_set
soit réalisé...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: disconnected from provider DB</command>
</para>
<para>
À la fin d'un événement d'abonnement, le &lslon; de l'abonné va se
déconnecter du fournisseur et supprimer les connexions...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
</para>
<para>
Ce message indique le temps total nécessaire pour effectuer la commande
copy_set... c'est le signe d'un abonné réussi&nbsp;!
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command>
</para>
<para>
Ce message indique le temps total nécessaire pour effectuer la commande
copy_set... c'est le signe d'un abonné réussi&nbsp;!
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="logmergeset">
<title>Messages associés à la commande MERGE SET</title>
<para>
Diverses exceptions peuvent conduire au rejet d'un <xref
linkend="stmtmergeset"/>&nbsp;; ces problèmes doivent être réglés avant de
soumettre à nouveau la requête.
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slony-I: merged set ids cannot be identical</command>
</para>
<para>
Il est illogique d'essayer de fusionner un ensemble avec lui-même.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: set % not found </command>
</para>
<para>
Un ensemble absent ne peut pas être fusionné.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: set % does not originate on local node</command>
</para>
<para>
La requête <xref linkend="stmtmergeset"/> doit être envoyée au n&oelig;ud
origine des ensembles qu'il faut fusionner.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: subscriber lists of set % and % are different</command>
</para>
<para>
Les ensembles ne peuvent être fusionné que s'ils ont la même liste d'abonnés.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command>
</para>
<para>
<xref linkend="stmtmergeset"/> ne peut pas fusionner tant que tous les
abonnements ne sont pas achevés. Si ce message apparaît, cela signifie
que les listes d'abonnées sont identiques mais qu'un ou plusieurs
n&oelig;uds n'ont pas terminé leur processus d'abonnement. Il est
probable qu'attendre une courte période avant de soumettre à nouveau la
requête <xref linkend="stmtmergeset"/> suffise à régler le problème.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="lognormalsync">
<title>Traces associés l'activité normale des SYNC</title>
<para>
Certains de ces messages indiquent des erreurs mais,
<quote>normalement</quote>, ils présentent les informations attendues
lorsque la réplication fonctionne correctement.
</para>
<itemizedlist>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: forward confirm %d,%s received by %d</command>
</para>
<para>
Ces événements devraient apparaître fréquemment et suivant une certaine
routine, car ils témoignent des confirmations d'événements qui sont
reçues.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: SYNC %d processing</command>
</para>
<para>
Ce message indique le début du traitement d'un <command>SYNC</command>.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: No pa_conninfo for data provider %d</command>
</para>
<para>
Les informations de connexion au fournisseur ne sont pas disponibles.
Normalement, cela n'est pas possible...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteListenThread_%d: timeout for event selection</command>
</para>
<para>
Ce message signifie que le processus d'écoute
(<filename>src/slon/remote_listener.c</filename>) s'est arrêté après
avoir tenté de déterminer quels événements étaient en attente.
</para>
<para>
Ceci se produit lorsqu'une connexion réseau est coupée. Si c'est le cas,
redémarrer le démon &lslon; devrait suffire à résoudre le problème.
</para>
<para>
Par ailleurs, ceci peut se produire lorsque le démon &lslon; de ce
n&oelig;ud a été en panne pendant longtemps, et qu'il y a une quantité
énorme de lignes dans la table <envar>sl_event</envar> sur ce n&oelig;ud
ou sur d'autres, en attente d'être traitées et qu'il faut plus de <xref
linkend="slon-config-remote-listen-timeout"/> secondes pour exécuter la
requête SQL. Dans les anciennes version de &slony1;, ce paramètre de
configuration n'existait pas&nbsp;; le temps maximum était fixé à 300
secondes. Dans les nouvelles versions, vous pouvez augmenter cette valeur
dans le fichier de configuration de &lslon; pour que le démon continue à
traiter les événements. Puis vous pourrez enquêter pour découvrir
pourquoi personne ne surveillait le processus et pourquoi la réplication
a été rompue pendant aussi longtemps...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: cannot connect to data provider %d on 'dsn'</command>
</para>
<para>
Nous n'avons pas les informations de connexions
<emphasis>correctes</emphasis> pour nous connecter au fournisseur de
données.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: connected to data provider %d on 'dsn'</command>
</para>
<para>
Excellent&nbsp;; le démon &lslon; s'est connecté au fournisseur.
</para>
</listitem>
<listitem>
<para>
<command>WARN: remoteWorkerThread_%d: don't know what ev_seqno node %d confirmed for ev_origin %d</command>
</para>
<para>
Il n'y a aucune information de confirmation en provenance de ce
fournisseur&nbsp;; il faut annuler le <command>SYNC</command> et attendre
en espérant que cette information arrive rapidement...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d: data provider %d only confirmed up to ev_seqno %d for ev_origin %d </command>
</para>
<para>
Le fournisseur de ce n&oelig;ud est un abonné. Apparemment, cet abonné
est en retard. Le démon &lslon; doit attendre que le fournisseur rattrape
son retard avant de recevoir de <emphasis> nouvelles</emphasis> données.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: data provider %d confirmed up to ev_seqno %s for ev_origin %d - OK</command>
</para>
<para>
Très bien&nbsp;; le fournisseur dispose des données dont l'abonné a besoin...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: syncing set %d with %d table(s) from provider %d</command>
</para>
<para>
Ce message indique les plans d'actions d'un <command>SYNC</command>&nbsp;:
il y a un ensemble de tables à traiter.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: ssy_action_list value: %s length: %d</command>
</para>
<para>
Cette partie de la requête a collecté des données qui semblent être
<quote>volumineuses</quote>&nbsp;; ce message indique comment elles ont
été compressées...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: Didn't add OR to provider</command>
</para>
<para>
Ce message indique qu'il n'y avait rien dans une clause
<quote>fournisseur</quote> à l'intérieur de la requête qui collecte les
données à appliquer, ce qui ne devrait pas se produire. Il est probable
que les choses aient mal tournées quelque part...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: no sets need syncing for this event</command>
</para>
<para>
Ceci se produira pour tous les événements <command>SYNC</command> générés
sur les n&oelig;uds qui ne sont pas l'origine d'un ensemble de
réplication. Vous pouvez vous attendre à voir ces messages assez
fréquemment.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: activate helper %d</command>
</para>
<para>
Un processus va être lancé pour aider à traiter les données de l'événement
<command>SYNC</command>...
</para>
</listitem>
<listitem>
<para>
<command>DEBUG4: remoteWorkerThread_%d: waiting for log data</command>
</para>
<para>
Le processus attend que les données se consument (c'est-à-dire qu'elles
soient appliquées sur le réplicat).
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: %s %s - qualification was %s</command>
</para>
<para>
Apparemment, l'application de données répliquées sur l'abonné a échoué....
ceci indique très certainement une corruption assez grave.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: replication query did not affect one row (cmdTuples = %s) - query was: %s qualification was: %s</command>
</para>
<para>
Si <envar>SLON_CHECK_CMDTUPLES</envar> est défini, &lslon; applique les
changements ligne par ligne, et vérifie que chaque changement affecte
exactement une ligne. Apparemment, ce n'était pas le cas ici, ce qui
semble indiquer une corruption de la réplication. C'est plutôt une
mauvaise nouvelle...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: SYNC aborted</command>
</para>
<para>
Le <command>SYNC</command> a été annulé. Le &lslon; va probablement
tenter de nouveau ce <command>SYNC</command> dans quelque temps. Si le
<command>SYNC</command> échoue encore et toujours, il y un problème
récurrent et la réplication ne va probablement pas reprendre sans une
intervention. Il est peut-être nécessaire de désabonner/réabonner
l'ensemble de réplication concerné, ou si il n'y a qu'un seul ensemble
de réplication sur le n&oelig;ud esclave, il est parfois plus simple de
supprimer et de recréer le n&oelig;ud. Si les connexions de l'application
peuvent être détournées vers le n&oelig;ud maître pendant cette opération,
alors il n'est pas nécessaire d'arrêter le service.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: new sl_rowid_seq value: %s</command>
</para>
<para>
Ce message rend compte de la progression de cette séquence interne de
&slony1;.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: SYNC %d done in %.3f seconds</command>
</para>
<para>
Ce message indique qu'un <command>SYNC</command> s'est achevé correctement.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG1: remoteWorkerThread_%d_d:%.3f seconds delay for first row </command>
</para>
<para>
Ce message indique combien de temps il a fallu pour récupérer la première
ligne du curseur LOG qui lit les données dans les tables sl_log tables.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d_d: large log_cmddata for actionseq %s not found</command>
</para>
<para>
&lslon; n'a pas trouvé les données relatives à une <quote>très
grande</quote> ligne de la table sl_log qui a été récupéré
individuellement. Ceci ne devrait pas se produire.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d_d:%.3f seconds until close cursor</command>
</para>
<para>
Ceci indique combien de temps il a fallu pour lire les données dans le
curseur LOG qui extrait les données des tables sl_log.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d_d: inserts=%d updates=%d deletes=%d</command>
</para>
<para>
Ce message montre l'activité enregistrée dans le <command>SYNC</command>
courant.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: compress_actionseq(list,subquery) Action list: %s</command>
</para>
<para>
Ce message indique qu'une partie de la requête du curseur LOG va être
compressée. (Dans certains cas, les requêtes peuvent grossir jusqu'à
une taille <emphasis>énorme</emphasis> et faire exploser l'analyseur
de requêtes...).
</para>
</listitem>
<listitem>
<para>
<command>DEBUG3: remoteWorkerThread_%d: compressed actionseq subquery %s</command>
</para>
<para>
Ce message indique comment la sous-requête a été compressée.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="logaddobjects">
<title>Traces concernant l'ajout d'objets dans des ensembles de réplication</title>
<para>
Ces messages apparaîtront dans les traces d'un n&oelig;ud origine au moment
où vous configurerez un ensemble de réplication&nbsp;; certains apparaîtront
sur les n&oelig;uds abonnés lors de leur abonnement.
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slony-I: setAddTable_int(): table % has no index %</command>
</para>
<para>
Apparemment, l'index de clé étrangère spécifié est absent sur ce
n&oelig;ud...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddTable_int(): table % not found</command>
</para>
<para>
La table n'a pas été trouvé sur ce n&oelig;ud&nbsp;; avez-vous chargé
correctement le schéma&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddTable_int(): table % is not a regular table</command>
</para>
<para>
Vous avez tenté de répliquer quelque chose qui n'est pas dans la
table&nbsp;; vous ne pouvez pas faire ça&nbsp;!
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: Slony-I setAddTable_int(): table % PK column % nullable</command>
</para>
<para>
Vous avez tenté de répliquer une table dont une colonne de la clef
primaire candidate peut être NULL. Toutes les colonnes participant à
une clef primaire doivent être <command>NOT NULL</command>. Cette
requête va échouer.
</para>
<para>
Une vérification de cette condition fut introduit dans la version 1.2 de
&slony1;. Si vous avez un réplicat 1.1, il va continuer à fonctionner
après la mise à jour en 1.2 mais vous rencontrerez ce message lorsque
vous essaierez d'ajouter de nouveaux abonnés.
</para>
<para>
Vous pouvez chercher des combinaisons table/index ayant des colonnes
pouvant être NULL sur un n&oelig;ud existant avec la requête
suivante&nbsp;:
<screen>select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
where t.tab_reloid = c.oid
and t.tab_idxname = ic.relname
and ic.oid = i.indexrelid
and att.attrelid = i.indexrelid
and att2.attname = att.attname
and att2.attrelid = c.oid
and att2.attnotnull = 'f';</screen>
</para>
<para>
Ces cas peuvent être rectifiés en exécutant à chaque fois une requête du
type&nbsp;:
<command>alter table matable alter column nullablecol set not null;</command>
Lancée sur un abonné ayant une table vide, cette requête s'exécutera très
rapidement. Elle prendra plus de temps sur une table qui contient déjà
beaucoup de données car la modification nécessite un parcours de la table
pour vérifier qu'il n'existe aucune ligne ayant la valeur NULL dans la
colonne.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddTable_int(): table % not replicable!</command>
</para>
<para>
Ceci se produit à cause d'une colonne qui n'est pas NOT NULL dans une
clef primaire.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddTable_int(): table id % has already been assigned!</command>
</para>
<para>
L'identifiant de la table doit être assigné de manière unique dans <xref
linkend="stmtsetaddtable"/>&nbsp;; apparemment, vous avez demandé une
valeur qui est déjà utilisée.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence(): set % not found</command>
</para>
<para>
Apparemment, l'ensemble que vous demandez n'est pas disponible...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence(): set % has remote origin</command>
</para>
<para>
Vous pouvez uniquement ajouter des objets sur le n&oelig;ud origine.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence(): cannot add sequence to currently subscribed set %</command>
</para>
<para>
Apparemment, l'ensemble de réplication que vous demandez a déjà été
abonné. Vous ne pouvez pas ajouter des tables/séquences dans un ensemble
qui a déjà des abonnés. Vous devez créer un nouvel ensemble, y ajouter
des objets et définir ses abonnements
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence_int(): set % not found</command>
</para>
<para>
Apparemment, l'ensemble que vous demandez n'est pas disponible...
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence_int(): sequence % not found</command>
</para>
<para>
Apparemment, la séquence que vous demandez n'est pas disponible sur ce
n&oelig;ud. Comment avez-vous mis en place le schéma sur les n&oelig;uds
abonnés&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence_int(): % is not a sequence</command>
</para>
<para>
Ce message est assez évident.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setAddSequence_int(): sequence ID % has already been assigned</command>
</para>
<para>
Chaque identifiant de séquence ajouté doit être unique. Apparemment, vous
avez réutilisé un identifiant déjà existant.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Traces lors du déplacement d'un objet d'un ensemble vers un autre</title>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slony-I setMoveTable_int(): table % not found</command>
</para>
<para>
La table n'a pas été trouvée sur ce n&oelig;ud&nbsp;; vous avez
probablement indiqué le mauvais identifiant.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveTable_int(): set ids cannot be identical</command>
</para>
<para>
Quel est l'intérêt de déplacer une table dans un ensemble où elle se
trouve déjà&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveTable_int(): set % not found</command>
</para>
<para>
L'ensemble n'a pas été trouvé sur le n&oelig;ud&nbsp;; vous avez
probablement indiqué un mauvais identifiant.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveTable_int(): set % does not originate on local node</command>
</para>
<para>
L'ensemble n'est pas originaire de ce n&oelig;ud&nbsp;; vous avez
probablement indiqué le mauvais EVENT NODE.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveTable_int(): subscriber lists of set % and % are different</command>
</para>
<para>
Vous pouvez uniquement déplacer les objets entre des ensembles qui ont
la même liste d'abonnés.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveSequence_int(): sequence % not found</command>
</para>
<para>
La séquence n'a pas été trouvée sur ce n&oelig;ud&nbsp;; vous avez
probablement indiqué un mauvais identifiant.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveSequence_int(): set ids cannot be identical</command>
</para>
<para>
Quel est l'intérêt de déplacer une séquence dans un ensemble où elle se
trouve déjà&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveSequence_int(): set % not found</command>
</para>
<para>
L'ensemble n'a pas été trouvé sur le n&oelig;ud&nbsp;; vous avez
probablement indiqué un mauvais identifiant.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveSequence_int(): set % does not originate on local node</command>
</para>
<para>
L'ensemble n'est pas originaire de ce n&oelig;ud&nbsp;; vous avez
probablement indiqué le mauvais EVENT NODE.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setMoveSequence_int(): subscriber lists of set % and % are different</command>
</para>
<para>
Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la
même liste d'abonnés.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Problèmes lors de la suppression d'objets</title>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slony-I setDropTable(): table % not found</command>
</para>
<para>
La table n'a pas été trouvée sur ce n&oelig;ud. Êtes-vous sûr d'avoir
indiqué le bon identifiant&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setDropTable(): set % not found</command>
</para>
<para>
L'ensemble de réplication n'a pas été trouvé sur ce n&oelig;ud.
Êtes-vous sûre d'avoir indiqué le bon identifiant&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setDropTable(): set % has remote origin</command>
</para>
<para>
L'ensemble de réplication n'a pas ce n&oelig;ud pour origine. Vous
devez probablement spécifier le paramètre <command>EVENT NODE</command>
dans la commande <xref linkend="stmtsetdroptable"/>.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setDropSequence_int(): sequence % not found</command>
</para>
<para>
Est-ce que cette séquence ne se trouverait pas plutôt dans un autre
ensemble&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setDropSequence_int(): set % not found</command>
</para>
<para>
Avez-vous spécifié le bon identifiant d'ensemble de réplication&nbsp;?
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I setDropSequence_int(): set % has origin at another node - submit this to that node</command>
</para>
<para>
Ce message semble assez évident.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Problèmes lors de MOVE SET, FAILOVER, DROP NODE</title>
<para>
Beaucoup de ces erreurs se produiront si vous soumettez un script &lslonik;
qui décrit une reconfiguration incompatible avec la configuration actuelle
de votre cluster. Ceci devrait vous faire dire&nbsp;: <quote>Heureusement
que &lslonik; a détecté ce problème à ma place&nbsp;!</quote>
</para>
<para>
D'autres messages se produisent lorsque &lslon; s'avertit lui-même qu'il va
s'arrêter. Tout <emphasis>devrait</emphasis> bien se passer lorsque vous le
redémarrez car il lira la nouvelle configuration lors de son redémarrage.
</para>
<para>
Hélas, quelques messages indiquent que <quote>quelque chose de mauvais est
arrivé</quote>, auquel cas la solution ne sera pas nécessairement simple.
Personne n'a dit que la réplication était facile...
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slony-I: DROP_NODE cannot initiate on the dropped node</command>
</para>
<para>
Vous devez préciser un paramètre EVENT NODE différent du n&oelig;ud que
vous voulez supprimer.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: Node % is still configured as a data provider</command>
</para>
<para>
Vous ne pouvez pas supprimer un n&oelig;ud qui est utilisé comme
fournisseur de données&nbsp;; vous devez remodeler les abonnements pour
qu'aucun n&oelig;ud ne soit dépendant de celui-ci.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: Node % is still origin of one or more sets</command>
</para>
<para>
Vous ne pouvez pas supprimer un n&oelig;ud si c'est l'origine d'un
ensemble de réplication&nbsp;! Utilisez d'abord <xref
linkend="stmtmoveset"/> ou <xref linkend="stmtfailover"/>.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: cannot failover - node % has no path to the backup node</command>
</para>
<para>
Vous ne pouvez pas effectuer une bascule d'urgence vers un n&oelig;ud qui
n'est pas connecté à tous les abonnés, au moins indirectement.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: cannot failover - node % is not subscribed to set %</command>
</para>
<para>
Vous ne pouvez pas faire une bascule d'urgence vers un n&oelig;ud qui
n'est pas abonné à tous les ensembles de réplication essentiels.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: cannot failover - subscription for set % is not active</command>
</para>
<para>
Si l'abonnement a été configuré mais pas activé, la bascule d'urgence
n'est pas possible.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: cannot failover - node % is not a forwarder of set %</command>
</para>
<para>
Vous ne pouvez effectuer une bascule d'urgence ou une bascule contrôlée
que vers un n&oelig;ud transmetteur.
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: failedNode: set % has no other direct receivers - move now</command>
</para>
<para>
Si le n&oelig;ud de sauvegarde est le seul abonné direct, alors la
situation est simplifiée... Pas besoin de remodeler les abonnements&nbsp;!
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: failedNode set % has other direct receivers - change providers only</command>
</para>
<para>
Dans ce cas, tous les abonnés directs sont redirigés vers le n&oelig;ud
de sauvegarde et le n&oelig;ud de sauvegarde est redirigé vers un autre
n&oelig;ud pour qu'il puisse rattraper son retard.
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: Slony-I: Please drop schema _@CLUSTERNAME@</command>
</para>
<para>
Un n&oelig;ud a été désinstallé&nbsp;; vous pouvez supprimer le schéma...
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Permutation des traces</title>
<para>
Ces messages sont liés à la nouvelle fonctionnalité apparue dans la version
1.2 qui permet à &slony1; de permuter périodiquement le stockage des données
entre <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
</para>
<itemizedlist>
<listitem>
<para>
<command>Slony-I: Logswitch to sl_log_2 initiated'</command>
</para>
<para>
Ce message indique que &lslon; est en train de permuter vers cette table
de log.
</para>
</listitem>
<listitem>
<para>
<command>Slony-I: Logswitch to sl_log_1 initiated'</command>
</para>
<para>
Ce message indique que &lslon; est en train de permuter vers cette table
de log.
</para>
</listitem>
<listitem>
<para>
<command>Previous logswitch still in progress</command>
</para>
<para>
Une tentative de permutation a été faite alors qu'une permutation était
déjà en cours.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: remoteWorkerThread_%d: cannot détermine current log status</command>
</para>
<para>
La tentative de lecture dans la table sl_log_status, qui détermine si on
travaille sur <envar>sl_log_1</envar> ou <envar>sl_log_2</envar>, n'a
donné aucun résultat. Ce n'est pas bon signe car il doit y avoir des
données dans cette table... La réplication va probablement s'arrêter dans
peu de temps.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: current local log_status is %d</command>
</para>
<para>
Ce message indique la table (<envar>sl_log_1</envar> ou
<envar>sl_log_2</envar>) utilisée pour stocker les données de réplication.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Divers</title>
<para>
Les messages ci-dessous ne sont pas encore classés. Les auteurs de la
documentation ont encore du travail...
</para>
<itemizedlist>
<listitem>
<para>
<command>ERROR: Slonik version: @MODULEVERSION@ != Slony-I version in PG build %</command>
</para>
<para>
Ce message est produit par la fonction
<function>checkmoduleversion()</function> lorsqu'il y a un problème de
correspondance entre la version de &slony1; telle qu'elle est indiquée
par &lslonik; et la version avec laquelle &postgres; a été compilé.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: registry key % is not an int4 value</command>
</para>
<para>
Message produit par <function>registry_get_int4()</function>. Cela indique
que la valeur demandée semble être à NULL.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: registry key % is not a text value</command>
</para>
<para>
Message produit par <function>registry_get_text()</function>. Cela
indique que la valeur demandée semble être à NULL.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: registry key % is not a timestamp value</command>
</para>
<para>
Message produit par <function>registry_get_timestamp()</function>. Cela
indique que la valeur demandée semble être à NULL.
</para>
</listitem>
<listitem>
<para>
<command>NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=%</command>
</para>
<para>
Ceci se produit typiquement lorsqu'un &lslon; se lance après qu'un autre ait
échoué&nbsp;; c'est un nettoyage de routine.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: This node is already initialized</command>
</para>
<para>
Ceci se produit typiquement lorsqu'on soumet une commande <xref
linkend="stmtstorenode"/> sur une n&oelig;ud qui a déjà été configuré
avec le schéma &slony1;.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: node % not found</command>
</para>
<para>
Toute tentative pour marquer un n&oelig;ud non listé localement comme
actif devrait échouer.
</para>
</listitem>
<listitem>
<para>
<command>ERROR: Slony-I: node % is already active</command>
</para>
<para>
Toute tentative pour marquer un n&oelig;ud déjà marqué comme actif devrait
échouer.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG4: remoteWorkerThread_%d: added active set %d to provider %d</command>
</para>
<para>
Indique que cet ensemble est fourni par ce fournisseur.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: event %d ignored - unknown origin</command>
</para>
<para>
Ceci se produit probablement lorsque des événements arrivent avant
l'événement <command>STORE_NODE</command> qui annonce que le nouveau
n&oelig;ud existe.
</para>
</listitem>
<listitem>
<para>
<command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command>
</para>
<para>
Ceci ce produit actuellement (2007) car la désactivation d'un
n&oelig;ud n'est pas une fonctionnalité supportée.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: event %d ignored - duplicate </command>
</para>
<para>
Ceci devrait se produire lorsqu'une notification d'événement arrive en
provenance de deux sources.
</para>
</listitem>
<listitem>
<para>
<command>DEBUG2: remoteWorkerThread_%d: unknown node %d</command>
</para>
<para>
Ceci se produit lorsque le démon &lslon; n'est conscient de l'existence
de ce n&oelig;ud. C'est probablement un signe que les requêtes
<command>STORE_NODE</command> ne se propagent pas.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>