[Trad] [svn:pgfr] r1506 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 18 Mai 22:47:28 CEST 2010
Author: gleu
Date: 2010-05-18 22:47:28 +0200 (Tue, 18 May 2010)
New Revision: 1506
Modified:
traduc/trunk/slony/faq.xml
Log:
Fin de la traduction de la FAQ de Slony :)
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2010-05-17 20:16:48 UTC (rev 1505)
+++ traduc/trunk/slony/faq.xml 2010-05-18 20:47:28 UTC (rev 1506)
@@ -598,31 +598,30 @@
</qandadiv>
<qandadiv id="faqimpossibilities">
- <title>&slony1; FAQ: Impossible Things People Try</title>
+<title>FAQ &slony1; : ce que les gens testent mais ne devraient pas</title>
<qandaentry>
<question>
<para>
- Can I use &slony1; to replicate changes back and forth on my database
- between my two offices?
+ Puis-je utiliser &slony1; pour fait du multi-maître ?
</para>
</question>
<answer>
<para>
- At one level, it is <emphasis>theoretically possible</emphasis> to do
- something like that, if you design your application so that each office
- has its own distinct set of tables, and you then have some system for
- consolidating the data to give them some common view. However, this
- requires a great deal of design work to create an application that
- performs this consolidation.
+ À un simple niveau, il est <emphasis>théoriquement possible</emphasis>
+ de le faire si vous concevez votre application de façon à ce que chaque
+ maître a son propre ensemble distinct de tables et que vous disposiez
+ d'un moyen pour consolider les données et qu'elles aient une vue
+ commune. Néanmoins, ceci requiert une grande attention dans la création
+ de l'application pour réaliser cette consolidation.
</para>
</answer>
<answer>
<para>
- In practice, the term for that is <quote>multimaster replication,</quote>
- and &slony1; does not support <quote>multimaster replication.</quote>.
+ En pratique, le terme utilisé est <quote>réplication multi-maître</quote>
+ et &slony1; ne permet pas de le faire.
</para>
</answer>
</qandaentry>
@@ -630,22 +629,24 @@
<qandaentry>
<question>
<para>
- I want to replicate all of the databases for a shared-database system
- I am managing. There are multiple databases, being used by my
- customers.
+ Je veux répliquer toutes les bases de données d'un système partagé que
+ je gère. Il existe plusieurs bases de données, utilisées par mes
+ clients.
</para>
</question>
<answer>
<para>
- For this purpose, something like &postgres; PITR (Point In Time
- Recovery) is likely to be much more suitable. &slony1; requires a slon
- process (and multiple connections) for each identifiable database, and
- if you have a &postgres; cluster hosting 50 or 100 databases, this will
- require hundreds of database connections. Typically, in <quote>shared
- hosting</quote> situations, DML is being managed by customers, who can
- change anything they like whenever <emphasis>they</emphasis> want.
- &slony1; does not work out well when not used in a disciplined manner.
+ Pour cela, une méthode comme PITR (Point In Time Recovery) proposée par
+ &postgres; semble mieux convenir. &slony1; nécessite un démon (et
+ plusieurs connexions pour chaque base de données identifiables. Si vous
+ avez une instance &postgres; comprenant 50 ou 100 bases de données, cela
+ va nécessiter des centaines de connexions aux bases. Typiquement, dans
+ des situations d'<quote>hébergement partagé</quote>, les modifications
+ de schéma sont gérées par les clients qui peuvent changer tout ce qu'ils
+ souhaitent quand <emphasis>ils</emphasis> le souhaitent.
+ &slony1; ne fonctionne pas bien lorsqu'il est utilisé d'une manière non
+ discipliné.
</para>
</answer>
</qandaentry>
@@ -653,25 +654,25 @@
<qandaentry>
<question>
<para>
- I want to be able to make DDL changes, and have them replicated
- automatically.
+ Je veux pouvoir faire des modifications de structure de ma base et que
+ ces modifications soient automatiquement répliquées.
</para>
</question>
<answer>
<para>
- &slony1; requires that <xref linkend="ddlchanges"/> be planned for
- explicitly and carefully. &slony1; captures changes using triggers,
- and &postgres; does not provide a way to use triggers to capture DDL
- changes.
+ &slony1; requiert que les <xref linkend="ddlchanges"/> soit préparées
+ avec attention. &slony1; capture les modifications en utilisant des
+ triggers et &postgres; ne fournit aucun moyen pour capturer des
+ modifications de schéma par des triggers.
</para>
<note>
<para>
- There has been quite a bit of discussion, off and on, about how
- &postgres; might capture DDL changes in a way that would make triggers
- useful; nothing concrete has emerged after several years of
- discussion.
+ Il y a eu des discussions sur ce sujet pour essayer de faire en sorte
+ que &postgres; puisse récupérer les modifications de schéma d'une
+ façon qui permettrait l'utilisation de triggers ; rien de concret
+ n'est apparu depuis cette discussion qui date de quelques années.
</para>
</note>
</answer>
@@ -680,18 +681,18 @@
<qandaentry>
<question>
<para>
- I want to split my cluster into disjoint partitions that are not aware
- of one another. &slony1; keeps generating <xref
- linkend="listenpaths"/> that link those partitions together.
+ Je veux diviser mon cluster en partitions disjointes qui ne sont pas
+ conscientes des autres. &slony1; continue à générer les <xref
+ linkend="listenpaths"/> qui lient les partitions entre elles.
</para>
</question>
<answer>
<para>
- The notion that all nodes are aware of one another is deeply imbedded
- in the design of &slony1;. For instance, its handling of cleanup of
- obsolete data depends on being aware of whether any of the nodes are
- behind, and thus might still depend on older data.
+ Le fait que tous les nœuds sont conscients des autres est intégré
+ profondément dans le design de &slony1;. Par exemple, sa gestion du
+ nettoyage des données obsolètes dépend de la connaissance du lag des
+ autres nœuds.
</para>
</answer>
</qandaentry>
@@ -699,17 +700,18 @@
<qandaentry>
<question>
<para>
- I want to change some of my node numbers. How do I
- <quote>rename</quote> a node to have a different node number?
+ Je veux changer certains des numéros de nœuds. Comment puis-je
+ <quote>renommer</quote> un n&elig;ud pour avoir un différent numéro de
+ nœud ?
</para>
</question>
<answer>
<para>
- You don't. The node number is used to coordinate inter-node
- communications, and changing the node ID number <quote>on the fly</quote>
- would make it essentially impossible to keep node configuration
- coordinated.
+ Vous ne pouvez pas. Le numéro de nœud est utilisé pour coordonner
+ les communications inter-nœuds. Changer le numéro de nœud
+ <quote>en ligne</quote> pourrait rendre impossible la coordination de
+ la configuration du nœud.
</para>
</answer>
</qandaentry>
@@ -717,36 +719,38 @@
<qandaentry>
<question>
<para>
- My application uses OID attributes; is it possible to replicate tables
- like this?
+ Mon application utilise les attributs OID ; est-il possible de
+ répliquer ce type de tables ?
</para>
</question>
<answer>
<para>
- It is worth noting that oids, as a regular table attribute, have been
- deprecated since &postgres; version 8.1, back in 2005. &slony1; has
- <emphasis>never</emphasis> collected oids to replicate them, and, with
- that functionality being deprecated, the developers do not intend to
- add this functionality.
+ Il est intéressant de noter que les OID, comme attribut d'une table
+ utilisateur, ont été rendus obsolètes depuis la version 8.1 de
+ &postgres;, autrement dit depuis 2005. &slony1; n'a
+ <emphasis>jamais</emphasis> utilisé les OID pour la réplication. Cette
+ fonctionnalité étant devenu obsolète, les développeurs n'ont aucune
+ intention d'ajouter son utilisation.
</para>
<para>
- &postgres; implemented oids as a way to link its internal system tables
- together; to use them with application tables is considered
- <emphasis>poor practice</emphasis>, and it is recommended that you use
- sequences to populate your own ID column on application tables.
+ &postgres; a implémenté les OID pour lier les catalogues systèmes
+ entre eux ; les utiliser avec les tables utilisateurs est
+ considéré comme une <emphasis>mauvaise pratique</emphasis>, et il est
+ recommandé d'utiliser une séquence pour peupler votre colonne
+ d'identifiant dans les tables utilisateurs.
</para>
</answer>
<answer>
<para>
- Of course, nothing prevents you from creating a table
- <emphasis>without</emphasis> oids, and then add in your own application
- column called <envar>oid</envar>, preferably with type information
- <command>SERIAL NOT NULL UNIQUE</command>, which
- <emphasis>can</emphasis> be replicated, and which is likely to be
- suitable as a candidate primary key for the table.
+ Bien sûr, rien ne vous empêcher de créer une table
+ <emphasis>sans</emphasis> OID, puis d'ajouter votre propre colonne
+ appelée <envar>oid</envar>, de préférence avec l'information
+ <command>SERIAL NOT NULL UNIQUE</command>, qui
+ <emphasis>peut</emphasis> être répliquée, et qui peut être utilisé
+ comme clé primaire pour la table.
</para>
</answer>
</qandaentry>
Plus d'informations sur la liste de diffusion Trad