Changeset 1047

Show
Ignore:
Timestamp:
05/27/08 20:45:53 (6 months ago)
Author:
daamien
Message:

best practices, 1ere traduction, xml à vérifier

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/bestpractices.xml

    r969 r1047  
    2222et de votre maniÚre d'utiliser ces serveurs.</para> 
    2323 
    24 <para> Il ya toutefois, un certain nombre de choses que les pioniers de &slony1; ont 
     24<para> Il y a toutefois, un certain nombre de choses que les pionniers de &slony1; ont 
    2525  découvertes qui peuvent au moins aider à concevoir le genre de rÚgles d'administration 
    2626  que vous pourriez mettre en place. </para> 
    …… 
    3333où des problÚmes peuvent surgir.</para>  
    3434 
    35 <para> c'est donc naturellement que la maintenance d'un environement propre, cohérent 
     35<para> c'est donc naturellement que la maintenance d'un environnement propre, cohérent 
    3636 est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement 
    3737 peut provoquer des problÚmes ou masquer le problÚme réel. </para> 
    …… 
    7171<para> Les utilisateurs ont rencontrés des problÚmes pour faire fonctionner 
    7272  &lslon; correctement lorsque leur systÚme utilisait une zone de temps que  
    73   &postgres; ne pouvait pas reconnaitre tel que CUT0 ou WST. Il est nécessaire 
     73  &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est nécessaire 
    7474  que vous utilisiez une zone de temps que &postgres; reconnaît correctement. 
    7575  De plus, il est préférable d'utiliser une zone qui n'est pas soumise au  
    …… 
    7878<para> Le choix <quote>géographiquement neutre</quote> semble être 
    7979 <command><envar>TZ</envar>=UTC</command> ou 
    80 <command><envar>TZ</envar>=GMT</command>, par ailleurs assurez-vous que  
    81 vos serveurs sont <quote>synchronisés</quote> grace à l'utilisation  
     80<command><envar>TZ</envar>=GMT</command>, par ailleurs Assurez-vous que  
     81vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation  
    8282de NTP sur l'ensemble de votre environnement. </para> 
    8383 
    …… 
    106106 
    107107<listitem><para> Le systÚme va périodiquement faire une rotation (en utilisant  
    108   <command>TRUNCATE</command> pour nettoyer l'anccienne table) entre les deux tables de logs, 
     108  <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les deux tables de logs, 
    109109   <xref linkend="table.sl-log-1"/> et <xref 
    110110linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit.  </para></listitem> 
    …… 
    118118 
    119119<para> Cela peut simplement se résumer à réfléchir à une liste 
    120   de priorité indiquant ce qui devrait basculer vers quoi, plutot  
     120  de priorité indiquant ce qui devrait basculer vers quoi, plutÃŽt  
    121121  que d'essayer d'automatiser la bascule. Quoiqu'il en soit savoir 
    122   au prélable ce qu'il faut faire réduit le nombre d'erreurs commises. 
     122  au préalable ce qu'il faut faire réduit le nombre d'erreurs commises. 
    123123  </para> 
    124124 
    …… 
    132132</listitem> 
    133133 
    134 <listitem><para> <xref linkend="stmtmoveset"/> should be used to allow 
    135 preventative maintenance to prevent problems from becoming serious 
    136 enough to require <link linkend="failover"> failover </link>. </para> 
    137 </listitem> 
    138  
    139 <listitem> <para> <command>VACUUM</command> policy needs to be 
    140 carefully defined.</para> 
    141  
    142 <para> As mentioned above, <quote>long running transactions are 
    143 Evil.</quote> <command>VACUUM</command>s are no exception in this.  A 
    144 <command>VACUUM</command> on a huge table will open a long-running 
    145 transaction with all the known ill effects.</para> 
    146 </listitem> 
    147  
    148 <listitem><para> If you are using the autovacuum process in recent 
    149 versions of &postgres;, you may wish to leave &slony1; tables out, as 
    150 &slony1; is a bit more intelligent about vacuuming when it is expected 
    151 to be conspicuously useful (<emphasis>e.g.</emphasis> - immediately 
    152 after purging old data) to do so than autovacuum can be. </para> 
    153  
    154 <para> See <xref linkend="maintenance-autovac"/> for more 
    155 details. </para> </listitem> 
    156  
    157  
    158 <listitem> <para> Running all of the &lslon; daemons on a central 
    159 server for each network has proven preferable. </para> 
    160  
    161 <para> Each &lslon; should run on a host on the same local network as 
    162 the node that it is servicing, as it does a <emphasis>lot</emphasis> 
    163 of communications with its database, and that connection needs to be 
    164 as reliable as possible.  </para> 
    165  
    166 <para> In theory, the <quote>best</quote> speed might be expected to 
    167 come from running the &lslon; on the database server that it is 
    168 servicing. </para> 
    169  
    170 <para> In practice, strewing &lslon; processes and configuration 
    171 across a dozen servers turns out to be inconvenient to manage.</para> 
    172 </listitem> 
    173  
    174 <listitem><para> &lslon; processes should run in the same 
    175 <quote>network context</quote> as the node that each is responsible 
    176 for managing so that the connection to that node is a 
    177 <quote>local</quote> one.  Do <emphasis>not</emphasis> run such links 
    178 across a WAN. </para> 
    179  
    180 <para> A WAN outage can leave database connections 
    181 <quote>zombied</quote>, and typical TCP/IP behaviour <link 
    182 linkend="multipleslonconnections"> will allow those connections to 
    183 persist, preventing a slon restart for around two hours. </link> 
    184 </para> 
    185  
    186 <para> It is not difficult to remedy this; you need only <command>kill 
    187 SIGINT</command> the offending backend connection.  But by running the 
    188 &lslon; locally, you will generally not be vulnerable to this 
    189 condition. </para> 
    190 </listitem> 
    191  
    192 <listitem><para> Before getting too excited about having fallen into 
    193 some big problem, consider killing and restarting all the &lslon; 
    194 processes.  Historically, this has frequently been able to 
    195 resolve <quote>stickiness.</quote> </para> 
    196  
    197 <para> With a very few exceptions, it is generally not a big deal to 
    198 kill off and restart the &lslon; processes.  Each &lslon; connects to 
    199 one database for which it is the manager, and then connects to other 
    200 databases as needed to draw in events.  If you kill off a &lslon;, all 
    201 you do is to interrupt those connections.  If 
    202 a <command>SYNC</command> or other event is sitting there 
    203 half-processed, there's no problem: the transaction will roll back, 
    204 and when the &lslon; restarts, it will restart that event from 
    205 scratch.</para> 
    206  
    207 <para> The exception, where it is undesirable to restart a &lslon;, is 
    208 where a <command>COPY_SET</command> is running on a large replication 
    209 set, such that stopping the &lslon; may discard several hours worth of 
    210 load work. </para> 
    211  
    212 <para> In early versions of &slony1;, it was frequently the case that 
    213 connections could get a bit <quote>deranged</quote> which restarting 
    214 &lslon;s would clean up.  This has become much more rare, but it has 
    215 occasionally proven useful to restart the &lslon;.  If there has been 
    216 any <quote>network derangement</quote>, this can clear up the issue of 
    217 defunct database connections.  </para> </listitem> 
    218  
    219 <listitem> 
    220 <para>The <link linkend="ddlchanges"> Database Schema Changes </link> 
    221 section outlines some practices that have been found useful for 
    222 handling changes to database schemas. </para></listitem> 
    223  
    224 <listitem> 
    225 <para> Handling of Primary Keys </para>  
    226  
    227 <para> Discussed in the section on <link linkend="definingsets"> 
    228 Replication Sets, </link> it is <emphasis>ideal</emphasis> if each 
    229 replicated table has a true primary key constraint; it is 
    230 <emphasis>acceptable</emphasis> to use a <quote>candidate primary 
    231 key.</quote></para> 
    232  
    233 <para> It is <emphasis>not recommended</emphasis> that a 
    234 &slony1;-defined key (created via <xref linkend="stmttableaddkey"/>) be 
    235 used to introduce a candidate primary key, as this introduces the 
    236 possibility that updates to this table can fail due to the introduced 
    237 unique index, which means that &slony1; has introduced a new failure 
    238 mode for your application.</para> 
    239  
    240  
    241 <warning><para> In version 2 of &slony1;, <xref 
    242 linkend="stmttableaddkey"/> is no longer supported.  You 
    243 <emphasis>must</emphasis> have either a true primary key or a 
    244 candidate primary key.  </para></warning> 
    245 </listitem> 
    246  
    247 <listitem> 
    248 <para> <link linkend="definesets"> Grouping tables into sets 
    249 </link> suggests strategies for determining how to group tables and 
    250 sequences into replication sets. </para> 
    251 </listitem> 
    252  
    253 <listitem> 
    254 <para> It should be obvious that actions that can delete a 
    255 lot of data should be taken with great care; the section on <link 
    256 linkend="dropthings"> Dropping things from &slony1; Replication</link> 
    257 discusses the different sorts of <quote>deletion</quote> that &slony1; 
    258 supports.  </para> 
    259 </listitem> 
    260  
    261 <listitem> 
    262 <para> <link linkend="Locking"> Locking issues </link></para> 
    263  
    264 <para> Certain &slony1; operations, notably <link 
     134<listitem><para> <xref linkend="stmtmoveset"/> doit être utliséￜ pour 
     135la maintenance préventive afin d'éviter l'apparition des 
     136problÚmes nécessitant une <link linkend="failover"> 
     137bascule aprÚs panne ("failover") </link>. </para> 
     138</listitem> 
     139 
     140<listitem> <para> La politique de <command>VACUUM</command> doit être  
     141définie avec soin.</para> 
     142 
     143<para> Comme indiqué précédemment, <quote>les transactions longues sont maléfiques.</quote>  
     144  La commande <command>VACUUM</command> n'est pas une exception à cette rÚgle. 
     145  Un <command>VACUUM</command> sur une grande table ouvrira une transaction longue 
     146  qui aura tous les effets négatifs déjà cités.</para> 
     147</listitem> 
     148 
     149<listitem><para> Si vous utiliser le processus autovacuum process avec une 
     150    version récente de &postgres;, vous pouvez éviter de le faire pour les tables &slony1;  
     151    car &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il s'agit de  
     152    vacuum dans des conditions de réplication ( <emphasis>par exemple</emphasis> : la purge 
     153    des anciennes données ).</para> 
     154 
     155<para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de  
     156détails. </para> </listitem> 
     157 
     158 
     159<listitem> <para> Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;  
     160    sur un serveur central pour chaque sous-réseau. </para> 
     161 
     162<para> Chaque &lslon; doit être hébergé par hÃŽte sur le même réseau local que  
     163  le noeud qu'il opÚre, car il envoie <emphasis>beaucoup</emphasis> de  
     164  communications avec sa base de donnée et que la connexion doit être aussi fiable  
     165  que possible.</para> 
     166 
     167<para> En théorie, les <quote>meilleures</quote> performances sont prévues lorsque 
     168  le &lslon; fonctionne sur le même serveur que la base qu'il opÚre. </para> 
     169 
     170<para> En pratique, déployer les processus &lslon; processes et leur configuration 
     171  à travers un réseau d'une douzaine de serveurs se révÚle être difficilement gérable.</para> 
     172</listitem> 
     173 
     174<listitem><para>Les processus &lslon; doivent évoluer dans le même 
     175    <quote>contexte réseau</quote> que le noeud qu'il opÚre, afin que la  
     176    liaison entre eux soir une connexion <quote>locale</quote>.   
     177    N'établissez <emphasis>pas</emphasis> ce genre de liaison à  
     178    travers un réseau WAN. </para> 
     179 
     180<para> Une coupure de lien WAN  peut provoquer des connexions 
     181  <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à  
     182  <link linkend="multipleslonconnections"> laisser ces connexions persister, 
     183    empêchant le démon slon de redémarrer pendant environ deux heures. </link> 
     184</para> 
     185 
     186<para> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les 
     187  processus liés aux connexions persistantes avec la commande <command>kill 
     188SIGINT</command>. Cependant en exécutant  les &lslon; localement, vous êtes 
     189généralement à l'abri de ce genre de problÚmes. </para> 
     190</listitem> 
     191 
     192<listitem><para> Si vous rencontrez ce genre de problÚmes, avant de vous exciter, 
     193    essayez de tuer et redémarrer tous les processus &lslon;.  
     194    Historiquement, cette méthode a souvent résolu ce genre de  
     195    <quote>petit tracas.</quote>.</para> 
     196 
     197<para>A quelques rares exceptions, il n'est pas trÚs grave de tuer et relancer les  
     198  processus &lslon;. Chaque &lslon; se connecte à la base de données qu'il gÚre, puis  
     199  ouvre les connexions nécessaires à la propagation des événements. 
     200  Si vous tuer un &lslon;, vous provoquez simplement l'interruption de ces connexions. 
     201  Si un évÚnement <command>SYNC</command> ou un autre événement est en cours de propagation, 
     202  il n'y a pas de problÚme : la transaction sera annulée ("roll back") et lorsque le &lslon;  
     203  sera relancé, l'évÚnement sera retraiter à partir de zéro.</para> 
     204 
     205<para> L'exception qui rend un redémarrage de &lslon; indésirable est le cas 
     206  où une commande <command>COPY_SET</command> est en cours d'exécution sur un 
     207  grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon; peut 
     208  annuler plusieurs heures de travail. </para> 
     209 
     210<para> Dans les premiÚres versions de &slony1;, il était fréquent que  
     211  des connexions soient un peu <quote>dérangée</quote>, ce qu'on pouvait 
     212  réparer en redémarrant &lslon;.  Ceci est devenu nettement plus rare, 
     213  mais il est parfois utile de redémarrer &lslon;.  En cas de   
     214  <quote>panne réseau</quote>, cela peut résoudre le problÚme des 
     215  connexions à la base défuntes.  </para> </listitem> 
     216 
     217<listitem> 
     218<para>La section sur les <link linkend="ddlchanges">changements de modÚle de données</link> 
     219détaille quelques bonnes pratiques qui sont utiles lorsque l'on souhaite modifier le 
     220schémas de la base de données. </para></listitem> 
     221 
     222<listitem> 
     223<para> Gestion des clefs primaires </para>  
     224 
     225<para> Comme précisé dans la section <link linkend="definingsets"> 
     226Ensembles de réplication</link>, il est <emphasis>idéal</emphasis> que  
     227chaque table répliquée dispose d'un vraie contrainte de clef primaire; 
     228il est <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire  
     229  candidate.</quote></para> 
     230 
     231<para> Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie  
     232  par &slony1; (crée par <xref linkend="stmttableaddkey"/>) pour 
     233  proposer une clef primaire candidate, car cela introduit la possibilité 
     234  d'échecs de certaines mises à jour sur la table à cause de l'index unique de cette 
     235  clef. Ceci entraînerait potentiellement des bugs dans votre application à cause  
     236  de &slony1;.</para> 
     237 
     238 
     239<warning><para> Dans la version 2 de &slony1;, <xref 
     240linkend="stmttableaddkey"/> n'est plus supportée. Vous <emphasis>devez</emphasis> absolument 
     241    avoir soit une vraie clef primaire, soit une clef primaire candidate.</para></warning> 
     242</listitem> 
     243 
     244<listitem> 
     245<para> La section <link linkend="definesets"> Définir les ensembles de réplication 
     246</link> vous suggÚre des stratégies pour déterminer comment regrouper les tables  
     247et les séquences en ensembles de réplication. </para> 
     248</listitem> 
     249 
     250<listitem> 
     251<para> Il est évident que les actions qui peuvent supprimer beaucoup  
     252  de données doivent être effectuées avec le plus grand soin; La section  
     253  <link 
     254linkend="dropthings">Supprimer des éléments de la réplication</link> 
     255évoque les différentes sortes de <quote>suppression</quote> que &slony1; 
     256supporte.  </para> 
     257</listitem> 
     258 
     259<listitem> 
     260<para> <link linkend="Locking">ProblÚmes d'inter-blocages</link></para> 
     261 
     262<para> Certaines opérations &slony1;, notament <link 
    265263linkend="stmtsetaddtable"> <command>set add table</command> </link>, 
    266264<link linkend="stmtmoveset"> <command> move set</command> </link>, 
    267265<link linkend="stmtlockset"> <command> lock set </command> </link>, 
    268 and <link linkend="stmtddlscript"> <command>execute script</command> 
    269 </link> require acquiring <emphasis>exclusive locks</emphasis> on the 
    270 tables being replicated. </para> 
    271  
    272 <para> Depending on the kind of activity on the databases, this may or 
    273 may not have the effect of requiring a (hopefully brief) database 
    274 outage. </para> 
    275 </listitem> 
    276  
    277 <listitem><para> What to do about DDL. </para> 
    278  
    279 <para> &slony1; operates via detecting updates to table data via 
    280 triggers that are attached to those tables.  That means that updates 
    281 that take place via methods that do not fire triggers will not notice 
    282 those updates.  <command>ALTER TABLE</command>, <command>CREATE OR 
    283 REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, all 
    284 represent SQL requests that &slony1; has no way to notice. </para> 
    285  
    286 <para> A philosophy underlying &slony1;'s handling of this is that 
    287 competent system designers do not write self-modifying code, and 
    288 database schemas that get modified by the application are an instance 
    289 of this.  It does not try hard to make it convenient to modify 
    290 database schemas. </para> 
    291  
    292 <para> There will be cases where that is necessary, so the <link 
    293 linkend="stmtddlscript"> <command>execute script</command> is provided 
    294 which will apply DDL changes at the same location in the transaction 
    295 stream on all servers.  </link> </para> 
    296  
    297 <para> Unfortunately, this introduces a great deal of locking of 
    298 database objects.  Altering tables requires taking out an exclusive 
    299 lock on them; doing so via <command>execute script</command> requires 
    300 that &slony1; take out an exclusive lock on <emphasis>all</emphasis> 
    301 replicated tables.  This can prove quite inconvenient when 
    302 applications are running; you run into deadlocks and such. </para> 
    303  
    304 <para> One particularly dogmatic position that some hold is that 
    305 <emphasis>all</emphasis> schema changes should 
    306 <emphasis>always</emphasis> be propagated using <command>execute 
    307 script</command>.  This guarantees that nodes will be consistent, but 
    308 the costs of locking and deadlocking may be too high for some 
    309 users.</para> 
    310  
    311 <para> At Afilias, our approach has been less dogmatic; there 
    312 <emphasis>are</emphasis> sorts of changes that 
    313 <emphasis>must</emphasis> be applied using <command>execute 
    314 script</command>, but we apply others independently.</para> 
    315  
    316 <itemizedlist> 
    317 <listitem><para> Changes that must be applied using <command>execute script</command> </para> 
    318 <itemizedlist> 
    319 <listitem><para> All instances of <command>ALTER TABLE</command></para></listitem> 
    320 </itemizedlist> 
    321  
    322 </listitem> 
    323 <listitem><para> Changes that are not normally applied using <command>execute script</command> </para> 
     266et <link linkend="stmtddlscript"> <command>execute script</command> 
     267</link> nécessite l'acquisition de <emphasis>verrous exclusifs</emphasis> sur les  
     268tables répliquées.</para> 
     269 
     270<para> En fonction de type d'activité de votre base de données, cela 
     271  peut ( ou pas ) provoquer des coupures de services ( heureusement assez brÚves ). </para> 
     272</listitem> 
     273 
     274<listitem><para> Que faire des ordres DDL ? </para> 
     275 
     276<para> &slony1; fonctionne en détectant les mises à jour sur les tables 
     277  grâce à des triggers qui sont placés sur ces tables. 
     278  Cela implique que les mises à jours que sont font au moyen de 
     279  méthodes qui ne déclenche pas les triggers ne seront pas propagées. 
     280  Les commandes <command>ALTER TABLE</command>, <command>CREATE OR 
     281REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, sont toutes  
     282des requêtes SQL que &slony1; ne peut pas détecter. </para> 
     283 
     284<para> Pour ce genre de situation, la philosophie de &slony1; 
     285  consiste à considérer que les développeurs compétents n'écrivent 
     286  jamais de code auto-modifiant et en particulier du code modifiant  
     287  les modÚles de données à la volée. &slony1; ne cherche pas à faciliter  
     288  ce genre de modification du schémas de données. </para> 
     289 
     290<para> Cependant il existe des cas où cela est nécessaire, ainsi la <link 
     291linkend="stmtddlscript"> <command>execute script</command> est fournie 
     292    pour appliquer des changements DDL au même point dans  
     293    le flux de transactions sur tous les serveurs.</link> </para> 
     294 
     295<para> Malheureusement, cela provoque de nombreux verrous sur  
     296  les objets de la base de données. Modifier les tables nécessite  
     297  de l'acquisition d'un verrou exclusif sur ces objets; ainsi le  
     298  <command>script d'exécution des modification</command> entraîne 
     299  un verrous exclusif sur <emphasis>toutes</emphasis> les tables 
     300  répliquées. Cela peut s'avérer trÚs problématiques lorsque les  
     301  applications fonctionnent; des inter-blocages ("deadlocks") peuvent 
     302  alors se produire.</para> 
     303 
     304<para> Une position particuliÚrement dogmatique défendue par certains 
     305  consiste à dire qu'il faut <emphasis>toujours</emphasis> propager 
     306  les changements de modÚles de données avec un <command>script d'exécution</command>. 
     307  Cela garantit que les noeuds restent consistants, cependant le coût des verrous 
     308  et des inter-blocages est trop élevé pour certains utilisateurs.</para> 
     309 
     310<para> Chez Afilias, notre approche est moins dogmatique; il y a  
     311<emphasis>certains</emphasis> changements qui  
     312<emphasis>doivent</emphasis> être appliquées avec un <command>script d'exécution</command>,  
     313mais nous appliquons certaines modification de maniÚre indépendante.</para> 
     314 
     315<itemizedlist> 
     316<listitem><para> Liste de changements qui doivent être effectuée dans un <command>script d'exécution</command> :</para> 
     317<itemizedlist> 
     318<listitem><para> Toutes les commandes <command>ALTER TABLE</command></para></listitem> 
     319</itemizedlist> 
     320 
     321</listitem> 
     322<listitem><para> Listes des changement qui ne nécessitent pas un <command>script d'exécution :</command> </para> 
    324323<itemizedlist> 
    325324<listitem><para> <command>CREATE INDEX</command> </para></listitem> 
    326325<listitem><para> <command>CREATE TABLE</command> </para> 
    327 <para> Tables that are not being replicated do not require &slony1; <quote>permission</quote>. </para></listitem> 
     326<para> Les tables qui ne sont pas répliquées n'ont pas besoin de ces  
     327  mécanismes. </para></listitem> 
    328328 
    329329<listitem><para> <command>CREATE OR REPLACE FUNCTION </command> </para> 
    330330 
    331 <para> Typically, new versions of functions may be done without 
    332 &slony1; being <quote>aware</quote> of them.  The obvious exception is 
    333 when a new function is being deployed to accomodate a table 
    334 alteration; in that case, the new version must be added in in a manner 
    335 synchronized with the <command>execute script</command> for the table 
    336 alteration. </para> 
    337  
    338 <para> Similarly, <command>CREATE TYPE</command>, <command> CREATE 
    339 AGGREGATE </command>,  and such will 
    340 commonly not need to be forcibly applied in <quote>perfectly 
    341 synchronized</quote> manner across nodes. </para></listitem> 
    342  
    343 <listitem><para> Security management, such as <command> CREATE USER 
     331<para> Typiquement, le chargement de nouvelles version de fonctions  
     332  peut être effectuée sans que &slony1; en soit <quote>averti</quote>. 
     333  A l'exception évidente des cas où la nouvelle fonction est déployée suite  
     334  à la modification d'une table. Dans ce cas là, la nouvelle version 
     335  doit être déployé de maniÚre synchronisée avec le  
     336  <command>script d'exécution</command> qui modifie la table.</para> 
     337 
     338<para> De la même maniÚre, les ordres <command>CREATE TYPE</command>, <command> CREATE 
     339AGGREGATE </command>,  etc. n'ont pas besoin d'être forcément insérés de 
     340maniÚre <quote>parfaitement synchronisés</quote> sur l'ensemble des noeuds. 
     341</para></listitem> 
     342 
     343<listitem><para> Les ordres de gestion des autorisations, tels que <command> CREATE USER 
    344344</command>, <command> CREATE ROLE </command>, <command>GRANT 
    345 </command>, and such are largely irrelevant to &slony1; as it runs as 
    346 a <quote>superuser</quote>. </para> 
    347  
    348 <para> Indeed, we have frequently found it useful to have different 
    349 security arrangements on different nodes.  Access to the 
    350 <quote>master</quote> node should be restricted to applications that 
    351 truly need access to it; <quote>reporting</quote> users commonly are 
    352 restricted much more there than on subscriber nodes.</para> 
    353  
    354 </listitem> 
    355 </itemizedlist> 
    356 </listitem> 
    357 </itemizedlist> 
    358  
    359 </listitem> 
    360  
    361 <listitem id="slonyuser"> <para> &slony1;-specific user names. </para> 
    362  
    363 <para> It has proven useful to define a <command>slony</command> user 
    364 for use by &slony1;, as distinct from a generic 
    365 <command>postgres</command> or <command>pgsql</command> user.  </para> 
    366  
    367 <para> If all sorts of automatic <quote>maintenance</quote> 
    368 activities, such as <command>vacuum</command>ing and performing 
    369 backups, are performed under the <quote>ownership</quote> of a single 
    370 &postgres; user, it turns out to be pretty easy to run into deadlock 
    371 problems. </para> 
    372  
    373 <para> For instance, a series of <command>vacuums</command> that 
    374 unexpectedly run against a database that has a large 
    375 <command>SUBSCRIBE_SET</command> event under way may run into a 
    376 deadlock which would roll back several hours worth of data copying 
    377 work.</para> 
    378  
    379 <para> If, instead, different maintenance roles are performed by 
    380 different users, you may, during vital operations such as 
    381 <command>SUBSCRIBE_SET</command>, lock out other users at the 
    382 <filename>pg_hba.conf</filename> level, only allowing the 
    383 <command>slony</command> user in, which substantially reduces the risk 
    384 of problems while the subscription is in progress. 
    385 </para> 
    386 </listitem> 
    387  
    388 <listitem> 
    389 <para> Path configuration </para>  
    390  
    391 <para> The section on <link linkend="plainpaths"> Path Communications 
    392 </link> discusses the issues surrounding what network connections need 
    393 to be in place in order for &slony1; to function.</para> 
    394 </listitem> 
    395  
    396 <listitem><para> Lowering Authority </para> 
    397  
    398 <para> Traditionally, it has been stated that <quote>&slony1; needs to 
    399 use superuser connections.</quote> It turns out that this is not 
    400 entirely true, and and if there are particular concerns about 
    401 excessive use of superuser accounts, it is possible to reduce this 
    402 considerably. </para> 
    403  
    404 <para> It is true to say that each &lslon; <emphasis>must</emphasis> 
    405 have a superuser connection in order to manage the node that it is 
    406 assigned to.  It needs to be able to alter the system catalogue in 
    407 order to set up subscriptions and to process alterations 
    408 (<emphasis>e.g</emphasis> - to run <xref linkend="stmtddlscript"/> and 
    409 other events that may alter the role of replicated tables on the local 
    410 node).  </para> 
    411  
    412 <para> However, the connections that &lslon; processes open to other 
    413 nodes to access events and process subcriptions do not need to have 
    414 nearly so much permission.  Indeed, one could set up a <quote>weak 
    415 user</quote> assigned to all <xref linkend="stmtstorepath"/> requests. 
    416 The minimal permissions that this user, let's call it 
    417 <command>weakuser</command>, requires are as follows:</para> 
    418  
    419 <itemizedlist> 
    420 <listitem><para> It must have read access to the &slony1;-specific namespace </para> </listitem> 
    421 <listitem><para> It must have read access to all tables and sequences in that namespace</para> </listitem> 
    422 <listitem><para> It must have write access to the &slony1; table <envar>sl_nodelock</envar> and sequence <envar>sl_nodelock_nl_conncnt_seq</envar> </para> </listitem> 
    423 <listitem><para> At subscribe time, it must have read access to all of the replicated tables. </para>  
    424 <para> Outside of subscription time, there is no need for access to access to the replicated tables. </para> </listitem> 
    425 <listitem><para> There is some need for read access to tables in pg_catalog; it has not been verified how little access would be suitable. </para> </listitem> 
    426 </itemizedlist> 
    427  
    428 <para> In version 1.3, the tests in the <xref linkend="testbed"/> 
    429 support using a <envar>WEAKUSER</envar> so that testing can regularly 
    430 confirm the minimal set of permissions needed to support 
    431 replication.</para> 
    432  
    433 </listitem> 
    434  
    435 <listitem><para> The section on <link linkend="listenpaths"> listen 
    436 paths </link> discusses the issues surrounding the table <xref 
    437 linkend="table.sl-listen"/>.</para> 
    438  
    439 <para> As of &slony1; 1.1, its contents are computed automatically 
    440 based on the communications information available to &slony1; which 
    441 should alleviate the problems found in earlier versions where this had 
    442 to be configured by hand.  Many seemingly inexplicable communications 
    443 failures, where nodes failed to talk to one another even though they 
    444 technically could, were a result of incorrect listen path 
    445 configuration. </para> 
    446 </listitem> 
    447  
    448 <listitem><para> Use <filename>test_slony_state.pl</filename> to look 
    449 for configuration problems.</para> 
    450  
    451 <para>This is a Perl script which connects to a &slony1; node and then 
    452 rummages through &slony1; configuration looking for quite a variety of 
    453 conditions that tend to indicate problems, including: 
    454 <itemizedlist> 
    455 <listitem><para>Bloating of some config tables</para></listitem> 
    456 <listitem><para>Analysis of listen paths</para></listitem> 
    457 <listitem><para>Analysis of event propagation and confirmation</para></listitem> 
     345</command>, etc. sont inutile pour &slony1; car il est exécuté avec les droits  
     346de <quote>super-utilisateur</quote>. </para> 
     347 
     348<para>Dans la pratique, il est utile d'avoir différentes politiques de sécurité 
     349  sur les noeuds. L'accÚs au noeud <quote>maître</quote> doit être limité aux  
     350  applications qui en ont réellement besoin; Les utilisateurs effectuant de  
     351  l'extraction de données ("reporting") ont généralement des droits plus limités 
     352  sur le noeud maître que sur les noeuds abonnés.</para> 
     353 
     354</listitem> 
     355</itemizedlist> 
     356</listitem> 
     357</itemizedlist> 
     358 
     359</listitem> 
     360 
     361<listitem id="slonyuser"> <para> Noms d'utilisateur spécifiques à &slony1;. </para> 
     362 
     363<para> Il s'est avéré utile de définir un utilisateur <command>slony</command> employé 
     364  uniquement par &slony1;, un utilisateur distinct de l'utilisateur générique  
     365<command>postgres</command> ou <command>pgsql</command>.  </para> 
     366 
     367<para> Lorsque toutes sortes d'activités de <quote>maintenance</quote> 
     368  automatiques, telles que les <command>vacuum</command> et les sauvegardes, 
     369  sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres; 
     370  , cela peut assez facilement provoquer des problÚmes d'inter-blocages ("deadlocks").</para> 
     371 
     372<para> Par exemple, une série de <command>vacuums</command> qui sont  
     373  lancés de maniÚre inattendue sur une base de donnée avec un gros événement 
     374  <command>SUBSCRIBE_SET</command> en cours d'exécution pourra entraîner des 
     375  inter-blocages qui annuleront plusieurs heures de travail de copie de données. 
     376  </para> 
     377 
     378<para> À l'inverse, si les différentes opérations de maintenance sont exécutées par 
     379  différents utilisateurs, vous pourrez assurer la réussite d'une opération vitale  
     380  telle que <command>SUBSCRIBE_SET</command>, en bloquant les autres utilisateurs 
     381  au niveau du fichier <filename>pg_hba.conf</filename>, et autorisant uniquement 
     382  l'utilisateur slony, ce qui réduit considérablement le risque de problÚmes lors d'un 
     383  processus de souscription. 
     384</para> 
     385</listitem> 
     386 
     387<listitem> 
     388<para> Configuration des chemins</para>  
     389 
     390<para> La section sur les <link linkend="plainpaths"> voies de communications 
     391</link> évoque les problÚmes liés aux connexions réseau nécessaire au  
     392bon fonctionnement de &slony1;.</para> 
     393</listitem> 
     394 
     395<listitem><para> Réduction des super-pouvoirs </para> 
     396 
     397<para> Traditionellement, on considÚre que <quote>&slony1; a besoin  
     398    de connexions en mode super-utilisateurs</quote>. Cela n'est pas 
     399  totalement vrai et si l'usage excessif de comptes super-utilisateurs 
     400  pose problÚme, il est possible de réduire nettement cet usage.</para> 
     401 
     402<para> Il est vrai que chaque  &lslon; <emphasis>doit</emphasis> 
     403avoir une connexion super-utilisateur afin de gérer le noeud dont il opÚre. 
     404Il doit pouvoir modifier le catalogue systÚme afin de mettre en place les  
     405souscriptions et  procéder aux modifications  
     406(<emphasis>par exemple</emphasis> - pour exécuter <xref linkend="stmtddlscript"/> et  
     407d'autres évÚnement qui peuvent modifier le rÃŽle d'une tables répliquées sur un noeud  
     408local).  </para> 
     409 
     410<para> Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres noeuds 
     411  afin d'accéder aux événements et aux souscriptions n'ont pas besoin d'avoir  
     412  d'autant de permissions. Ainsi, on peut mettre en place un  <quote>utilisateur  
     413    faible</quote> assigné à toutes les requêtes <xref linkend="stmtstorepath"/>. 
     414  Les permissions minimales de cet utilisateur, appellons-le  
     415<command>weakuser</command>, sont les suivantes :</para> 
     416 
     417<itemizedlist> 
     418<listitem><para> Il doit avoir accÚs en lecture sur le namespace spécifique de &slony1;</para> </listitem> 
     419<listitem><para> Il doit avoir accÚs en lecture sur toutes les tables et les séquences de ce namespace</para> </listitem> 
     420<listitem><para> Il doit avoir accÚs en écriture sur la table <envar>sl_nodelock</envar> et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> </para> </listitem> 
     421<listitem><para> Lors de la souscrition, il doit avoir accÚs en lecture sur toutes les tables répliquées.</para>  
     422<para> AprÚs la souscription, il n'est plus nécessaire d'accéder aux tables répliquées. </para> </listitem> 
     423<listitem><para> Il est parfois nécessaire de lire les tables dans pg_catalog; sans qu'on ait pu vérifier 
     424    à quel niveau d'accÚs est convenable. </para> </listitem> 
     425</itemizedlist> 
     426 
     427<para> Dans la version 1.3, les tests du <xref linkend="testbed"/> 
     428permettent l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de  
     429tester si les permissions définies sont suffisantes pour supporter la réplication. 
     430</para> 
     431 
     432</listitem> 
     433 
     434<listitem><para> La section sur les <link linkend="listenpaths"> voies d'écoute </link> 
     435    parle des problÚmes entourant la table <xref linkend="table.sl-listen"/>.</para> 
     436 
     437<para> A partir la version &slony1; 1.1, le contenu de cette table  
     438  était calculé automatiquement en se basant sur les informations 
     439  dont disposait &slony1; ce qui devrait supprimer les problÚmes  
     440  rencontrés. Beaucoup de problÚmes de communication inexplicables, 
     441  avec des noeuds qui n'arrive pas à se parler alors que c'est techniquement  
     442  possible, étaient du à une configuration incorrecte des voies d'écoutes. 
     443  </para> 
     444</listitem> 
     445 
     446<listitem><para> Utilisez <filename>test_slony_state.pl</filename> pour rechercher 
     447    les problÚmes de configuration.</para> 
     448 
     449<para>Il s'agit d'un script Perl qui se connecte à un noeud &slony1; puis  
     450  parcours la configuration &slony1; à la recherche de différentes conditions 
     451  qui indique la présence de problÚmes, en particulier : 
     452<itemizedlist> 
     453<listitem><para>le gonflement de certaines tables de congfiguration;</para></listitem> 
     454<listitem><para>l'analyse des voies d'écoute;</para></listitem> 
     455<listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem> 
    458456</itemizedlist></para> 
    459457 
    460 <para> If replication mysteriously <quote>isn't working</quote>, this 
    461 tool can run through many of the possible problems for you. </para> 
    462  
    463 </listitem> 
    464  
    465 <listitem> 
    466 <para> Configuring &lslon; </para>  
    467  
    468 <para> As of version 1.1, &lslon; configuration may be 
    469 drawn either from the command line or from configuration files. 
    470 <quote>Best</quote> practices have yet to emerge from the two 
    471 options:</para> 
    472 </listitem> 
    473 </itemizedlist> 
    474  
    475 <itemizedlist> 
    476  
    477 <listitem> 
    478 <para> Configuration via command line options</para>  
    479  
    480 <para> This approach has the merit that all the options that are 
    481 active are visible in the process environment.  (And if there are a 
    482 lot of them, they may be a nuisance to read.)</para> 
    483  
    484 <para> Unfortunately, if you invoke &lslon; from the 
    485 command line, you could <emphasis>forget</emphasis> to include 
    486 &logshiplink; configuration and thereby destroy the sequence of logs 
    487 for a log shipping node. </para> 
    488 </listitem> 
    489  
    490 <listitem> <para> Unlike when command line options are used, the 
    491 active options are <emphasis>not</emphasis> visible.  They can only be 
    492 inferred from the name and/or contents of the &lslon; 
    493 configuration file, and will not reflect subsequent changes to the 
    494 configuration file.  </para> 
    495  
    496 <para> By putting the options in a file, you won't forget including 
    497 any of them, so this is safer for &logshiplink;. </para> 
    498 </listitem> 
    499  
    500 </itemizedlist> 
    501 <itemizedlist> 
    502  
    503 <listitem><para> Things to do when subscribing nodes </para> 
    504  
    505 <para> When a new node is running the <command>COPY_SET</command> 
    506 event for a large replication set (<emphasis>e.g.</emphasis> - one 
    507 which takes several hours to subscribe) it has been found to be 
    508 desirable to lock all users other than the <command>slony</command> 
    509 user out of the new subscriber because: 
    510 </para> 
    511 </listitem> 
    512 </itemizedlist> 
    513 <itemizedlist> 
    514  
    515 <listitem><para> Applications will run into partially-copied, 
    516 half-baked data that is not totally consistent. </para> </listitem> 
    517  
    518 <listitem><para> It is possible for applications (and maintenance 
    519 scripts) to submit combinations of queries that will get the system 
    520 into a deadlock situation, thereby terminating the 
    521 <command>COPY_SET</command> event, and requiring the subscription to 
    522 start over again.  </para> </listitem> 
    523  
    524 </itemizedlist> 
    525  
    526 <para> It <emphasis>may</emphasis> be worth considering turning the 
    527 &postgres; <function>fsync</function> functionality off during the 
    528 copying of data, as this will improve performance, and if the database 
    529 <quote>falls over</quote> during the <command>COPY_SET</command> 
    530 event, you will be restarting the copy of the whole replication 
    531 set.</para> 
    532  
    533 <itemizedlist> 
    534 <listitem><para> Managing use of slonik </para>  
    535  
    536 <para> The notes on <link linkend="usingslonik"> Using Slonik </link> 
    537 describe some of the lessons learned from managing large numbers of 
    538 <xref linkend="slonik"/> scripts.</para> 
    539  
    540 <para> Notable principles that have fallen out of generating many 
    541 slonik scripts are that: 
    542  
    543 <itemizedlist> 
    544  
    545 <listitem><para>Using <quote>preamble</quote> files is 
    546 <emphasis>highly recommended</emphasis> as it means that you use 
    547 heavily-verified preambles over and over.</para></listitem> 
    548  
    549 <listitem><para>Any opportunity that you have to automatically 
    550 generate configuration whether by drawing it from a database or by 
    551 using a script that generates repetitively similar elements will help 
    552 prevent human error.</para></listitem> 
    553  
    554 </itemizedlist> 
    555 </para> 
    556 </listitem> 
    557  
    558 <listitem><para> Handling Very Large Replication Sets </para> 
    559  
    560 <para> Some users have set up replication on replication sets that are 
    561 tens to hundreds of gigabytes in size, which puts some added 
    562 <quote>strain</quote> on the system, in particular where it may take 
    563 several days for the <command>COPY_SET</command> event to complete. 
    564 Here are some principles that have been observed for dealing with 
    565 these sorts of situations.</para></listitem> 
    566  
    567 </itemizedlist> 
    568  
    569 <itemizedlist> 
    570  
    571 <listitem><para> Drop all indices other than the primary key index 
    572 while the <command>COPY_SET</command> event is run. </para> 
    573  
    574 <para> When data is copied into a table that has indices on it, 
    575 &postgres; builds the indices incrementally, on the fly.  This is much 
    576 slower than simply copying the data into the table, and then 
    577 recreating each index <quote>ex nihilo</quote>, as the latter can take 
    578 substantial advantage of sort memory. </para> 
    579  
    580 <para> In &slony1; version 1.1.5 and later versions, indices are 
    581 dropped and recreated automatically, which effectively invalidates 
    582 this practice.</para> 
    583 </listitem> 
    584  
    585 <listitem><para> If there are large numbers of updates taking place as 
    586 the large set is being copied, this can lead to the subscriber being 
    587 behind by some enormous number of <command>SYNC</command> events.</para> 
    588  
    589 <para> If a <command> SYNC </command> is generated about once per 
    590 second, that leads to the subscriber <quote>falling behind</quote> by 
    591 around 90,000 <command>SYNC</command>s per day, possibly for several 
    592 days.  </para> 
    593  
    594 <para> There will correspondingly be an <emphasis>enormous</emphasis> 
    595 growth of <xref linkend="table.sl-log-1"/> and <xref 
    596 linkend="table.sl-seqlog"/>.  Unfortunately, once the 
    597 <command>COPY_SET</command> completes, users have found that the 
    598 queries against these tables wind up reverting to <command>Seq 
    599 Scans</command> so that even though a particular 
    600 <command>SYNC</command> processing event is only processing a small 
    601 number of those 90,000 <command>SYNC</command> events, it still reads 
    602 through the entire table.  In such a case, you may never see 
    603 replication catch up. 
     458<para> Si, de maniÚre mystérieuse, la réplication <quote>ne marche pas</quote>, cet outil 
     459  peut vérifier beaucoup de problÚmes potentiels pour vous. </para> 
     460 
     461</listitem> 
     462 
     463<listitem> 
     464<para> Configurer &lslon; </para>  
     465 
     466<para> A partir de la version 1.1, la configuration de &lslon;  
     467peut être définie par ligne de commande ou dans des fichiers de 
     468configuration. De <quote>bonnes</quote> pratiques sont  
     469conseillédans les deux cas : 
     470</para> 
     471 
     472<itemizedlist> 
     473 
     474<listitem> 
     475<para> Configuration via les options en ligne de commande</para>  
     476 
     477<para> Cette approche à le mérite de rendre visible dans 
     478l'environnement systÚme toutes les options actives. 
     479( Ainsi s'il y en a beaucoup cela peut devenir pénible 
     480à lire )</para> 
     481 
     482<para>Malheureusement, si vous invoquer &lslon; à partir d'une 
     483ligne de commande, vous pouvez <emphasis>oublier</emphasis> d'inclure 
     484la configuration de &logshiplink; et ainsi détruire les 
     485séquences de logs pour les noeuds de log shipping.</para> 
     486</listitem> 
     487 
     488<listitem> <para> A la différence  des options en ligne de 
     489commande les options actives ne sont <emphasis>pas</emphasis> visible. 
     490Elles peuvent seulement être positionnées à partir u nom 
     491et du contenu du fichier de configuration de &lslon;, et ne  
     492refléteront pas les changements apparus dans le fichier de 
     493configuration. 
     494</para> 
     495 
     496<para> En plaçant les options dans un fichier, vous n'oublierez 
     497aucune, ce qui est plus sur pour &logshiplink;. </para> 
     498</listitem> 
     499 
     500</itemizedlist> 
     501</listitem> 
     502 
     503<listitem><para> Taches à faire loque l'on abonne un noeud </para> 
     504 
     505<para> Lorsqu'un nouveau noeud exécute l'événement <command>COPY_SET</command> 
     506sur un grand ensemble de réplication (<emphasis>par 
     507exemple</emphasis> - un ensemble qui nécessite un abonnement de 
     508plusieurs heures) il est prouvé qu'il est souhaitable de 
     509verrouiller l'accÚs au noeud pour tous les utilisateurs 
     510autres que <command>slony</command> car : 
     511</para> 
     512</listitem> 
     513 
     514<itemizedlist> 
     515 
     516<listitem><para> Les applications s'exécutent sur des  
     517données partiellemen copiées qui ne seront pas 
     518consistantes. 
     519</para> </listitem> 
     520 
     521<listitem><para>Il est possible que certaines applications (et 
     522certains scripts de maintenance) soumettent une combinaison  
     523de requêtes qui placeront le systÚme dans une situation 
     524d'inter-blocage ("deadlock"), ce qui annulera l'événement  
     525<command>COPY_SET</command>, et impliquera le ré-abonnement 
     526complet du noeud.</para> </listitem> 
     527 
     528</itemizedlist> 
     529 
     530<para> Il <emphasis>peut</emphasis> être intéressant de 
     531désactive la fonctionnalité<function>fsync</function> de &postgres; 
     532pendant le copie des données, car cela améliorera les 
     533performances, 
     534et en cas d'échec lors de l'évÚnement 
     535<command>COPY_SET</command>, 
     536vous pourrez redémarrer avec un copie entiÚre de 
     537l'ensemble de réplication.</para> 
     538 
     539 
     540<listitem><para> Gestion de slonik </para>  
     541 
     542<para> Les notes sur <link linkend="usingslonik">l'utilisation de  
     543Slonik </link> décrivent certaines lessons apprises en 
     544gérant un grand nombre de scripts <xref linkend="slonik"/>.</para> 
     545 
     546<para> Voici les principes importants se sont dégagés lors de 
     547la création de ces scripts : 
     548 
     549<itemizedlist> 
     550 
     551<listitem><para>Utiliser des fichiers <quote>préambule</quote> 
     552est <emphasis>hautement recommandé</emphasis> car cela implique 
     553que vous utilisiez et    réutilisiez des 
     554préambules vérifié maintes fois.</para></listitem> 
     555 
     556<listitem><para>Toute opportunité de générer automatiquement 
     557la configuration soit en la récpérant dans une base de 
     558données, soit en utilisant un script de génération vous 
     559aidera à éviter les erreurs humaines.</para></listitem> 
     560 
     561</itemizedlist> 
     562</para> 
     563</listitem> 
     564 
     565<listitem><para>GÚrer un trÚs grand ensemble de réplication</para> 
     566 
     567<para> Certains utilisateurs ont bâti des réplications sur des 
     568 ensembles de plusieurs dizaines, voire plusieurs centaines de  
     569 gigabytes, ce qui ajoute des <quote>contraintes</quote> sur le 
     570systÚme, n particulier lorsqu'il faut plusieurs jours pour 
     571 effectuer un évÚnement  <command>COPY_SET</command>. 
     572 Voici quelques principes qui ont été définis 
     573 pour gérer ce genre de situations.</para></listitem> 
     574 
     575 
     576 
     577<itemizedlist> 
     578 
     579<listitem><para> Supprimer tous les index autres que les index  
     580primaire lorsque l'évÚnement en<command>COPY_SET</command> 
     581est exécuté. </para> 
     582 
     583<para> Lorsque les données sont copiées dans une table qui 
     584dispose d'index, &postgres; construit les index de maniÚre 
     585incrémentale, à la vole. 
     586Ceci est beaucoup plus lent que simplement copier les donnés 
     587dans une table puis de recréerchaque index <quote>ex 
     588nihilo</quote>, 
     589car cette derniÚre opération profite de l'avantage de la 
     590mémoire de tri. </para> 
     591 
     592<para> Dans &slony1; version 1.1.5 et dans les versions 
     593ultérieures, les index sont supprimés et 
     594recréés automatiquement, ce qui rend caduque ce 
     595conseil. 
     596</para> 
     597</listitem> 
     598 
     599<listitem><para> Si beaucoup de mises à jour ont lieu lorsque de 
     600grands ensemble sont copiés, ceci peut mener à un nombre 
     601énormed'événements<command>SYNC</command> sur le 
     602noeud qui s'abonne.</para> 
     603 
     604<para>Si un <command> SYNC </command> est généré 
     605une fois par seconde, ceci conduit à un <quote>retard</quote> 
     606 de plus de 90,000 <command>SYNC</command>s par jour, pendant 
     607 probablement plusieurs jours.  </para> 
     608 
     609<para>ParallÚlement 
     610on constatera une croissance <emphasis>énorme</emphasis> 
     611des tables <xref linkend="table.sl-log-1"/> et <xref 
     612linkend="table.sl-seqlog"/>.   
     613Malheureusement, une fois que <command>COPY_SET</command>  
     614est complété, on constate que les requêtes sur  
     615ces tables se font via <command>seq scans</command>, 
     616mémé si le <command>SYNC</command> ne traite qu'une petite 
     617partie de ces 90 000 événements<command>SYNC</command> 
     618la table sera lue dans son ensemble. Dans de tel cas, il 
     619est possible que le noeud abonné ne rattrape 
     620jamais le noeud origine. 
    604621</para>  
    605622 
    606 <para> Several things can be done that will help, involving 
    607 careful selection of &lslon; parameters:</para> 
    608 </listitem> 
    609 </itemizedlist> 
    610  
    611 <itemizedlist> 
    612  
    613 <listitem><para> Ensure that there exists, on the 
    614 <quote>master</quote> node, an index on <function> sl_log_1(log_xid) 
    615 </function>.  If it doesn't exist, as the &slony1; instance was set up 
    616 before version 1.1.1, see <filename> slony1_base.sql </filename> for 
    617 the exact form that the index setup should take. </para>  
    618  
    619 <para> In 1.2 and later versions, there is a process that runs 
    620 automatically to add partial indexes by origin node number, which 
    621 should be the optimal form for such an index to take.  </para> 
    622 </listitem> 
    623  
    624 <listitem><para> On the subscriber's &lslon;, increase 
    625 the number of <command>SYNC</command> events processed together, with 
    626 the <xref linkend= "slon-config-sync-group-maxsize"/> parameter to some 
    627 value that allows it to process a significant portion of the 
    628 outstanding <command>SYNC</command> events. </para> </listitem> 
    629  
    630 <listitem><para> On the subscriber's &lslon;, set the 
    631 <xref linkend="slon-config-desired-sync-time"/> to 0, as the adaptive 
    632 <command>SYNC</command> grouping system will start with small 
    633 groupings that will, under these circumstances, perform 
    634 poorly. </para> </listitem> 
    635  
    636 <listitem><para> Increase the <xrefls 
    637 linkend="slon-config-sync-interval"/> on the origin's <xref 
    638 linkend="slon"/> so that <command>SYNC</command> events are generated 
    639 less frequently.  If a <command>SYNC</command> is only generated once 
    640 per minute instead of once per second, that will cut down the number 
    641 of events by a factor of 60. </para> </listitem> 
    642 </itemizedlist> 
    643  
    644 <itemizedlist> 
    645 <listitem><para> It is likely to be worthwhile to use <xref 
    646 linkend="slon-config-vac-frequency"/> to deactivate <xref 
    647 linkend="slon"/>-initiated vacuuming in favor of running your own 
    648 vacuum scripts, as there will be a buildup of unpurgeable data while 
    649 the data is copied and the subscriber starts to catch up. </para> 
     623<para> Plusieurs taches peuvent résoudre ce problÚme, 
     624notamment en réglant avec soin les paramÚtres  
     625&lslon; :</para> 
     626</listitem> 
     627</itemizedlist> 
     628 
     629<itemizedlist> 
     630 
     631<listitem><para>Assurez-vous qu'il existe sur le noeud  
     632<quote>maître</quote>, un index sur  <function> sl_log_1(log_xid) 
     633</function>.  
     634S'il n'y en a pas, comme avec les versions de &slony1;  
     635inférieure à la version 1.1.1, regardez dans le fichier 
     636<filename> slony1_base.sql </filename> pour 
     637la configuration correcte de cet index. </para>  
     638 
     639<para> Dans les versions 1.2 et suivantes, il y a un processus 
     640qui ajoute automatiquement les index partiels par numéro de 
     641noeud 
     642d'origine, ce qui est la forme optimale pour ces index. 
     643</para> 
     644</listitem> 
     645 
     646<listitem><para>Sur un noeud abonné, ajouter