[Trad] [svn:pgfr] r1047 - traduc/trunk/slony
svncommit at kryskool.org
svncommit at kryskool.org
Mar 27 Mai 20:45:53 CEST 2008
Auteur: daamien
Date: 2008-05-27 20:45:53 +0200 (mar, 27 mai 2008)
Nouvelle Révision: 1047
Modification:
traduc/trunk/slony/bestpractices.xml
Log:
best practices, 1ere traduction, xml à vérifier
Modified: traduc/trunk/slony/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml 2008-05-26 07:20:18 UTC (rev 1046)
+++ traduc/trunk/slony/bestpractices.xml 2008-05-27 18:45:53 UTC (rev 1047)
@@ -21,7 +21,7 @@
en fonction de l'architecture globale de votre réseau, de votre ensemble de serveurs de base de données,
et de votre manière d'utiliser ces serveurs.</para>
-<para> Il ya toutefois, un certain nombre de choses que les pioniers de &slony1; ont
+<para> Il y a toutefois, un certain nombre de choses que les pionniers de &slony1; ont
découvertes qui peuvent au moins aider à concevoir le genre de règles d'administration
que vous pourriez mettre en place. </para>
@@ -32,7 +32,7 @@
ce qui implique qu'il existe un ensemble presque infini d'endroits
où des problèmes peuvent surgir.</para>
-<para> c'est donc naturellement que la maintenance d'un environement propre, cohérent
+<para> c'est donc naturellement que la maintenance d'un environnement propre, cohérent
est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement
peut provoquer des problèmes ou masquer le problème réel. </para>
@@ -70,15 +70,15 @@
<para> Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
&lslon; correctement lorsque leur système utilisait une zone de temps que
- &postgres; ne pouvait pas reconnaitre tel que CUT0 ou WST. Il est nécessaire
+ &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est nécessaire
que vous utilisiez une zone de temps que &postgres; reconnaît correctement.
De plus, il est préférable d'utiliser une zone qui n'est pas soumise au
basculement entre heure d'été et heure d'hivers.</para>
<para> Le choix <quote>géographiquement neutre</quote> semble être
<command><envar>TZ</envar>=UTC</command> ou
-<command><envar>TZ</envar>=GMT</command>, par ailleurs assurez-vous que
-vos serveurs sont <quote>synchronisés</quote> grace à l'utilisation
+<command><envar>TZ</envar>=GMT</command>, par ailleurs Assurez-vous que
+vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation
de NTP sur l'ensemble de votre environnement. </para>
<para> Voir aussi <xref linkend="times"/>.</para>
@@ -105,7 +105,7 @@
</para></listitem>
<listitem><para> Le système va périodiquement faire une rotation (en utilisant
- <command>TRUNCATE</command> pour nettoyer l'anccienne table) entre les deux tables de logs,
+ <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les deux tables de logs,
<xref linkend="table.sl-log-1"/> et <xref
linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit. </para></listitem>
</itemizedlist>
@@ -117,9 +117,9 @@
devraient être planifiées à l'avance. </para>
<para> Cela peut simplement se résumer à réfléchir à une liste
- de priorité indiquant ce qui devrait basculer vers quoi, plutot
+ de priorité indiquant ce qui devrait basculer vers quoi, plutôt
que d'essayer d'automatiser la bascule. Quoiqu'il en soit savoir
- au prélable ce qu'il faut faire réduit le nombre d'erreurs commises.
+ au préalable ce qu'il faut faire réduit le nombre d'erreurs commises.
</para>
<para> Chez Afilias, une grande variété de guide interne, tel que <citation>Le guide
@@ -131,225 +131,225 @@
</para>
</listitem>
-<listitem><para> <xref linkend="stmtmoveset"/> should be used to allow
-preventative maintenance to prevent problems from becoming serious
-enough to require <link linkend="failover"> failover </link>. </para>
+<listitem><para> <xref linkend="stmtmoveset"/> doit être utlisé� pour
+la maintenance préventive afin d'éviter l'apparition des
+problèmes nécessitant une <link linkend="failover">
+bascule après panne ("failover") </link>. </para>
</listitem>
-<listitem> <para> <command>VACUUM</command> policy needs to be
-carefully defined.</para>
+<listitem> <para> La politique de <command>VACUUM</command> doit être
+définie avec soin.</para>
-<para> As mentioned above, <quote>long running transactions are
-Evil.</quote> <command>VACUUM</command>s are no exception in this. A
-<command>VACUUM</command> on a huge table will open a long-running
-transaction with all the known ill effects.</para>
+<para> Comme indiqué précédemment, <quote>les transactions longues sont maléfiques.</quote>
+ La commande <command>VACUUM</command> n'est pas une exception à cette règle.
+ Un <command>VACUUM</command> sur une grande table ouvrira une transaction longue
+ qui aura tous les effets négatifs déjà cités.</para>
</listitem>
-<listitem><para> If you are using the autovacuum process in recent
-versions of &postgres;, you may wish to leave &slony1; tables out, as
-&slony1; is a bit more intelligent about vacuuming when it is expected
-to be conspicuously useful (<emphasis>e.g.</emphasis> - immediately
-after purging old data) to do so than autovacuum can be. </para>
+<listitem><para> Si vous utiliser le processus autovacuum process avec une
+ version récente de &postgres;, vous pouvez éviter de le faire pour les tables &slony1;
+ car &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il s'agit de
+ vacuum dans des conditions de réplication ( <emphasis>par exemple</emphasis> : la purge
+ des anciennes données ).</para>
-<para> See <xref linkend="maintenance-autovac"/> for more
-details. </para> </listitem>
+<para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de
+détails. </para> </listitem>
-<listitem> <para> Running all of the &lslon; daemons on a central
-server for each network has proven preferable. </para>
+<listitem> <para> Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
+ sur un serveur central pour chaque sous-réseau. </para>
-<para> Each &lslon; should run on a host on the same local network as
-the node that it is servicing, as it does a <emphasis>lot</emphasis>
-of communications with its database, and that connection needs to be
-as reliable as possible. </para>
+<para> Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
+ le noeud qu'il opère, car il envoie <emphasis>beaucoup</emphasis> de
+ communications avec sa base de donnée et que la connexion doit être aussi fiable
+ que possible.</para>
-<para> In theory, the <quote>best</quote> speed might be expected to
-come from running the &lslon; on the database server that it is
-servicing. </para>
+<para> En théorie, les <quote>meilleures</quote> performances sont prévues lorsque
+ le &lslon; fonctionne sur le même serveur que la base qu'il opère. </para>
-<para> In practice, strewing &lslon; processes and configuration
-across a dozen servers turns out to be inconvenient to manage.</para>
+<para> En pratique, déployer les processus &lslon; processes et leur configuration
+ à travers un réseau d'une douzaine de serveurs se révèle être difficilement gérable.</para>
</listitem>
-<listitem><para> &lslon; processes should run in the same
-<quote>network context</quote> as the node that each is responsible
-for managing so that the connection to that node is a
-<quote>local</quote> one. Do <emphasis>not</emphasis> run such links
-across a WAN. </para>
+<listitem><para>Les processus &lslon; doivent évoluer dans le même
+ <quote>contexte réseau</quote> que le noeud qu'il opère, afin que la
+ liaison entre eux soir une connexion <quote>locale</quote>.
+ N'établissez <emphasis>pas</emphasis> ce genre de liaison à
+ travers un réseau WAN. </para>
-<para> A WAN outage can leave database connections
-<quote>zombied</quote>, and typical TCP/IP behaviour <link
-linkend="multipleslonconnections"> will allow those connections to
-persist, preventing a slon restart for around two hours. </link>
+<para> Une coupure de lien WAN peut provoquer des connexions
+ <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
+ <link linkend="multipleslonconnections"> laisser ces connexions persister,
+ empêchant le démon slon de redémarrer pendant environ deux heures. </link>
</para>
-<para> It is not difficult to remedy this; you need only <command>kill
-SIGINT</command> the offending backend connection. But by running the
-&lslon; locally, you will generally not be vulnerable to this
-condition. </para>
+<para> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les
+ processus liés aux connexions persistantes avec la commande <command>kill
+SIGINT</command>. Cependant en exécutant les &lslon; localement, vous êtes
+généralement à l'abri de ce genre de problèmes. </para>
</listitem>
-<listitem><para> Before getting too excited about having fallen into
-some big problem, consider killing and restarting all the &lslon;
-processes. Historically, this has frequently been able to
-resolve <quote>stickiness.</quote> </para>
+<listitem><para> Si vous rencontrez ce genre de problèmes, avant de vous exciter,
+ essayez de tuer et redémarrer tous les processus &lslon;.
+ Historiquement, cette méthode a souvent résolu ce genre de
+ <quote>petit tracas.</quote>.</para>
-<para> With a very few exceptions, it is generally not a big deal to
-kill off and restart the &lslon; processes. Each &lslon; connects to
-one database for which it is the manager, and then connects to other
-databases as needed to draw in events. If you kill off a &lslon;, all
-you do is to interrupt those connections. If
-a <command>SYNC</command> or other event is sitting there
-half-processed, there's no problem: the transaction will roll back,
-and when the &lslon; restarts, it will restart that event from
-scratch.</para>
+<para>A quelques rares exceptions, il n'est pas très grave de tuer et relancer les
+ processus &lslon;. Chaque &lslon; se connecte à la base de données qu'il gère, puis
+ ouvre les connexions nécessaires à la propagation des événements.
+ Si vous tuer un &lslon;, vous provoquez simplement l'interruption de ces connexions.
+ Si un évènement <command>SYNC</command> ou un autre événement est en cours de propagation,
+ il n'y a pas de problème : la transaction sera annulée ("roll back") et lorsque le &lslon;
+ sera relancé, l'évènement sera retraiter à partir de zéro.</para>
-<para> The exception, where it is undesirable to restart a &lslon;, is
-where a <command>COPY_SET</command> is running on a large replication
-set, such that stopping the &lslon; may discard several hours worth of
-load work. </para>
+<para> L'exception qui rend un redémarrage de &lslon; indésirable est le cas
+ où une commande <command>COPY_SET</command> est en cours d'exécution sur un
+ grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon; peut
+ annuler plusieurs heures de travail. </para>
-<para> In early versions of &slony1;, it was frequently the case that
-connections could get a bit <quote>deranged</quote> which restarting
-&lslon;s would clean up. This has become much more rare, but it has
-occasionally proven useful to restart the &lslon;. If there has been
-any <quote>network derangement</quote>, this can clear up the issue of
-defunct database connections. </para> </listitem>
+<para> Dans les premières versions de &slony1;, il était fréquent que
+ des connexions soient un peu <quote>dérangée</quote>, ce qu'on pouvait
+ réparer en redémarrant &lslon;. Ceci est devenu nettement plus rare,
+ mais il est parfois utile de redémarrer &lslon;. En cas de
+ <quote>panne réseau</quote>, cela peut résoudre le problème des
+ connexions à la base défuntes. </para> </listitem>
<listitem>
-<para>The <link linkend="ddlchanges"> Database Schema Changes </link>
-section outlines some practices that have been found useful for
-handling changes to database schemas. </para></listitem>
+<para>La section sur les <link linkend="ddlchanges">changements de modèle de données</link>
+détaille quelques bonnes pratiques qui sont utiles lorsque l'on souhaite modifier le
+schémas de la base de données. </para></listitem>
<listitem>
-<para> Handling of Primary Keys </para>
+<para> Gestion des clefs primaires </para>
-<para> Discussed in the section on <link linkend="definingsets">
-Replication Sets, </link> it is <emphasis>ideal</emphasis> if each
-replicated table has a true primary key constraint; it is
-<emphasis>acceptable</emphasis> to use a <quote>candidate primary
-key.</quote></para>
+<para> Comme précisé dans la section <link linkend="definingsets">
+Ensembles de réplication</link>, il est <emphasis>idéal</emphasis> que
+chaque table répliquée dispose d'un vraie contrainte de clef primaire;
+il est <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
+ candidate.</quote></para>
-<para> It is <emphasis>not recommended</emphasis> that a
-&slony1;-defined key (created via <xref linkend="stmttableaddkey"/>) be
-used to introduce a candidate primary key, as this introduces the
-possibility that updates to this table can fail due to the introduced
-unique index, which means that &slony1; has introduced a new failure
-mode for your application.</para>
+<para> Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie
+ par &slony1; (crée par <xref linkend="stmttableaddkey"/>) pour
+ proposer une clef primaire candidate, car cela introduit la possibilité
+ d'échecs de certaines mises à jour sur la table à cause de l'index unique de cette
+ clef. Ceci entraînerait potentiellement des bugs dans votre application à cause
+ de &slony1;.</para>
-<warning><para> In version 2 of &slony1;, <xref
-linkend="stmttableaddkey"/> is no longer supported. You
-<emphasis>must</emphasis> have either a true primary key or a
-candidate primary key. </para></warning>
+<warning><para> Dans la version 2 de &slony1;, <xref
+linkend="stmttableaddkey"/> n'est plus supportée. Vous <emphasis>devez</emphasis> absolument
+ avoir soit une vraie clef primaire, soit une clef primaire candidate.</para></warning>
</listitem>
<listitem>
-<para> <link linkend="definesets"> Grouping tables into sets
-</link> suggests strategies for determining how to group tables and
-sequences into replication sets. </para>
+<para> La section <link linkend="definesets"> Définir les ensembles de réplication
+</link> vous suggère des stratégies pour déterminer comment regrouper les tables
+et les séquences en ensembles de réplication. </para>
</listitem>
<listitem>
-<para> It should be obvious that actions that can delete a
-lot of data should be taken with great care; the section on <link
-linkend="dropthings"> Dropping things from &slony1; Replication</link>
-discusses the different sorts of <quote>deletion</quote> that &slony1;
-supports. </para>
+<para> Il est évident que les actions qui peuvent supprimer beaucoup
+ de données doivent être effectuées avec le plus grand soin; La section
+ <link
+linkend="dropthings">Supprimer des éléments de la réplication</link>
+évoque les différentes sortes de <quote>suppression</quote> que &slony1;
+supporte. </para>
</listitem>
<listitem>
-<para> <link linkend="Locking"> Locking issues </link></para>
+<para> <link linkend="Locking">Problèmes d'inter-blocages</link></para>
-<para> Certain &slony1; operations, notably <link
+<para> Certaines opérations &slony1;, notament <link
linkend="stmtsetaddtable"> <command>set add table</command> </link>,
<link linkend="stmtmoveset"> <command> move set</command> </link>,
<link linkend="stmtlockset"> <command> lock set </command> </link>,
-and <link linkend="stmtddlscript"> <command>execute script</command>
-</link> require acquiring <emphasis>exclusive locks</emphasis> on the
-tables being replicated. </para>
+et <link linkend="stmtddlscript"> <command>execute script</command>
+</link> nécessite l'acquisition de <emphasis>verrous exclusifs</emphasis> sur les
+tables répliquées.</para>
-<para> Depending on the kind of activity on the databases, this may or
-may not have the effect of requiring a (hopefully brief) database
-outage. </para>
+<para> En fonction de type d'activité de votre base de données, cela
+ peut ( ou pas ) provoquer des coupures de services ( heureusement assez brèves ). </para>
</listitem>
-<listitem><para> What to do about DDL. </para>
+<listitem><para> Que faire des ordres DDL ? </para>
-<para> &slony1; operates via detecting updates to table data via
-triggers that are attached to those tables. That means that updates
-that take place via methods that do not fire triggers will not notice
-those updates. <command>ALTER TABLE</command>, <command>CREATE OR
-REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, all
-represent SQL requests that &slony1; has no way to notice. </para>
+<para> &slony1; fonctionne en détectant les mises à jour sur les tables
+ grâce à des triggers qui sont placés sur ces tables.
+ Cela implique que les mises à jours que sont font au moyen de
+ méthodes qui ne déclenche pas les triggers ne seront pas propagées.
+ Les commandes <command>ALTER TABLE</command>, <command>CREATE OR
+REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, sont toutes
+des requêtes SQL que &slony1; ne peut pas détecter. </para>
-<para> A philosophy underlying &slony1;'s handling of this is that
-competent system designers do not write self-modifying code, and
-database schemas that get modified by the application are an instance
-of this. It does not try hard to make it convenient to modify
-database schemas. </para>
+<para> Pour ce genre de situation, la philosophie de &slony1;
+ consiste à considérer que les développeurs compétents n'écrivent
+ jamais de code auto-modifiant et en particulier du code modifiant
+ les modèles de données à la volée. &slony1; ne cherche pas à faciliter
+ ce genre de modification du schémas de données. </para>
-<para> There will be cases where that is necessary, so the <link
-linkend="stmtddlscript"> <command>execute script</command> is provided
-which will apply DDL changes at the same location in the transaction
-stream on all servers. </link> </para>
+<para> Cependant il existe des cas où cela est nécessaire, ainsi la <link
+linkend="stmtddlscript"> <command>execute script</command> est fournie
+ pour appliquer des changements DDL au même point dans
+ le flux de transactions sur tous les serveurs.</link> </para>
-<para> Unfortunately, this introduces a great deal of locking of
-database objects. Altering tables requires taking out an exclusive
-lock on them; doing so via <command>execute script</command> requires
-that &slony1; take out an exclusive lock on <emphasis>all</emphasis>
-replicated tables. This can prove quite inconvenient when
-applications are running; you run into deadlocks and such. </para>
+<para> Malheureusement, cela provoque de nombreux verrous sur
+ les objets de la base de données. Modifier les tables nécessite
+ de l'acquisition d'un verrou exclusif sur ces objets; ainsi le
+ <command>script d'exécution des modification</command> entraîne
+ un verrous exclusif sur <emphasis>toutes</emphasis> les tables
+ répliquées. Cela peut s'avérer très problématiques lorsque les
+ applications fonctionnent; des inter-blocages ("deadlocks") peuvent
+ alors se produire.</para>
-<para> One particularly dogmatic position that some hold is that
-<emphasis>all</emphasis> schema changes should
-<emphasis>always</emphasis> be propagated using <command>execute
-script</command>. This guarantees that nodes will be consistent, but
-the costs of locking and deadlocking may be too high for some
-users.</para>
+<para> Une position particulièrement dogmatique défendue par certains
+ consiste à dire qu'il faut <emphasis>toujours</emphasis> propager
+ les changements de modèles de données avec un <command>script d'exécution</command>.
+ Cela garantit que les noeuds restent consistants, cependant le coût des verrous
+ et des inter-blocages est trop élevé pour certains utilisateurs.</para>
-<para> At Afilias, our approach has been less dogmatic; there
-<emphasis>are</emphasis> sorts of changes that
-<emphasis>must</emphasis> be applied using <command>execute
-script</command>, but we apply others independently.</para>
+<para> Chez Afilias, notre approche est moins dogmatique; il y a
+<emphasis>certains</emphasis> changements qui
+<emphasis>doivent</emphasis> être appliquées avec un <command>script d'exécution</command>,
+mais nous appliquons certaines modification de manière indépendante.</para>
<itemizedlist>
-<listitem><para> Changes that must be applied using <command>execute script</command> </para>
+<listitem><para> Liste de changements qui doivent être effectuée dans un <command>script d'exécution</command> :</para>
<itemizedlist>
-<listitem><para> All instances of <command>ALTER TABLE</command></para></listitem>
+<listitem><para> Toutes les commandes <command>ALTER TABLE</command></para></listitem>
</itemizedlist>
</listitem>
-<listitem><para> Changes that are not normally applied using <command>execute script</command> </para>
+<listitem><para> Listes des changement qui ne nécessitent pas un <command>script d'exécution :</command> </para>
<itemizedlist>
<listitem><para> <command>CREATE INDEX</command> </para></listitem>
<listitem><para> <command>CREATE TABLE</command> </para>
-<para> Tables that are not being replicated do not require &slony1; <quote>permission</quote>. </para></listitem>
+<para> Les tables qui ne sont pas répliquées n'ont pas besoin de ces
+ mécanismes. </para></listitem>
<listitem><para> <command>CREATE OR REPLACE FUNCTION </command> </para>
-<para> Typically, new versions of functions may be done without
-&slony1; being <quote>aware</quote> of them. The obvious exception is
-when a new function is being deployed to accomodate a table
-alteration; in that case, the new version must be added in in a manner
-synchronized with the <command>execute script</command> for the table
-alteration. </para>
+<para> Typiquement, le chargement de nouvelles version de fonctions
+ peut être effectuée sans que &slony1; en soit <quote>averti</quote>.
+ A l'exception évidente des cas où la nouvelle fonction est déployée suite
+ à la modification d'une table. Dans ce cas là, la nouvelle version
+ doit être déployé de manière synchronisée avec le
+ <command>script d'exécution</command> qui modifie la table.</para>
-<para> Similarly, <command>CREATE TYPE</command>, <command> CREATE
-AGGREGATE </command>, and such will
-commonly not need to be forcibly applied in <quote>perfectly
-synchronized</quote> manner across nodes. </para></listitem>
+<para> De la même manière, les ordres <command>CREATE TYPE</command>, <command> CREATE
+AGGREGATE </command>, etc. n'ont pas besoin d'être forcément insérés de
+manière <quote>parfaitement synchronisés</quote> sur l'ensemble des noeuds.
+</para></listitem>
-<listitem><para> Security management, such as <command> CREATE USER
+<listitem><para> Les ordres de gestion des autorisations, tels que <command> CREATE USER
</command>, <command> CREATE ROLE </command>, <command>GRANT
-</command>, and such are largely irrelevant to &slony1; as it runs as
-a <quote>superuser</quote>. </para>
+</command>, etc. sont inutile pour &slony1; car il est exécuté avec les droits
+de <quote>super-utilisateur</quote>. </para>
-<para> Indeed, we have frequently found it useful to have different
-security arrangements on different nodes. Access to the
-<quote>master</quote> node should be restricted to applications that
-truly need access to it; <quote>reporting</quote> users commonly are
-restricted much more there than on subscriber nodes.</para>
+<para>Dans la pratique, il est utile d'avoir différentes politiques de sécurité
+ sur les noeuds. L'accès au noeud <quote>maître</quote> doit être limité aux
+ applications qui en ont réellement besoin; Les utilisateurs effectuant de
+ l'extraction de données ("reporting") ont généralement des droits plus limités
+ sur le noeud maître que sur les noeuds abonnés.</para>
</listitem>
</itemizedlist>
@@ -358,295 +358,328 @@
</listitem>
-<listitem id="slonyuser"> <para> &slony1;-specific user names. </para>
+<listitem id="slonyuser"> <para> Noms d'utilisateur spécifiques à &slony1;. </para>
-<para> It has proven useful to define a <command>slony</command> user
-for use by &slony1;, as distinct from a generic
-<command>postgres</command> or <command>pgsql</command> user. </para>
+<para> Il s'est avéré utile de définir un utilisateur <command>slony</command> employé
+ uniquement par &slony1;, un utilisateur distinct de l'utilisateur générique
+<command>postgres</command> ou <command>pgsql</command>. </para>
-<para> If all sorts of automatic <quote>maintenance</quote>
-activities, such as <command>vacuum</command>ing and performing
-backups, are performed under the <quote>ownership</quote> of a single
-&postgres; user, it turns out to be pretty easy to run into deadlock
-problems. </para>
+<para> Lorsque toutes sortes d'activités de <quote>maintenance</quote>
+ automatiques, telles que les <command>vacuum</command> et les sauvegardes,
+ sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;
+ , cela peut assez facilement provoquer des problèmes d'inter-blocages ("deadlocks").</para>
-<para> For instance, a series of <command>vacuums</command> that
-unexpectedly run against a database that has a large
-<command>SUBSCRIBE_SET</command> event under way may run into a
-deadlock which would roll back several hours worth of data copying
-work.</para>
+<para> Par exemple, une série de <command>vacuums</command> qui sont
+ lancés de manière inattendue sur une base de donnée avec un gros événement
+ <command>SUBSCRIBE_SET</command> en cours d'exécution pourra entraîner des
+ inter-blocages qui annuleront plusieurs heures de travail de copie de données.
+ </para>
-<para> If, instead, different maintenance roles are performed by
-different users, you may, during vital operations such as
-<command>SUBSCRIBE_SET</command>, lock out other users at the
-<filename>pg_hba.conf</filename> level, only allowing the
-<command>slony</command> user in, which substantially reduces the risk
-of problems while the subscription is in progress.
+<para> À l'inverse, si les différentes opérations de maintenance sont exécutées par
+ différents utilisateurs, vous pourrez assurer la réussite d'une opération vitale
+ telle que <command>SUBSCRIBE_SET</command>, en bloquant les autres utilisateurs
+ au niveau du fichier <filename>pg_hba.conf</filename>, et autorisant uniquement
+ l'utilisateur slony, ce qui réduit considérablement le risque de problèmes lors d'un
+ processus de souscription.
</para>
</listitem>
<listitem>
-<para> Path configuration </para>
+<para> Configuration des chemins</para>
-<para> The section on <link linkend="plainpaths"> Path Communications
-</link> discusses the issues surrounding what network connections need
-to be in place in order for &slony1; to function.</para>
+<para> La section sur les <link linkend="plainpaths"> voies de communications
+</link> évoque les problèmes liés aux connexions réseau nécessaire au
+bon fonctionnement de &slony1;.</para>
</listitem>
-<listitem><para> Lowering Authority </para>
+<listitem><para> Réduction des super-pouvoirs </para>
-<para> Traditionally, it has been stated that <quote>&slony1; needs to
-use superuser connections.</quote> It turns out that this is not
-entirely true, and and if there are particular concerns about
-excessive use of superuser accounts, it is possible to reduce this
-considerably. </para>
+<para> Traditionellement, on considère que <quote>&slony1; a besoin
+ de connexions en mode super-utilisateurs</quote>. Cela n'est pas
+ totalement vrai et si l'usage excessif de comptes super-utilisateurs
+ pose problème, il est possible de réduire nettement cet usage.</para>
-<para> It is true to say that each &lslon; <emphasis>must</emphasis>
-have a superuser connection in order to manage the node that it is
-assigned to. It needs to be able to alter the system catalogue in
-order to set up subscriptions and to process alterations
-(<emphasis>e.g</emphasis> - to run <xref linkend="stmtddlscript"/> and
-other events that may alter the role of replicated tables on the local
-node). </para>
+<para> Il est vrai que chaque &lslon; <emphasis>doit</emphasis>
+avoir une connexion super-utilisateur afin de gérer le noeud dont il opère.
+Il doit pouvoir modifier le catalogue système afin de mettre en place les
+souscriptions et procéder aux modifications
+(<emphasis>par exemple</emphasis> - pour exécuter <xref linkend="stmtddlscript"/> et
+d'autres évènement qui peuvent modifier le rôle d'une tables répliquées sur un noeud
+local). </para>
-<para> However, the connections that &lslon; processes open to other
-nodes to access events and process subcriptions do not need to have
-nearly so much permission. Indeed, one could set up a <quote>weak
-user</quote> assigned to all <xref linkend="stmtstorepath"/> requests.
-The minimal permissions that this user, let's call it
-<command>weakuser</command>, requires are as follows:</para>
+<para> Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres noeuds
+ afin d'accéder aux événements et aux souscriptions n'ont pas besoin d'avoir
+ d'autant de permissions. Ainsi, on peut mettre en place un <quote>utilisateur
+ faible</quote> assigné à toutes les requêtes <xref linkend="stmtstorepath"/>.
+ Les permissions minimales de cet utilisateur, appellons-le
+<command>weakuser</command>, sont les suivantes :</para>
<itemizedlist>
-<listitem><para> It must have read access to the &slony1;-specific namespace </para> </listitem>
-<listitem><para> It must have read access to all tables and sequences in that namespace</para> </listitem>
-<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>
-<listitem><para> At subscribe time, it must have read access to all of the replicated tables. </para>
-<para> Outside of subscription time, there is no need for access to access to the replicated tables. </para> </listitem>
-<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>
+<listitem><para> Il doit avoir accès en lecture sur le namespace spécifique de &slony1;</para> </listitem>
+<listitem><para> Il doit avoir accès en lecture sur toutes les tables et les séquences de ce namespace</para> </listitem>
+<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>
+<listitem><para> Lors de la souscrition, il doit avoir accès en lecture sur toutes les tables répliquées.</para>
+<para> Après la souscription, il n'est plus nécessaire d'accéder aux tables répliquées. </para> </listitem>
+<listitem><para> Il est parfois nécessaire de lire les tables dans pg_catalog; sans qu'on ait pu vérifier
+ à quel niveau d'accès est convenable. </para> </listitem>
</itemizedlist>
-<para> In version 1.3, the tests in the <xref linkend="testbed"/>
-support using a <envar>WEAKUSER</envar> so that testing can regularly
-confirm the minimal set of permissions needed to support
-replication.</para>
+<para> Dans la version 1.3, les tests du <xref linkend="testbed"/>
+permettent l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de
+tester si les permissions définies sont suffisantes pour supporter la réplication.
+</para>
</listitem>
-<listitem><para> The section on <link linkend="listenpaths"> listen
-paths </link> discusses the issues surrounding the table <xref
-linkend="table.sl-listen"/>.</para>
+<listitem><para> La section sur les <link linkend="listenpaths"> voies d'écoute </link>
+ parle des problèmes entourant la table <xref linkend="table.sl-listen"/>.</para>
-<para> As of &slony1; 1.1, its contents are computed automatically
-based on the communications information available to &slony1; which
-should alleviate the problems found in earlier versions where this had
-to be configured by hand. Many seemingly inexplicable communications
-failures, where nodes failed to talk to one another even though they
-technically could, were a result of incorrect listen path
-configuration. </para>
+<para> A partir la version &slony1; 1.1, le contenu de cette table
+ était calculé automatiquement en se basant sur les informations
+ dont disposait &slony1; ce qui devrait supprimer les problèmes
+ rencontrés. Beaucoup de problèmes de communication inexplicables,
+ avec des noeuds qui n'arrive pas à se parler alors que c'est techniquement
+ possible, étaient du à une configuration incorrecte des voies d'écoutes.
+ </para>
</listitem>
-<listitem><para> Use <filename>test_slony_state.pl</filename> to look
-for configuration problems.</para>
+<listitem><para> Utilisez <filename>test_slony_state.pl</filename> pour rechercher
+ les problèmes de configuration.</para>
-<para>This is a Perl script which connects to a &slony1; node and then
-rummages through &slony1; configuration looking for quite a variety of
-conditions that tend to indicate problems, including:
+<para>Il s'agit d'un script Perl qui se connecte à un noeud &slony1; puis
+ parcours la configuration &slony1; à la recherche de différentes conditions
+ qui indique la présence de problèmes, en particulier :
<itemizedlist>
-<listitem><para>Bloating of some config tables</para></listitem>
-<listitem><para>Analysis of listen paths</para></listitem>
-<listitem><para>Analysis of event propagation and confirmation</para></listitem>
+<listitem><para>le gonflement de certaines tables de congfiguration;</para></listitem>
+<listitem><para>l'analyse des voies d'écoute;</para></listitem>
+<listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
</itemizedlist></para>
-<para> If replication mysteriously <quote>isn't working</quote>, this
-tool can run through many of the possible problems for you. </para>
+<para> Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>, cet outil
+ peut vérifier beaucoup de problèmes potentiels pour vous. </para>
</listitem>
<listitem>
-<para> Configuring &lslon; </para>
+<para> Configurer &lslon; </para>
-<para> As of version 1.1, &lslon; configuration may be
-drawn either from the command line or from configuration files.
-<quote>Best</quote> practices have yet to emerge from the two
-options:</para>
-</listitem>
-</itemizedlist>
+<para> A partir de la version 1.1, la configuration de &lslon;
+peut être définie par ligne de commande ou dans des fichiers de
+configuration. De <quote>bonnes</quote> pratiques sont
+conseillédans les deux cas :
+</para>
<itemizedlist>
<listitem>
-<para> Configuration via command line options</para>
+<para> Configuration via les options en ligne de commande</para>
-<para> This approach has the merit that all the options that are
-active are visible in the process environment. (And if there are a
-lot of them, they may be a nuisance to read.)</para>
+<para> Cette approche à le mérite de rendre visible dans
+l'environnement système toutes les options actives.
+( Ainsi s'il y en a beaucoup cela peut devenir pénible
+à lire )</para>
-<para> Unfortunately, if you invoke &lslon; from the
-command line, you could <emphasis>forget</emphasis> to include
-&logshiplink; configuration and thereby destroy the sequence of logs
-for a log shipping node. </para>
+<para>Malheureusement, si vous invoquer &lslon; à partir d'une
+ligne de commande, vous pouvez <emphasis>oublier</emphasis> d'inclure
+la configuration de &logshiplink; et ainsi détruire les
+séquences de logs pour les noeuds de log shipping.</para>
</listitem>
-<listitem> <para> Unlike when command line options are used, the
-active options are <emphasis>not</emphasis> visible. They can only be
-inferred from the name and/or contents of the &lslon;
-configuration file, and will not reflect subsequent changes to the
-configuration file. </para>
+<listitem> <para> A la différence des options en ligne de
+commande les options actives ne sont <emphasis>pas</emphasis> visible.
+Elles peuvent seulement être positionnées à partir u nom
+et du contenu du fichier de configuration de &lslon;, et ne
+refléteront pas les changements apparus dans le fichier de
+configuration.
+</para>
-<para> By putting the options in a file, you won't forget including
-any of them, so this is safer for &logshiplink;. </para>
+<para> En plaçant les options dans un fichier, vous n'oublierez
+aucune, ce qui est plus sur pour &logshiplink;. </para>
</listitem>
</itemizedlist>
-<itemizedlist>
+</listitem>
-<listitem><para> Things to do when subscribing nodes </para>
+<listitem><para> Taches à faire loque l'on abonne un noeud </para>
-<para> When a new node is running the <command>COPY_SET</command>
-event for a large replication set (<emphasis>e.g.</emphasis> - one
-which takes several hours to subscribe) it has been found to be
-desirable to lock all users other than the <command>slony</command>
-user out of the new subscriber because:
+<para> Lorsqu'un nouveau noeud exécute l'événement <command>COPY_SET</command>
+sur un grand ensemble de réplication (<emphasis>par
+exemple</emphasis> - un ensemble qui nécessite un abonnement de
+plusieurs heures) il est prouvé qu'il est souhaitable de
+verrouiller l'accès au noeud pour tous les utilisateurs
+autres que <command>slony</command> car :
</para>
</listitem>
-</itemizedlist>
+
<itemizedlist>
-<listitem><para> Applications will run into partially-copied,
-half-baked data that is not totally consistent. </para> </listitem>
+<listitem><para> Les applications s'exécutent sur des
+données partiellemen copiées qui ne seront pas
+consistantes.
+</para> </listitem>
-<listitem><para> It is possible for applications (and maintenance
-scripts) to submit combinations of queries that will get the system
-into a deadlock situation, thereby terminating the
-<command>COPY_SET</command> event, and requiring the subscription to
-start over again. </para> </listitem>
+<listitem><para>Il est possible que certaines applications (et
+certains scripts de maintenance) soumettent une combinaison
+de requêtes qui placeront le système dans une situation
+d'inter-blocage ("deadlock"), ce qui annulera l'événement
+<command>COPY_SET</command>, et impliquera le ré-abonnement
+complet du noeud.</para> </listitem>
</itemizedlist>
-<para> It <emphasis>may</emphasis> be worth considering turning the
-&postgres; <function>fsync</function> functionality off during the
-copying of data, as this will improve performance, and if the database
-<quote>falls over</quote> during the <command>COPY_SET</command>
-event, you will be restarting the copy of the whole replication
-set.</para>
+<para> Il <emphasis>peut</emphasis> être intéressant de
+désactive la fonctionnalité<function>fsync</function> de &postgres;
+pendant le copie des données, car cela améliorera les
+performances,
+et en cas d'échec lors de l'évènement
+<command>COPY_SET</command>,
+vous pourrez redémarrer avec un copie entière de
+l'ensemble de réplication.</para>
-<itemizedlist>
-<listitem><para> Managing use of slonik </para>
-<para> The notes on <link linkend="usingslonik"> Using Slonik </link>
-describe some of the lessons learned from managing large numbers of
-<xref linkend="slonik"/> scripts.</para>
+<listitem><para> Gestion de slonik </para>
-<para> Notable principles that have fallen out of generating many
-slonik scripts are that:
+<para> Les notes sur <link linkend="usingslonik">l'utilisation de
+Slonik </link> décrivent certaines lessons apprises en
+gérant un grand nombre de scripts <xref linkend="slonik"/>.</para>
+<para> Voici les principes importants se sont dégagés lors de
+la création de ces scripts :
+
<itemizedlist>
-<listitem><para>Using <quote>preamble</quote> files is
-<emphasis>highly recommended</emphasis> as it means that you use
-heavily-verified preambles over and over.</para></listitem>
+<listitem><para>Utiliser des fichiers <quote>préambule</quote>
+est <emphasis>hautement recommandé</emphasis> car cela implique
+que vous utilisiez et réutilisiez des
+préambules vérifié maintes fois.</para></listitem>
-<listitem><para>Any opportunity that you have to automatically
-generate configuration whether by drawing it from a database or by
-using a script that generates repetitively similar elements will help
-prevent human error.</para></listitem>
+<listitem><para>Toute opportunité de générer automatiquement
+la configuration soit en la récpérant dans une base de
+données, soit en utilisant un script de génération vous
+aidera à éviter les erreurs humaines.</para></listitem>
</itemizedlist>
</para>
</listitem>
-<listitem><para> Handling Very Large Replication Sets </para>
+<listitem><para>Gèrer un très grand ensemble de réplication</para>
-<para> Some users have set up replication on replication sets that are
-tens to hundreds of gigabytes in size, which puts some added
-<quote>strain</quote> on the system, in particular where it may take
-several days for the <command>COPY_SET</command> event to complete.
-Here are some principles that have been observed for dealing with
-these sorts of situations.</para></listitem>
+<para> Certains utilisateurs ont bâti des réplications sur des
+ ensembles de plusieurs dizaines, voire plusieurs centaines de
+ gigabytes, ce qui ajoute des <quote>contraintes</quote> sur le
+système, n particulier lorsqu'il faut plusieurs jours pour
+ effectuer un évènement <command>COPY_SET</command>.
+ Voici quelques principes qui ont été définis
+ pour gérer ce genre de situations.</para></listitem>
-</itemizedlist>
+
<itemizedlist>
-<listitem><para> Drop all indices other than the primary key index
-while the <command>COPY_SET</command> event is run. </para>
+<listitem><para> Supprimer tous les index autres que les index
+primaire lorsque l'évènement en<command>COPY_SET</command>
+est exécuté. </para>
-<para> When data is copied into a table that has indices on it,
-&postgres; builds the indices incrementally, on the fly. This is much
-slower than simply copying the data into the table, and then
-recreating each index <quote>ex nihilo</quote>, as the latter can take
-substantial advantage of sort memory. </para>
+<para> Lorsque les données sont copiées dans une table qui
+dispose d'index, &postgres; construit les index de manière
+incrémentale, à la vole.
+Ceci est beaucoup plus lent que simplement copier les donnés
+dans une table puis de recréerchaque index <quote>ex
+nihilo</quote>,
+car cette dernière opération profite de l'avantage de la
+mémoire de tri. </para>
-<para> In &slony1; version 1.1.5 and later versions, indices are
-dropped and recreated automatically, which effectively invalidates
-this practice.</para>
+<para> Dans &slony1; version 1.1.5 et dans les versions
+ultérieures, les index sont supprimés et
+recréés automatiquement, ce qui rend caduque ce
+conseil.
+</para>
</listitem>
-<listitem><para> If there are large numbers of updates taking place as
-the large set is being copied, this can lead to the subscriber being
-behind by some enormous number of <command>SYNC</command> events.</para>
+<listitem><para> Si beaucoup de mises à jour ont lieu lorsque de
+grands ensemble sont copiés, ceci peut mener à un nombre
+énormed'événements<command>SYNC</command> sur le
+noeud qui s'abonne.</para>
-<para> If a <command> SYNC </command> is generated about once per
-second, that leads to the subscriber <quote>falling behind</quote> by
-around 90,000 <command>SYNC</command>s per day, possibly for several
-days. </para>
+<para>Si un <command> SYNC </command> est généré
+une fois par seconde, ceci conduit à un <quote>retard</quote>
+ de plus de 90,000 <command>SYNC</command>s par jour, pendant
+ probablement plusieurs jours. </para>
-<para> There will correspondingly be an <emphasis>enormous</emphasis>
-growth of <xref linkend="table.sl-log-1"/> and <xref
-linkend="table.sl-seqlog"/>. Unfortunately, once the
-<command>COPY_SET</command> completes, users have found that the
-queries against these tables wind up reverting to <command>Seq
-Scans</command> so that even though a particular
-<command>SYNC</command> processing event is only processing a small
-number of those 90,000 <command>SYNC</command> events, it still reads
-through the entire table. In such a case, you may never see
-replication catch up.
+<para>Parallèlement
+on constatera une croissance <emphasis>énorme</emphasis>
+des tables <xref linkend="table.sl-log-1"/> et <xref
+linkend="table.sl-seqlog"/>.
+Malheureusement, une fois que <command>COPY_SET</command>
+est complété, on constate que les requêtes sur
+ces tables se font via <command>seq scans</command>,
+mémé si le <command>SYNC</command> ne traite qu'une petite
+partie de ces 90 000 événements<command>SYNC</command>
+la table sera lue dans son ensemble. Dans de tel cas, il
+est possible que le noeud abonné ne rattrape
+jamais le noeud origine.
</para>
-<para> Several things can be done that will help, involving
-careful selection of &lslon; parameters:</para>
+<para> Plusieurs taches peuvent résoudre ce problème,
+notamment en réglant avec soin les paramètres
+&lslon; :</para>
</listitem>
</itemizedlist>
<itemizedlist>
-<listitem><para> Ensure that there exists, on the
-<quote>master</quote> node, an index on <function> sl_log_1(log_xid)
-</function>. If it doesn't exist, as the &slony1; instance was set up
-before version 1.1.1, see <filename> slony1_base.sql </filename> for
-the exact form that the index setup should take. </para>
+<listitem><para>Assurez-vous qu'il existe sur le noeud
+<quote>maître</quote>, un index sur <function> sl_log_1(log_xid)
+</function>.
+S'il n'y en a pas, comme avec les versions de &slony1;
+inférieure à la version 1.1.1, regardez dans le fichier
+<filename> slony1_base.sql </filename> pour
+la configuration correcte de cet index. </para>
-<para> In 1.2 and later versions, there is a process that runs
-automatically to add partial indexes by origin node number, which
-should be the optimal form for such an index to take. </para>
+<para> Dans les versions 1.2 et suivantes, il y a un processus
+qui ajoute automatiquement les index partiels par numéro de
+noeud
+d'origine, ce qui est la forme optimale pour ces index.
+</para>
</listitem>
-<listitem><para> On the subscriber's &lslon;, increase
-the number of <command>SYNC</command> events processed together, with
-the <xref linkend= "slon-config-sync-group-maxsize"/> parameter to some
-value that allows it to process a significant portion of the
-outstanding <command>SYNC</command> events. </para> </listitem>
+<listitem><para>Sur un noeud abonné, ajouter le nombres
+d'évènements<command>SYNC</command>
+traités ensemble, en réglant le paramètre
+<xref linkend= "slon-config-sync-group-maxsize"/>
+à une valeur lui permettant une portion significative
+de la masse d'événements <command>SYNC</command>.
+</para> </listitem>
-<listitem><para> On the subscriber's &lslon;, set the
-<xref linkend="slon-config-desired-sync-time"/> to 0, as the adaptive
-<command>SYNC</command> grouping system will start with small
-groupings that will, under these circumstances, perform
-poorly. </para> </listitem>
+<listitem><para>Sur le noeud abonné, régler le paramètre
+<xref linkend="slon-config-desired-sync-time"/>
+à 0, car le système de regroupent adaptatif des
+<command>SYNC</command>
+fonctionne a avec de petits groupes, qui sous certaines
+circonstances, donne de mauvaises performances.
+</para> </listitem>
-<listitem><para> Increase the <xrefls
-linkend="slon-config-sync-interval"/> on the origin's <xref
-linkend="slon"/> so that <command>SYNC</command> events are generated
-less frequently. If a <command>SYNC</command> is only generated once
-per minute instead of once per second, that will cut down the number
-of events by a factor of 60. </para> </listitem>
+<listitem><para> Augmenter le
+<xrefls linkend="slon-config-sync-interval"/>
+sur le noeud origine <xref linkend="slon"/>
+afin que les événement<command>SYNC</command>
+soit générés moins fréquemment.
+Si un <command>SYNC</command> est simplement
+généré
+une fois par minute plutôt qu'une fois par seconde, cela
+divisera par soixante le nombre d'évènements.
+</para> </listitem>
+
</itemizedlist>
-<itemizedlist>
-<listitem><para> It is likely to be worthwhile to use <xref
-linkend="slon-config-vac-frequency"/> to deactivate <xref
-linkend="slon"/>-initiated vacuuming in favor of running your own
-vacuum scripts, as there will be a buildup of unpurgeable data while
-the data is copied and the subscriber starts to catch up. </para>
+<listitem><para> Il faudra probablement utiliser le
+<xref linkend="slon-config-vac-frequency"/> pour
+désactiver les vacuum lancés par<xref linkend="slon"/>
+afin d'utiliser vos propres scripts de vacuum,
+car il y aura un masse de données non-purgeables pendant
+que les données seront copiées et
+que l'abonné commencera à rattraper le fournisseur.
+</para>
</listitem>
</itemizedlist>
More information about the Trad
mailing list