Changeset 1129

Show
Ignore:
Timestamp:
09/05/08 21:59:08 (3 months ago)
Author:
daamien
Message:

Slony : slonik_ref ( à relire )

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/slonik_ref.xml

    r1122 r1129  
    16861686     nouveau doivent avoir le même noeud origine et les même noeuds abonnés. 
    16871687      
    1688      <caution><para> La méthode d'abonnement d'un nouvel ensemble de réplication  
    1689      permet de garantir que l'abonnement est complÚtement effectué sur tous les noeuds 
    1690      avant que le tables soient déplacées. Déplacer une table trop tÃŽt vers un nouvel ensemble, 
     1688     <caution><para> La méthode d'abonnement d'un nouvel ensemble de réplication est  
     1689                    particuliÚre, vous devez vous assurer l'abonnement est complÚtement effectué sur tous les noeuds 
     1690     avant de déplacer les tables. Déplacer une table trop tÃŽt vers un nouvel ensemble, 
    16911691     implique que le noeud abonné va essayer d'ajouter la table pendant le processus d'abonnement 
    16921692     de l'ensemble de réplication, ce qui échoue suite à une erreur de clef dupliquée et provoque  
    …… 
    17461746 
    17471747    <para> 
    1748      Change the set a sequence belongs to. The current set and the new 
    1749      set must originate on the same node and subscribed by the same 
    1750      nodes. 
    1751  
    1752      <caution><para> Due to the way subscribing to new sets works make 
    1753        absolutely sure that the subscription of all nodes to the sets 
    1754        is completely processed before moving sequences. Moving a sequence too 
    1755        early to a new set causes the subscriber to try and add the sequence 
    1756        already during the subscription process, which fails with a duplicate 
    1757        key error and breaks replication.</para></caution> 
     1748        Change l'ensemble de réplication dans lequel se trouve la séquence. 
     1749       L'ensemble courant et le nouveau doivent avoir le même noeud d'origine 
     1750       et les mêmes noeuds abonnés. 
     1751         
     1752     <caution><para> La méthode d'abonnement à un nouvel ensemble est particuliÚre, 
     1753        vous devez vous assurer que l'abonnement est complÚtement effectué 
     1754        avant de déplacer les séquences. Déplacer un séquence top tÃŽt peut impliquer 
     1755        une tentative d'ajout de la séquence pendant le processus d'abonnement, 
     1756        ce qui échouera en emettant une erreur à cause d'une clef dupliquée et 
     1757       provoquera l'arrêt de la réplication.</para></caution> 
    17581758      
    17591759     <variablelist> 
    17601760      <varlistentry><term><literal> ORIGIN = ival </literal></term> 
    1761        <listitem><para> Origin node for the set.  A future version of <application>slonik</application> 
    1762          might figure out this information by itself.</para></listitem> 
     1761       <listitem><para> Noeud d'origine de l'ensemble de réplication. Les 
     1762        futures versions de <application>slonik</application> 
     1763        deviner toutes seules cette information.</para></listitem> 
    17631764      </varlistentry> 
    17641765      <varlistentry><term><literal> ID = ival </literal></term> 
    17651766        
    1766        <listitem><para> Unique ID of the sequence.</para></listitem> 
     1767       <listitem><para> Identifiant unique de la séquence.</para></listitem> 
    17671768        
    17681769      </varlistentry> 
    17691770      <varlistentry><term><literal> NEW SET = ival </literal></term> 
    17701771        
    1771        <listitem><para> Unique ID of the set to which the sequence should be moved.</para></listitem> 
     1772       <listitem><para> Identifiant unique de l'ensemble de réplication dans lequel 
     1773        la séquence doit être déplacée.</para></listitem> 
    17721774        
    17731775      </varlistentry> 
    17741776     </variablelist> 
    17751777    </para> 
    1776     <para> This uses &funsetmovesequence;. </para> 
     1778    <para> Cette commande utilise &funsetmovesequence;. </para> 
    17771779   </refsect1> 
    17781780   <refsect1><title>Exemple</title> 
    …… 
    18021804   <refnamediv><refname>STORE TRIGGER</refname> 
    18031805     
    1804     <refpurpose> Indicate that a trigger should not be disabled by 
    1805     &slony1; on a subscriber node 
     1806    <refpurpose> Indique qu'un trigger ne doit pas être désactivé par &slony1;  
     1807sur un noeud abonné. should not be disabled by 
    18061808    </refpurpose></refnamediv> 
    18071809    
    …… 
    18141816    <title>Description</title> 
    18151817     
    1816     <para> By default, all user defined triggers and constraints are 
    1817      disabled on all subscriber nodes while a table is replicated. This 
    1818      command can be used to explicitly exclude a trigger from being 
    1819      disabled. 
    1820  
     1818    <para> Par défaut, tout les triggers définis par l'utilisateur sont 
     1819désactivés sur tout les noeuds abonnés lorsque la table est répliquée. 
     1820Cette commande peut être utilisée pour empêcher explicititement la désactivation 
     1821d'un trigger. 
    18211822     <variablelist> 
    18221823      <varlistentry><term><literal> TABLE ID = ival </literal></term> 
    1823        <listitem><para> The unique, numeric ID number of the table the trigger is defined for.</para></listitem> 
     1824       <listitem><para> L'indentifiant numérique et unique de la table concernée par le trigger.</para></listitem> 
    18241825        
    18251826      </varlistentry> 
    18261827      <varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term> 
    18271828        
    1828        <listitem><para> The name of the trigger as it appears in the 
    1829          <envar>pg_trigger</envar> system catalog.</para></listitem> 
     1829       <listitem><para> Le nom du trigger tel qu'on le trouve dans le catalogue systÚme 
     1830         <envar>pg_trigger</envar>.</para></listitem> 
    18301831        
    18311832      </varlistentry> 
    18321833      <varlistentry><term><literal> EVENT NODE = ival </literal></term> 
    18331834        
    1834        <listitem><para> (Optional) The ID of the node used to create 
    1835        the configuration event that tells all existing nodes about the 
    1836          special trigger. Default value is 1.</para></listitem> 
     1835       <listitem><para> (Optionel) L'identifiant du noeud utilisé pour  
     1836créer l'événement de configuration qui annonce aux noeuds existants la 
     1837présence d'un trigger spécial. Par défaut, cette valeur est 1. 
     1838         </para></listitem> 
    18371839 
    18381840      </varlistentry> 
    18391841     </variablelist> 
    18401842    </para> 
    1841     <note><para> A nifty trick is that you can run <command>STORE 
    1842     TRIGGER</command> <emphasis>before the trigger is 
    1843     installed;</emphasis> that will not cause any errors.  You could 
    1844     thus add &slony1;'s handling of the trigger 
    1845     <emphasis>before</emphasis> it is installed.  That allows you to 
    1846     be certain that it becomes active on all nodes immediately upon 
    1847     its installation via <xref linkend="stmtddlscript"/>; there is no 
    1848     risk of events getting through in between the <command>EXECUTE 
    1849     SCRIPT</command> and <command>STORE TRIGGER</command> 
    1850     events. </para> 
     1843    <note><para> Une astuce consiste à lancer <command>STORE 
     1844    TRIGGER</command> <emphasis>avant que le trigger soit installé 
     1845    ;</emphasis> ce qui ne provoquera pas d'errreurs. Vous pouvez 
     1846    ainsi définir la gestion d'un trigger par &slony1; r 
     1847    <emphasis>avant</emphasis> qu'il soit installé.  Vous êtes alors 
     1848    certain que le trigger est actif sur tous les noeuds immédiatement 
     1849aprÚs son installation via <xref linkend="stmtddlscript"/>; il n'y a  
     1850aucun risque de voir un événement passer entre les événements  
     1851    <command>EXECUTE 
     1852    SCRIPT</command> et <command>STORE TRIGGER</command>. </para> 
    18511853    </note>     
    1852     <para> This uses &funstoretrigger;. </para> 
    1853    </refsect1> 
    1854    <refsect1><title>Exemple</title> 
     1854    <para> Cette commande utilise &funstoretrigger;. </para> 
     1855   </refsect1> 
     1856   <refsect1><title>Exemple :</title> 
    18551857    <programlisting> 
    18561858STORE TRIGGER ( 
    …… 
    18621864   <refsect1> <title> Utilisation de verrous </title> 
    18631865 
    1864     <para> This operation will need to acquire an exclusive lock on 
    1865     the specified table on each node to which it applies in order to 
    1866     alter table schemas to add back the trigger, but only breifly. </para> 
     1866    <para> Cette opération pose briÚvement  un verrou exclusif sur la table spécifiée 
     1867sur chaque noeud auquel elle s'applique, afin de modifier le schéma de la table 
     1868et y ajouter de nouveau le trigger. 
     1869    </para> 
    18671870   </refsect1> 
    18681871   <refsect1> <title> Note de version </title> 
    18691872    <para> Cette commande fut introduite dans &slony1; 1.0 </para> 
    18701873 
    1871     <para> In &slony1; version 2.0, this command is removed as 
    1872     obsolete because triggers are no longer <quote>messed around 
    1873     with</quote> in the system catalogue. </para>     
     1874    <para> Avec &slony1; version 2.0, cette commande est supprimée car 
     1875obsolÚte, puisque les triggers ne sont plus <quote>trafiqués</quote>  
     1876dans le catalogue systÚme. </para>     
    18741877   </refsect1> 
    18751878  </refentry> 
    …… 
    18821885   <refnamediv><refname>DROP TRIGGER</refname> 
    18831886     
    1884     <refpurpose> Return a trigger to default behavior, where it will 
    1885     not fire on subscriber nodes </refpurpose></refnamediv> 
     1887    <refpurpose> Cette commande redonde à un trigger son comportement par défaut : 
     1888c'est à dire qu'il ne se déclenche pas sur les noeuds abonnés. </refpurpose></refnamediv> 
    18861889    
    18871890   <refsynopsisdiv> 
    …… 
    18931896    <title>Description</title> 
    18941897     
    1895     <para> Remove the special handling for the specified trigger. 
     1898    <para> Supprime la gestion particuliÚre du trigger spécifié. 
    18961899 
    18971900     <variablelist> 
    18981901      <varlistentry><term><literal> TABLE ID = ival </literal></term> 
    1899       <listitem><para> The unique, numeric ID number of the table the 
    1900       trigger is defined for.</para></listitem> 
     1902      <listitem><para> L'identifiant numérique et unique de la table pour laquelle le  
     1903trigger est défini.</para></listitem> 
    19011904        
    19021905      </varlistentry> 
    19031906      <varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term> 
    1904         
    1905        <listitem><para> The name of the trigger as it appears in the 
    1906         <envar>pg_trigger</envar> system catalog.</para></listitem> 
     1907 
     1908       <listitem><para> Le nom du trigger tel qu'on le trouve dans le catalogue systÚme 
     1909         <envar>pg_trigger</envar>.</para></listitem> 
    19071910 
    19081911      </varlistentry> 
    19091912      <varlistentry><term><literal> EVENT NODE = ival </literal></term> 
    1910         
    1911        <listitem><para> (Optional) The ID of the node used to create 
    1912          the configuration event that tells all existing nodes about the 
    1913          special trigger. Default value is 1.</para></listitem> 
    1914         
     1913 
     1914       <listitem><para> (Optionel) L'identifiant du noeud utilisé pour 
     1915créer l'événement de configuration qui annonce aux noeuds existants la 
     1916présence d'un trigger spécial. Par défaut, cette valeur est 1. 
     1917         </para></listitem> 
     1918 
     1919      </varlistentry> 
     1920 
    19151921      </varlistentry> 
    19161922     </variablelist> 
    19171923    </para> 
    1918     <para> This uses &fundroptrigger;. </para> 
     1924    <para> Cette commande utilise &fundroptrigger;. </para> 
    19191925   </refsect1> 
    19201926   <refsect1><title>Exemple</title> 
    …… 
    19281934   <refsect1> <title> Utilisation de verrous </title> 
    19291935 
    1930     <para> This operation will need to acquire an exclusive lock on 
    1931     the specified table on each node to which it applies in order to 
    1932     alter table schemas to remove the trigger. </para> 
     1936    <para> Cette opération pose briÚvement  un verrou exclusif sur la table spécifiée 
     1937sur chaque noeud auquel elle s'applique, afin de modifier le schéma de la table 
     1938et y ajouter de nouveau le trigger. 
     1939    </para> 
    19331940   </refsect1> 
    19341941   <refsect1> <title> Note de version </title> 
    19351942    <para> Cette commande fut introduite dans &slony1; 1.0 </para> 
    19361943 
    1937     <para> In &slony1; version 2.0, this command is removed as 
    1938     obsolete because triggers are no longer <quote>messed around 
    1939     with</quote> in the system catalogue. </para>     
    1940      
     1944    <para> Avec &slony1; version 2.0, cette commande est supprimée car 
     1945obsolÚte, puisque les triggers ne sont plus <quote>trafiqués</quote> 
     1946dans le catalogue systÚme. </para> 
    19411947   </refsect1> 
    19421948  </refentry> 
    …… 
    19481954   <refnamediv><refname>SUBSCRIBE SET</refname> 
    19491955     
    1950     <refpurpose> Start replication of &slony1; set </refpurpose></refnamediv> 
     1956    <refpurpose> Lance la réplication d'un ensemble donné </refpurpose></refnamediv> 
    19511957    
    19521958   <refsynopsisdiv> 
    …… 
    19581964    <title>Description</title> 
    19591965     
    1960     <para> This performs one of two actions: </para> 
     1966    <para> Cette commande réalise une des deux opérations suivantes : </para> 
    19611967 
    19621968    <itemizedlist> 
    19631969  
    1964     <listitem><para> Initiates replication for a replication set </para> 
    1965     <para> Causes a node (subscriber) to start replicating a set of 
    1966     tables either from the origin or from another provider node, which 
    1967     must itself already be be an active, forwarding subscriber.</para> 
    1968      
    1969     <para> The application tables contained in the set must already 
    1970      exist and should ideally be empty. The current version of 
    1971      &slony1; will <emphasis>not</emphasis> 
    1972      attempt to copy the schema of the set. The replication daemon will 
    1973      start copying the current content of the set from the given 
    1974      provider and then try to catch up with any update activity that 
    1975      happened during that copy process. After successful subscription, 
    1976      the tables are guarded on the subscriber, using triggers, against 
    1977      accidental updates by the application. 
    1978     </para> 
    1979      
    1980     <para> If the tables on the subscriber are 
    1981     <emphasis>not</emphasis> empty, then the <command>COPY 
    1982     SET</command> event (which is part of the subscription process) 
    1983     may wind up doing more work than should be strictly 
    1984     necessary:</para> 
     1970    <listitem><para> Initie la réplication pour un ensemble de réplication </para> 
     1971    <para> Ceci déclenche la réplication sur un noeud (abonné) soit à partir 
     1972de l'origine soit à partir du fournisseur, qui doit être lui même un noeud 
     1973abonné actif et transmetteur ("forwarding subscriber").</para> 
     1974     
     1975    <para> Les tables de l'application contenues dans l'ensemble de réplication  
     1976doivent déjà exister et idéalement elles sont vides. La version courante de  
     1977&slony1; ne tente <emphasis>pas</emphasis> de copier le schéma de l'ensemble  
     1978de réplication. Le démon de réplication démarre et commence à copier le contenu  
     1979de l'ensemble de réplication à partir du fournisseur spécifi, puis essaie 
     1980de rattraper son retard en rejouant les mises à jour qui se sont produites 
     1981lors du processus de copie. Un fois que l'abonnement a réussi, les tables  
     1982sont protégées avec des triggers contre les mises à jour en provenance de  
     1983l'application. 
     1984    </para> 
     1985     
     1986    <para> Si les tables sur l'abonné ne sont  
     1987    <emphasis>pas</emphasis> vides, alors l'événement <command>COPY 
     1988    SET</command> ( qui fait partie du processus d'abonnement) 
     1989    devra effectuer quelques taches supplémentaires :</para> 
    19851990     <itemizedlist> 
    19861991 
    1987       <listitem><para> It attempts to <command>TRUNCATE</command> the 
    1988       table, which will be efficient. </para> </listitem> 
     1992      <listitem><para> Il tente d'effectuer un <command>TRUNCATE</command> 
     1993     sur la table, ce qui devrait être efficace. </para> </listitem> 
    19891994       
    1990       <listitem><para> If that fails (a foreign key relationship might 
    1991       prevent TRUNCATE from working), it uses 
    1992       <command>DELETE</command> to delete all <quote>old</quote> 
    1993       entries in the table</para></listitem> 
    1994  
    1995       <listitem><para> Those old entries clutter up the table until it 
    1996       is next <command>VACUUM</command>ed <emphasis>after</emphasis> 
    1997       the subscription process is complete</para></listitem> 
     1995      <listitem><para> Si cela ne fonctionne pas ( une relation sur une  
     1996clef étrangÚre empêche peut-être le fonctionnement de TRUNCATE), il  
     1997utilise la commande  <command>DELETE</command> pour effacer toutes les  
     1998<quote>anciennes</quote> 
     1999entrées de la tables</para></listitem> 
     2000 
     2001      <listitem><para> Ces anciennes données encombrent encore l'espace 
     2002disque jusqu'à ce qu'un <command>VACUUM</command> soit effectué <emphasis>aprÚs</emphasis> 
     2003la fin du processus d'abonnement.</para></listitem> 
    19982004       
    1999       <listitem><para> The indices for the table will contain entries 
    2000       for the old, deleted entries, which will slow the process of 
    2001       inserting new entries into the index.</para></listitem> 
     2005      <listitem><para> Les index de la tables contiendront de références 
     2006aux anciennes données, ce qui ralentira l'insertion de nouvelles données 
     2007dans les index.</para></listitem> 
    20022008     </itemizedlist> 
    20032009 
    2004      <warning><para> This operation can take a (potentially distinctly) 
    2005      non-zero period of time.  If you have a great deal of data in a 
    2006      particular set of tables, it may take hours or even (if <quote>a 
    2007      great deal</quote> indicates <quote>tens or hundreds gigabytes of 
    2008      data</quote>) possibly multiple days for this event to 
    2009      complete.</para> 
    2010  
    2011      <para> The <command>SUBSCRIBE SET</command> request will, 
    2012      nonetheless, return fairly much immediately, even though the 
    2013      work, being handled by the <command>COPY SET</command> event, is 
    2014      still in progress.  If you need to set up subscriptions for a set 
    2015      of cascading nodes, you will need to wait for each subscriber to 
    2016      complete subscribing before submitting requests for subscriptions 
    2017      that use that node as a provider.  If you don't, it won't be a 
    2018      big deal: <command>slonik</command> will check the node, discover 
    2019      that it is not yet an active provider for the set, and report 
    2020      back:</para> 
     2010     <warning><para> Le temps d'execution de cette opération n'est pas  
     2011négligeable. Si vous avez un grand volume de données dans un ensemble  
     2012particulier de tables, cela peut prendre plusieurs heures, voire plusieurs 
     2013jours pour que l'opération aboutisse ( ici <quote>"un grand volume</quote> 
     2014signifie <quote>des dizaines ou des centaines de gigabytes de 
     2015</quote>).</para> 
     2016 
     2017     <para> Cependant, la requête  <command>SUBSCRIBE SET</command> se terminera 
     2018presque immédiatement, même si les travaux, gérés par l'événement 
     2019<command>COPY SET</command>, sont encore en cours. Si vous devez configurer 
     2020les abonnements sur des noeuds en cascade, vous devez attendre que chaque 
     2021abonné ait terminé son abonnement avant de soumettre des requête d'abonnement 
     2022qui utilise ce noeud comme fournisseur. Si vous ne le faites pas, ce n'est pas 
     2023trÚs grave : <command>slonik</command> va vérifier le noeud, découvrir qu'il  
     2024n'est pas encore un fournisseur actif et reporter l'erreur suivante : 
     2025</para> 
    20212026 
    20222027<programlisting> 
    …… 
    20242029</programlisting> 
    20252030 
    2026      <para> In effect, such subscription requests will be ignored 
    2027      until the provider is ready.</para> 
     2031     <para> En pratique, de telles requêtes d'abonnement seront ignorées 
     2032jusqu'à ce que le fournisseur soit prêt.</para> 
    20282033</warning> 
    20292034 
    20302035     </listitem> 
    20312036 
    2032      <listitem><para> Revising subscription information for already-subscribed nodes. </para> 
    2033  
    2034      <para> If you need to revise subscription information for a 
    2035        node, you <emphasis>also</emphasis> submit the new information 
    2036        using this command, and the new configuration will be propagated 
    2037        throughout the replication network.  The normal reason to revise 
    2038        this information is that you want a node to subscribe to a 
    2039        <emphasis> different </emphasis> provider node, or for a node to 
    2040        become a <quote>forwarding</quote> subscriber so it may later 
    2041        become the provider for a later subscriber.</para> 
     2037     <listitem><para> Modifier les informations d'abonnement pour les  
     2038noeuds qui sont déjà abonnés. </para> 
     2039 
     2040     <para> Si vous devez modifier les informations d'abonnement pour un  
     2041noeud donné, vous devez <emphasis>également</emphasis> soumettre les  
     2042nouvelles informations avec cette commande, et la nouvelle configuration sera 
     2043propagée à travers le réseau de réplication. En général, on modifier 
     2044les informations d'abonnement lorsque l'on veut abonner un noeud à un fournisseur 
     2045 <emphasis> différent </emphasis> ou transformer un noeud en <quote>transmetteur</quote> 
     2046afin qu'il puisse à son tour devenir le fournisseur d'un autre abonné. 
     2047</para> 
    20422048 
    20432049     </listitem> 
    …… 
    20462052     <variablelist> 
    20472053      <varlistentry><term><literal> ID = ival </literal></term> 
    2048        <listitem><para> ID of the set to subscribe</para></listitem> 
     2054       <listitem><para> Identifiant de l'ensemble auquel on s'abonne</para></listitem> 
    20492055        
    20502056      </varlistentry> 
    20512057      <varlistentry><term><literal> PROVIDER = ival </literal></term> 
    20522058        
    2053        <listitem><para> Identifiant du noeud of the data provider from which this 
    2054        node draws data.</para></listitem> 
     2059       <listitem><para> Identifiant du noeud fournisseur qui transmet les données 
     2060à ce noeud.</para></listitem> 
    20552061        
    20562062      </varlistentry> 
    20572063      <varlistentry><term><literal> RECEIVER = ival </literal></term> 
    20582064        
    2059        <listitem><para> Identifiant du noeud of the new subscriber</para></listitem> 
     2065       <listitem><para> Identifiant du nouveau noeud abonné</para></listitem> 
    20602066        
    20612067      </varlistentry> 
    20622068      <varlistentry><term><literal> FORWARD = boolean </literal></term> 
    20632069        
    2064        <listitem><para> Flag whether or not the new subscriber should 
    2065          store the log information during replication to make it 
    2066          possible candidate for the provider role for future 
    2067          nodes.</para></listitem> 
     2070       <listitem><para> Indique si le nouvel abonné doit stocker les logs 
     2071pendant la réplication afin de pouvoir devenir fournisseur pour de futurs  
     2072noeuds.</para></listitem> 
    20682073 
    20692074      </varlistentry> 
    20702075     </variablelist> 
    2071     <para> This uses &funsubscribeset;. </para> 
     2076    <para> Cette commande utilise &funsubscribeset;. </para> 
    20722077   </refsect1> 
    20732078   <refsect1><title>Exemple</title> 
    …… 
    20822087   </refsect1> 
    20832088 
    2084    <refsect1> <title> Forwarding Behaviour </title> 
    2085  
    2086     <para> The <command>FORWARD=boolean</command> flag indicates 
    2087     whether the subscriber will store log information in tables 
    2088     &sllog1; and &sllog2;.  Several implications fall from 
    2089     this...</para> 
    2090  
    2091     <para> By storing the data in these tables on the subscriber, 
    2092     there is some additional processing burden.  If you are certain 
    2093     that you would never want to <xref linkend="stmtmoveset"/> or <xref 
    2094     linkend="stmtfailover"/> to a particular subscriber, it is worth 
    2095     considering turning off forwarding on that node.  </para> 
    2096  
    2097     <para> There is, however, a case where having forwarding turned 
    2098     off opens up a perhaps-unexpected failure condition; a rule of 
    2099     thumb should be that <emphasis>all nodes that connect directly to 
    2100     the origin</emphasis> should have forwarding turned on.  Supposing 
    2101     one such <quote>direct subscriber</quote> has forwarding turned 
    2102     off, it is possible for that node to be forcibly lost in a case of 
    2103     failover.  The problem comes if that node gets ahead of other 
    2104     nodes.</para> 
    2105  
    2106     <para> Let's suppose that the origin, node 1 is at SYNC number 
    2107     88901, a non-forwarding node, node 2 has processed up to SYNC 
    2108     88897, and other forwarding nodes, 3, 4, and 5, have only 
    2109     processed data up to SYNC 88895.  At that moment, the disk system 
    2110     on the origin node catches fire.  Node 2 has the 
    2111     <emphasis>data</emphasis> up to SYNC 88897, but there is no 
    2112     remaining node that contains, in &sllog1; or &sllog2;, the data 
    2113     for SYNCs 88896 and 88897, so there is no way to bring nodes 3-5 
    2114     up to that point.</para> 
    2115  
    2116     <para> At that point, there are only two choices: To drop node 2, 
    2117     because there is no way to continue managing it, or to drop all 
    2118     nodes <emphasis>but</emphasis> 2, because there is no way to bring 
    2119     them up to SYNC 88897.</para> 
    2120  
    2121     <para> That dilemma may be avoided by making sure that all nodes 
    2122     directly subscribing to the origin have forwarding turned 
    2123     on. </para> 
    2124  
    2125    </refsect1> 
    2126    <refsect1> <title> Dangerous/Unintuitive Behaviour </title> 
     2089   <refsect1> <title> Transmission  </title> 
     2090 
     2091    <para> Le paramÚtre <command>FORWARD=boolean</command> indique si le 
     2092l'abonné doit conserver les informations dans les tables 
     2093    &sllog1; and &sllog2;.  Ceci implique plusieurs choses...</para> 
     2094 
     2095    <para>Stocker les données dans ces tables sur l'abonné représente 
     2096une charge supplémentaire. Si vous êtes certain(e) que vous n'effectuerez  
     2097jamais les opérations <xref linkend="stmtmoveset"/> ou <xref 
     2098linkend="stmtfailover"/> sur un abonné particulier, il vaut mieux  
     2099désactiver la transmission sur ce noeud.  </para> 
     2100 
     2101    <para> Ceci étant, dans certains cas le fait de désactiver cette option 
     2102peut poser des problÚmes losque l'on se trouve dans une situation inattendue. 
     2103De maniÚre empirique, on considÚre qu'il préférable que <emphasis>tout  
     2104noeud connecté directement à l'origine</emphasis> soit  
     2105un <quote>noeud transmetteur </quote>. Il est possible que ce noeud 
     2106soit perdu lors d'une bascule d'urgence. Le problÚme survient lorsque 
     2107ce noeud est en avance sur les autres noeuds.</para> 
     2108 
     2109    <para> Supposons que l'origine, le noeud 1, est au numéro de SYNC 
     211088901, un noeud non-transmetteur, le noeud 2 en est arrivé au numéro 
     211188897, tandis que les autres noeuds transmetteur, 3, 4, et 5, en sont 
     2112seulement au SYNC numéro  88895.  A ce moment, le disque systÚme sur le 
     2113noeud origine prend feu.  Le noeud 2 possÚde les <emphasis>données</emphasis> à jour  
     2114jusqu'à 88901, mais aucun noeud transmetteur ne dispose, dans les tables 
     2115 &sllog1; ou &sllog2;, des données correspondant 
     2116aux événements SYNCs numérotés 88896 et 88897. Il n'y a donc  
     2117aucun moyen de ramener les noeuds 3-5 à ce niveau.</para> 
     2118 
     2119    <para> À ce stade, vous avez deux choix : supprimer le noeud2, car il 
     2120n'existe aucun moyen de le maintenir, ou supprimer tous les noeuds  
     2121<emphasis>sauf</emphasis> le noeud 2, car il n'existe aucun moyen de les  
     2122amener jusqu'à l'événement SYNC 88897.</para> 
     2123 
     2124    <para> Ce dilemme peut être évité en s'assurant que tous les noeuds directement  
     2125abonnés à l'origine sont des transmetteurs. </para> 
     2126 
     2127   </refsect1> 
     2128   <refsect1> <title> Comportement dangereux et non-intuitif </title> 
    21272129 
    21282130   <itemizedlist> 
    21292131 
    2130      <listitem><para> The fact that the request returns immediately 
    2131      even though the subscription may take considerable time to 
    2132      complete may be a bit surprising. </para>  
    2133  
    2134      <para> Processing of the subscription involves 
    2135      <emphasis>two</emphasis> events; the 
    2136      <command>SUBSCRIBE_SET</command>, initiated from the provider 
    2137      node, and an <command>ENABLE_SUBSCRIPTION</command>, which is 
    2138      initiated on the subscriber node.  This means that <xref 
    2139      linkend="stmtwaitevent"/> cannot directly wait for completion of a 
    2140      subscription.  If you need to wait for completion of a 
    2141      subscription, then what you need to do instead is to submit a 
    2142      <xref linkend="stmtsync"/> request, and wait for 
    2143      <emphasis>that</emphasis> event.</para> 
     2132     <listitem><para> Le fait que la requête se termine immédiatement 
     2133même si l'abonnement prend un temps considérable est parfois surprenant. 
     2134 </para>  
     2135 
     2136     <para> Le traitement des abonnements implique  
     2137     <emphasis>deux</emphasis> événements; l'opération 
     2138     <command>SUBSCRIBE_SET</command>, initié sur le noeud fournisseur, 
     2139et une opération  <command>ENABLE_SUBSCRIPTION</command>, qui est  
     2140initiée sur le noeud abonné. Cela signifie que <xref 
     2141     linkend="stmtwaitevent"/> ne peut pas attendre la fin d'une souscription. 
     2142Si vous souhaitez attendre la fin d'un abonnement, alors vous devez soumettre une 
     2143requête <xref linkend="stmtsync"/> et attendre que <emphasis>cet</emphasis> événement 
     2144s'achÚve.</para> 
    21442145     </listitem> 
    21452146 
    2146      <listitem><para> This command has <emphasis>two</emphasis> 
    2147      purposes; setting up subscriptions (which should be unsurprising) 
    2148      and <emphasis>revising subscriptions</emphasis>, which isn't so 
    2149      obvious to intuition. </para> </listitem> 
    2150  
    2151      <listitem><para> New subscriptions are set up by using 
    2152      <command>DELETE</command> or <command>TRUNCATE</command> to 
    2153      empty the table on a subscriber.  If you created a new node by 
    2154      copying data from an existing node, it might <quote>seem 
    2155      intuitive</quote> that that data should be kept; that is not the 
    2156      case - the former contents are discarded and the node is 
    2157      populated <emphasis>from scratch</emphasis>.</para> </listitem> 
     2147     <listitem><para> Cette commande a <emphasis>deux</emphasis> 
     2148objectifs : mettre en place des abonnements ( ce qui n'est trÚs surprenant ) 
     2149et <emphasis>modifier des abonnements</emphasis>, ce qui n'est pas forcément 
     2150intuitif. </para> </listitem> 
     2151 
     2152 <listitem><para> Les nouveaux abonnements sont définis en utilisant  
     2153<command>DELETE</command> ou <command>TRUNCATE</command> pour vider 
     2154les tables sur l'abonné. Si vous avez créé un nouveau noeud en  
     2155recopiant les données à partir d'un noeud existant, il peut <quote>paraitre 
     2156évident</quote> que ces données seront conservées. Ce n'est pas le cas, 
     2157l'ancien contenu est détruit et le noeud est re-peupler <emphasis>à partir 
     2158de zéro</emphasis>.</para> </listitem> 
    21582159 
    21592160   </itemizedlist> 
    …… 
    21622163   <refsect1> <title> Utilisation de verrous </title> 
    21632164 
    2164     <para> This operation does <emphasis>not</emphasis> require 
    2165     acquiring any locks on the provider node.</para> 
    2166  
    2167     <para> On the subscriber node, it will have the effect of locking 
    2168     every table in the replication set.  In version 1.2, exclusive 
    2169     locks are acquired at the beginning of the process; in earlier 
    2170     versions, locks were acquired implicitly as activity mandated it, 
    2171     which left some risk of deadlock if other applications could 
    2172     access the subscriber database at this time. 
     2165    <para> Cette opération ne nécessite <emphasis>pas</emphasis> de verrous 
     2166sur le noeud fournisseur.</para> 
     2167 
     2168    <para> Sur le noeud abonné, l'opération placera un verrou 
     2169sur toutes les table de l'ensemble de réplication. Dans la version 
     21701.2, les verrous exclusifs sont placés au début du processus; dans les  
     2171versions antérieurs, les verrous sont placés implicitement uniquement lorsque 
     2172qu'une activité le demande, ce qui laisse une possibilité d'inter-blocage 
     2173("deadlock") si d'autres applications peuvent accéder à la base à ce moment là. 
    21732174    </para> 
    21742175   </refsect1> 
    …… 
    21852186   <refnamediv><refname>UNSUBSCRIBE SET</refname> 
    21862187 
    2187     <refpurpose> End replication of &slony1; set </refpurpose></refnamediv> 
     2188    <refpurpose> Arrête la  réplication d'un ensemble de réplication &slony1; </refpurpose></refnamediv> 
    21882189    
    21892190   <refsynopsisdiv> 
    …… 
    21952196    <title>Description</title> 
    21962197 
    2197     <para> Stops the subscriber from replicating the set. The tables 
    2198      are opened up for full access by the client application on the 
    2199      former subscriber. The tables are not truncated or otherwise 
    2200      modified. All original triggers, rules and constraints are 
    2201      restored. 
     2198    <para> Cette commande interrompt la réplication d'un ensemble sur un abonné. 
     2199Les tables sont alors ouvertes en accÚs total aux applications clientes sur l'ancien  
     2200abonné. Les tables ne sont pas détruites, ni modifiées. Tous les triggers originaux, les rÚgles 
     2201et les contraintes sont restaurées. 
    22022202      
    22032203     <variablelist> 
    22042204      <varlistentry><term><literal> ID = ival </literal></term> 
    2205        <listitem><para> ID of the set to unsubscribe</para></listitem> 
     2205       <listitem><para> Identifiant de l'ensemble à désabonner</para></listitem> 
    22062206        
    22072207      </varlistentry> 
    22082208      <varlistentry><term><literal> RECEIVER = ival </literal></term> 
    22092209        
    2210        <listitem><para> Identifiant du noeud of the (former) subscriber</para></listitem> 
     2210       <listitem><para> Identifiant de noeud de l' (ancien) abonné</para></listitem> 
    22112211        
    22122212      </varlistentry> 
    22132213     </variablelist> 
    22142214    </para> 
    2215     <para> This uses &fununsubscribeset;. </para> 
     2215    <para> Cette commande utilise &fununsubscribeset;. </para> 
    22162216   </refsect1> 
    22172217   <refsect1><title>Exemple</title> 
    …… 
    22252225   <refsect1> <title> Utilisation de verrous </title> 
    22262226 
    2227     <para> Exclusive locks on each replicated table will be taken out 
    2228     on the subscriber in order to drop replication triggers from the 
    2229     tables and restore other triggers/rules. </para> 
    2230    </refsect1> 
    2231  
    2232    <refsect1><title> Dangerous/Unintuitive Behaviour </title> 
    2233  
    2234      <para> Resubscribing an unsubscribed set requires a 
    2235      <emphasis>complete fresh copy</emphasis> of data from the 
    2236      provider to be transferred since the tables have been subject to 
    2237      possible independent modifications.  </para> 
     2227    <para> Des verrous exclusifs sont posés sur chaque table répliquées 
     2228de l'abonné afin de supprimer les triggers de réplication et de restaurer  
     2229les anciens triggers/rÚgles. </para> 
     2230   </refsect1> 
     2231 
     2232   <refsect1><title> Comportement dangereux et non-intuitif </title> 
     2233 
     2234     <para> Ré-abonner un ensemble désabonné nécessite une  
     2235     <emphasis>copie fraîche et complÚte</emphasis> des données obtenue à partir 
     2236du noeud fournisseur, car les tables ont pu être soumises à des modifications 
     2237indépendantes.  </para> 
    22382238 
    22392239   </refsect1> 
    …… 
    22512251   <refnamediv><refname>LOCK SET</refname> 
    22522252     
    2253     <refpurpose> Guard &slony1; replication 
    2254     set to prepare for <command>MOVE SET</command> 
     2253    <refpurpose> ProtÚge un ensemble de réplication &slony1; pour le  
     2254préparer à un <command>MOVE SET</command> 
    22552255    </refpurpose></refnamediv> 
    22562256   <refsynopsisdiv> 
    …… 
    22622262    <title>Description</title> 
    22632263     
    2264     <para> Guards a replication set against client application updates 
    2265     in preparation for a <xref linkend="stmtmoveset"/> command. 
    2266     </para> 
    2267  
    2268     <para> This command must be the first in a possible statement 
    2269     group (<command>try</command>).  The reason for this is that it 
    2270     needs to commit the changes made to the tables (adding a special 
    2271     trigger function) before it can wait for every concurrent 
    2272     transaction to finish. At the same time it cannot hold an open 
    2273     transaction to the same database itself since this would result in 
    2274     blocking itself forever.</para> 
    2275  
    2276     <para> Note that this is a &rlocking; operation, which means that 
    2277     it can get stuck behind other database activity.</para> 
    2278  
    2279     <para> The operation waits for transaction IDs to advance in order 
    2280     that data is not missed on the new origin.  Thus, if you have 
    2281     long-running transactions running on the source node, this 
    2282     operation will wait for those transactions to complete. 
    2283     Unfortunately, if you have another database on the same postmaster 
    2284     as the origin node, long running transactions on that database 
    2285     will also be considered even though they are essentially 
    2286     independent. 
     2264    <para> Cette commande protÚge un ensemble de réplication des mises à  
     2265jour en provenance des applications clientes, en préparation d'une  
     2266commande <xref linkend="stmtmoveset"/>. 
     2267    </para> 
     2268 
     2269    <para> Cette commande doit être la premiÚre dans un groupe de commande <command>try</command>. 
     2270En effet, il faut <quote>committer</quote> les changements faits sur les tables 
     2271 (ajout d'une fonction trigger speciale) avant d'attendre que toutes les  
     2272transactions concurrentes se termine. En même temps, il ne faut pas 
     2273non plus garder une transaction ouverte sur la base elle-même car cela 
     2274cela signifierait qu'elle se bloque elle-même. 
     2275    </para> 
     2276 
     2277    <para> Notons qu'il s'agit d'un opération &rlocking;, ce qui signifie qu'elle peut être 
     2278bloquer derriÚre d'autres activités de la base.</para> 
     2279 
     2280    <para> L'opération attend que les identifiants de transaction avancent 
     2281afin qu'aucune donnée ne soient oubliées sur la nouvelle origine. Ainsi 
     2282si vous avez des transactions trÚs longues en cours sur le noeud source,  
     2283cette opération attendra que ces transactions aboutissent. 
     2284Malheureusement , si vous avez une autre base de données sur le même  
     2285    postmaster du noeud origine, les transactions longues en cours 
     2286sur cette base seront aussi prises en compte même si elles sont par définition 
     2287indépendantes. 
    22872288      
    22882289     <variablelist> 
    22892290      <varlistentry><term><literal> ID = ival </literal></term> 
    2290        <listitem><para> ID of the set to lock</para></listitem> 
     2291       <listitem><para> Identifiant de l'ensemble à bloquer</para></listitem> 
    22912292          
    22922293      </varlistentry> 
    …… 
    24332434     </variablelist> 
    24342435    </para> 
    2435     <para> This uses &funmoveset;. </para> 
     2436    <para> Cette commande utilise &funmoveset;. </para> 
    24362437   </refsect1> 
    24372438   <refsect1><title>Exemple</title> 
    …… 
    24502451   <refsect1> <title> Utilisation de verrous </title> 
    24512452 
    2452     <para> Exclusive locks on each replicated table will be taken out 
    2453     on both the old origin node and the new origin node, as 
    2454     replication triggers are changed on both nodes: on the former 
    2455     origin, each table has two triggers (logtrigger and lockset) 
    2456     dropped and a denyaccess trigger added; on the new origin, the 
    2457     denyaccess trigger is dropped and a logtrigger trigger 
    2458     added. </para> 
     2453    <para> Des verrous exclusifs sont posés sur chaque table répliquée 
     2454à la fois sur l'ancien noeud origine et le nouveau noeud origine, car  
     2455les triggers de réplication sont changés sur les deux noeuds : 
     2456sur l'ancienne origine, chaque table supprime deux triggers  
     2457(logtrigger et lockset) et ajoute un trigger denyaccess; 
     2458sur la nouvelle origine, le trigger denyaccess est supprimé et 
     2459le trigger logtrigger est ajouté. </para> 
    24592460   </refsect1> 
    24602461   <refsect1> <title> Note de version </title> 
    …… 
    24702471   <refnamediv><refname>FAILOVER</refname> 
    24712472     
    2472     <refpurpose> Fail a broken replication set over to a backup node 
     2473    <refpurpose> Cette commande bascule un ensemble de réplication  
     2474en échec vers un noeud de secours. 
    24732475    </refpurpose></refnamediv> 
    24742476   <refsynopsisdiv> 
    …… 
    24812483     
    24822484    <para> 
    2483      The <command>FAILOVER</command> command causes the backup node to take over all sets 
    2484      that currently originate on the failed 
    2485      node. <application>slonik</application> will contact all other 
    2486      direct subscribers of the failed node to determine which node has 
    2487      the highest sync status for each set. If another node has a 
    2488      higher sync status than the backup node, the replication will 
    2489      first be redirected so that the backup node replicates against 
    2490      that other node, before assuming the origin role and allowing 
    2491      update activity. 
    2492     </para> 
    2493  
    2494     <para> 
    2495      After successful failover, all former direct subscribers of the 
    2496      failed node become direct subscribers of the backup node. The 
    2497      failed node is abandoned, and can and should be removed from the 
    2498      configuration with <xref linkend="stmtdropnode"/>. 
     2485     La commande <command>FAILOVER</command> transfert tous les ensembles dont 
     2486l'origine est en panne vers le noeud de secours. 
     2487     <application>slonik</application> va contacter tous les autres noeuds directement 
     2488abonnés au noeud en panne pour déterminer quel noeud à le meilleur niveau de synchronisation 
     2489pour chacun des ensembles de réplication. Si un autre noeud a un niveau de synchronisation 
     2490plus élévé que le noeud de secours, la réplication sera d'abord redirigée pour que le noeud 
     2491de secours rattrape son retard sur l'autre noeud, puis qu'il assume le role d'origine 
     2492et reçoive les mises à jour. 
     2493    </para> 
     2494 
     2495    <para> 
     2496     AprÚs une bascule d'urgence réussie, tous les anciens noeuds abonnés directement  
     2497au noeud en panne deviennent des abonnés direct du noeud de secours. 
     2498Le noeud en panne est abandonné, et doit être retiré de la configuration avec  
     2499<xref linkend="stmtdropnode"/>. 
    24992500    </para> 
    25002501     
    25012502    <variablelist> 
    25022503     <varlistentry><term><literal> ID = ival </literal></term> 
    2503       <listitem><para> ID of the failed node</para></listitem> 
     2504      <listitem><para> Identifiant du noeud en panne</para></listitem> 
    25042505       
    25052506     </varlistentry> 
    25062507     <varlistentry><term><literal> BACKUP NODE = ival </literal></term> 
    25072508       
    2508       <listitem><para> Identifiant du noeud of the node that will take over all 
    2509       sets originating on the failed node</para></listitem> 
     2509      <listitem><para> Identifiant du noeud de secours qui va prendre en charge 
     2510les ensembles de réplication dont l'origine est le noeud en panne</para></listitem> 
    25102511 
    25112512     </varlistentry> 
    25122513    </variablelist> 
    25132514     
    2514     <para> This uses &funfailednode;. </para> 
     2515    <para> Cette commande utilise &funfailednode;. </para> 
    25152516   </refsect1> 
    25162517   <refsect1><title>Exemple</title> 
    …… 
    25242525   <refsect1> <title> Utilisation de verrous </title> 
    25252526 
    2526     <para> Exclusive locks on each replicated table will be taken out 
    2527     on both the new origin node as replication triggers are changed. 
    2528     If the new origin was not completely up to date, and replication 
    2529     data must be drawn from some other node that is more up to date, 
    2530     the new origin will not become usable until those updates are 
    2531     complete. </para> 
    2532    </refsect1> 
    2533    <refsect1><title> Dangerous/Unintuitive Behaviour </title> 
    2534     <para> This command will abandon the status of the failed 
    2535     node.  There is no possibility to let the failed node join the 
    2536     cluster again without rebuilding it from scratch as a slave.  If 
    2537     at all possible, you would likely prefer to use <xref 
    2538     linkend="stmtmoveset"/> instead, as that does 
    2539     <emphasis>not</emphasis> abandon the failed node. 
     2527    <para> Des verrous exclusifs sont posés sur chaque table répliquée sur 
     2528le nouveau noeud origine, car les triggers de réplication sont changés. 
     2529Si la nouvelle origine n'est pas tout à fait à jour, et que des données  
     2530doivent être rapatriées depuis à partir d'un autre noeud qui est mieux synchronisé, 
     2531alors la nouvelle origine ne sera pas utilisable avant que ces mises à jour 
     2532soient terminées. 
     2533     </para> 
     2534   </refsect1> 
     2535   <refsect1><title> Comportement dangerous et non-intuitif </title> 
     2536    <para> Cette commande va abandonner le noeud en panne. 
     2537Il n'y a pas de possibilité de réintégrer le noeud en panne, 
     2538sans le reconstruire à partir de zéro en tant qu'esclave. 
     2539Si c'est possible, il est préférable d'utiliser la commande  
     2540     <xref linkend="stmtmoveset"/> , car elle n'abandonne 
     2541    <emphasis>pas</emphasis> le noeud en panne. 
    25402542    </para> 
    25412543   </refsect1> 
    …… 
    25522554   <refnamediv><refname>EXECUTE SCRIPT</refname> 
    25532555     
    2554     <refpurpose> Execute SQL/DDL script  </refpurpose></refnamediv> 
     2556    <refpurpose> Éxecute un script SQL/DDL  </refpurpose></refnamediv> 
    25552557   <refsynopsisdiv> 
    25562558    <cmdsynopsis> 
    …… 
    25612563    <title>Description</title> 
    25622564     
    2563     <para> Executes a script containing arbitrary SQL statements on 
    2564      all nodes that are subscribed to a set at a common controlled 
    2565      point within the replication transaction stream.</para> 
    2566      
    2567     <para> The specified event origin must be the origin of the set. 
    2568     The script file must not contain any <command>START</command> or 
    2569     <command>COMMIT TRANSACTION</command> calls.  (This changes 
    2570     somewhat in &postgres; 8.0 once nested transactions, aka 
    2571     savepoints, are supported) In addition, non-deterministic DML 
    2572     statements (like updating a field with 
    2573     <function>CURRENT_TIMESTAMP</function>) must be avoided, since the 
    2574     data changes done by the script are explicitly not 
    2575     replicated. </para> 
     2565    <para> Cette commande éxecutes un script contenant de ordres SQL sur  
     2566tous les noeufs qui sont abonnés à un ensemble de réplication à un  
     2567point précis dans le flux des transactions.</para> 
     2568    OA 
     2569    <para> L'origine de l'événement doit être l'origine de l'ensemble 
     2570de réplication. Le fichier de script ne doit pas contenir d'ordres  
     2571<command>START</command> ou <command>COMMIT TRANSACTION</command>. 
     2572  (Ceci change un peu avec &postgres; 8.0 puisque les transactions imbriquées, 
     2573appelée également <quote>points de sauvegarde</quote> (<quote> 
     2574    savepoints</quote>, sont supportés. 
     2575De plus les ordres DML non déterministes (par exemple mettre a jour un  
     2576champs avec la valeur  <function>CURRENT_TIMESTAMP</function>) doivent 
     2577être évitées, car les changements effectués par ce script ne sont pas 
     2578explicitement répliqués. </para> 
    25762579 
    25772580    <variablelist> 
    25782581     <varlistentry><term><literal> SET ID = ival </literal></term> 
    25792582 
    2580       <listitem><para> The unique numeric ID number of the set 
    2581       affected by the script</para></listitem> 
     2583      <listitem><para> Le numéro unique de l'ensemble affecté par le script</para></listitem> 
    25822584       
    25832585     </varlistentry> 
    2584      <varlistentry><term><literal> FILENAME = '/path/to