[Trad] [svn:pgfr] r1503 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Sam 15 Mai 22:17:20 CEST 2010
Author: gleu
Date: 2010-05-15 22:17:20 +0200 (Sat, 15 May 2010)
New Revision: 1503
Modified:
traduc/trunk/slony/adminscripts.xml
traduc/trunk/slony/dropthings.xml
traduc/trunk/slony/faq.xml
traduc/trunk/slony/intro.xml
traduc/trunk/slony/legal.xml
traduc/trunk/slony/prerequisites.xml
traduc/trunk/slony/slonik_ref.xml
traduc/trunk/slony/slonyupgrade.xml
traduc/trunk/slony/supportedplatforms.xml
Log:
Mise ?\195?\160 jour en version 2.0.3.
Reste encore le fichier faq.xml qui n'est pas enti?\195?\168rement traduit.
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/adminscripts.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -250,6 +250,18 @@
</sect3>
+<sect3 id="slonik-drop-sequence">
+<title>slonik_drop_sequence</title>
+
+<para>
+ Cette commande produit un script Slonik pour supprimer une séquence de la
+ réplication. Est requis en entrée l'identifiant de la séquence (disponible à
+ partir de la table <envar>sl_table</envar>) qui est à supprimer et
+ l'identifiant de l'ensemble auquel elle est attachée.
+</para>
+
+</sect3>
+
<sect3>
<title>slonik_execute_script</title>
@@ -1396,4 +1408,5 @@
</para>
</sect2>
+
</sect1>
Modified: traduc/trunk/slony/dropthings.xml
===================================================================
--- traduc/trunk/slony/dropthings.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/dropthings.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -113,7 +113,7 @@
</sect2>
<sect2>
-<title> Retirer une table de la réplication</title>
+<title>Retirer une table de la réplication</title>
<indexterm><primary>retirer une table de la réplication</primary></indexterm>
<sect3>
@@ -121,12 +121,15 @@
<para>
Si les outils <link linkend="altperl">altperl</link> sont installés, vous
- pouvez utiliser le script d'aide <link
- linkend="slonik-drop-table">slonik_drop_table</link> pour supprimer une table
- dans un ensemble de réplication. Lancez simplement
- <command>slonik_drop_table</command> sans arguments pour afficher la méthode
- d'utilisation du script. Après avoir retiré la table, vous devez également la
- retirer du fichier <filename>slon_tools.conf</filename>.
+ pouvez utiliser les scripts d'aide <link
+ linkend="slonik-drop-table">slonik_drop_table</link> et <link
+ linkend="slonik-drop-sequence">slonik_drop_sequence</link> pour supprimer
+ une table ou une séquence de la réplication. Exécutez simplement
+ <command>slonik_drop_table</command> (ou
+ <command>slonik_drop_sequence</command>) sans arguments pour afficher
+ la syntaxe d'exécution du script. Après avoir supprimé la table, vous devez
+ aussi la supprimer du fichier de configuration
+ <filename>slon_tools.conf</filename>.
</para>
</sect3>
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/faq.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -421,6 +421,28 @@
</para>
</answer>
</qandaentry>
+
+<qandaentry>
+
+<question> <para> I found conflicting types for <envar>yyleng</envar>
+between <filename>parser.c</filename> and <filename>scan.c</filename>.
+In one case, it used type <type>int</type>, conflicting with
+<type>yy_size_t</type>. What shall I do?</para> </question>
+
+<answer><para> This has been observed on <application>MacOS</application>,
+where <application>flex</application> (which generates
+<filename>scan.c</filename>) and <application>bison</application>
+(which generates <filename>parser.c</filename>) diverged in their
+handling of this variable. </para>
+<itemizedlist>
+<listitem><para> You might might <quote>hack</quote> <filename>scan.c</filename> by hand to use the matching type. </para> </listitem>
+<listitem><para> You might select different versions of <application>bison</application> or <application>flex</application> so as to get versions whose data types match. </para> </listitem>
+<listitem><para> Note that you may have multiple versions of <application>bison</application> or <application>flex</application> around, and might need to modify <envar>PATH</envar> in order to select the appropriate one.</para></listitem>
+</answer>
+
+
+
+</qandaentry>
</qandadiv>
<qandadiv id="faqhowto"> <title> &slony1; FAQ: How Do I? </title>
@@ -1933,6 +1955,78 @@
</para>
</answer>
</qandaentry>
+
+<qandaentry>
+
+<question> <para>As of version 8.3, &postgres; offers a
+<envar>synchronous_commit</envar> parameter which may be set either
+via GUC or <filename>postgresql.conf</filename> which can provide some
+performance gains by not logging results in WAL. Would it be sensible
+to turn off synchronous commit on a subscriber node? </para>
+</question>
+
+<answer><para> Unfortunately, there is an unpleasant failure case
+which this would introduce. </para>
+
+<para>Consider...</para>
+
+<itemizedlist>
+
+<listitem><para> Node #2 claims to have committed up to transaction
+T5, but the WAL only really has records up to T3.</para></listitem>
+
+<listitem><para> Node #1, the "master", got the report back that #2 is
+up to date to T5.</para></listitem>
+
+<listitem><para> Node #2 experiences a failure (e.g. - power
+outage).</para></listitem>
+
+</itemizedlist>
+
+<para>There are two possible outcomes, now, one OK, and one not so OK...</para>
+
+<itemizedlist>
+
+<listitem><para> OK </para>
+
+<para> Node #2 gets restarted, replays WAL, knows it's only got data
+up to T3, and heads back to node #1, asking for transaction T4 and
+others.</para>
+
+<para> No problem.</para></listitem>
+
+<listitem><para> Not so OK.</para>
+
+<para> Before node #2 gets back up, node #1 has run an iteration of
+the cleanup thread, which trims out all the data up to T5, because the
+other nodes confirmed up to that point.</para>
+
+<para> Node #2 gets restarted, replays WAL, knows it's only got data
+up to T3, and heads back to node #1, asking for transaction T4 and
+T5.</para>
+
+<para> Oops. Node #1 just trimmed those log entries
+out.</para></listitem>
+</itemizedlist>
+
+<para>The race condition here is quite easy to exercise - you just
+need to suppress the restart of node 2 for a while, long enough for
+node 1 to run the cleanup thread.</para>
+
+<para>You might evade the problem somewhat by setting the &lslon; parameter
+<xref linkend="slon-config-cleanup-interval"/> to a larger value.</para>
+
+<para>Unfortunately, any time the outage of node 2 could exceed that
+interval, the risk of losing log data inexorably emerges.</para>
+
+</answer>
+
+<answer><para> As a result, it cannot be recommended that users run
+&slony1; in a fashion where it suppresses WAL writing via
+<envar>synchronous_commit</envar>. </para> </answer>
+
+</qandaentry>
+
</qandadiv>
<qandadiv id="faqperformance">
Modified: traduc/trunk/slony/intro.xml
===================================================================
--- traduc/trunk/slony/intro.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/intro.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -231,12 +231,15 @@
jour sur les tables répliquées à l'exception de celles effectuées par le
processus <xref linkend="slon"/>. De plus, tous les
<emphasis>autres</emphasis> triggers et règles sur les tables répliquées sont
- <emphasis>supprimés</emphasis> sur les nœuds abonnés ; ceci est
- réalisé en faisant pointer ces tables, dans le catalogue système, vers les
- index des clefs primaires plutôt que sur la table elle-même. Cela s'apparente
- à une <quote>corruption</quote> du dictionnaire de données, et cela explique
- pourquoi on ne peut pas utiliser directement <application>pg_dump</application>
- pour exporter le schéma sur les nœuds abonnés.
+ <emphasis>supprimés</emphasis> sur les nœuds abonnés. Sur les versions
+ de &slony1; antérieures à la 2.0, cela se fait en les pointant, dans la table
+ système, vers l'index de la clé primaire au lieu de la table elle-même, ce
+ qui représente une <quote>corruption</quote> du dictionnaire des données et
+ qui explique pourquoi vous ne devez pas utiliser directement
+ <application>pg_dump</application> pour sauvegarder les schémas sur les
+ abonnés. En version 2.0, cette fonctionnalité est gérée via une fonctionnalité
+ native de &postgres;. Du coup, avec &slony1; 2.0+,
+ <application>pg_dump</application> doit fonctionner correctement.
</para>
<para>
@@ -278,6 +281,12 @@
</itemizedlist>
</para>
+<para>
+ &slony1; ne détermine pas automatiquement les séquences devant être
+ répliquées ; vous devez les ajouter explicitement en utilisant <xref
+ linkend="stmtsetaddsequence"/>.
+</para>
+
</sect2>
<sect2>
Modified: traduc/trunk/slony/legal.xml
===================================================================
--- traduc/trunk/slony/legal.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/legal.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -5,7 +5,7 @@
révision $Revision$ -->
<copyright>
- <year>2004-2007</year>
+ <year>2004-2009</year>
<holder>The PostgreSQL Global Development Group</holder>
</copyright>
@@ -13,7 +13,7 @@
<title>Notice légale</title>
<para>
- <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2007
+ <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2009
du PostgreSQL Global Development Group et est distribué sous les termes
de la licence de l'Université de Californie ci-dessous.
</para>
Modified: traduc/trunk/slony/prerequisites.xml
===================================================================
--- traduc/trunk/slony/prerequisites.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/prerequisites.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -61,49 +61,9 @@
<para>
Vous avez également besoin d'une version <emphasis>source</emphasis>
récente de &postgres;. &slony1; dépend du support des schémas, ce qui
- nécessite au minimum une version 7.3.3 de &postgres; pour pouvoir
- compiler et utiliser &slony1;.
+ nécessite au minimum une version 8.3 de &postgres; pour pouvoir
+ compiler et utiliser &slony1;.
</para>
-
- <para>
- Les versions antérieures de &postgres; <emphasis>ne sont pas</emphasis>
- supportées, mais notez qu'un utilisateur a réussi à <quote>forcer</quote>
- l'utilisation de &slony1; dans le cadre d'une migration d'une version
- 7.2 vers une version 7.4 ; voir les <link linkend="v72upgrade">notes
- sur &postgres; 7.2</link>.
- </para>
-
- <para>
- Les versions de &postgres; antérieures à la 7.4.8 peuvent rencontrer
- une requête sans fin conduisant à un problème de <link
- linkend="dupkey"><quote>duplicate keys</quote></link> (clés dupliquées),
- vous devrez alors envisager une mise à jour pour éviter ce type d'erreur.
- </para>
-
- <para>
- Si vous utiliser une version de &postgres; antérieure à la version 8.0,
- vous devez vous assurer que les fichiers d'en-tête de serveur sont
- installés. Si vous installez depuis les sources, cela se fait par la
- commande <command>make install-all-headers</command>. Sinon, vous
- rencontrerez le problème <link linkend="missingheaders">missing headers
- for libpqserver</link> (en-têtes manquants pour libpqserver), comme
- décrit dans la FAQ.
- </para>
-
- <para>
- Si vous utilisez les versions 8.1.0 à 8.1.3, un bogue (corrigé en
- 8.1.4) empêche la fonction <xref linkend="stmtupdatefunctions"/>
- de s'exécuter correctement. Pour plus de détails, voir
- <xref linkend="faq" />, <link linkend="pg81funs">&postgres;
- 8.1.[0-3]</link>.
- </para>
-
- <para>
- Certaines versions de &postgres; ne sont pas compatibles avec certaines
- versions de &slony1;. Voir <xref linkend="installation"/> pour plus de
- détails.
- </para>
-
</listitem>
<listitem>
@@ -140,9 +100,9 @@
<para>
Sous &windows;, vous aurez aussi besoin de la boîte à outils <ulink
url="http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">MinGW/
- Msys</ulink> pour compiler les versions 8.0 et supérieures de
- &postgres;. De plus, vous devez installer <ulink
- url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
+ Msys</ulink> pour compiler les versions 8.3 et supérieures de
+ &postgres;. De plus, vous devez installer <ulink
+ url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
</para>
</listitem>
</itemizedlist>
@@ -156,9 +116,8 @@
<note>
<para>
- À partir de la version 1.1 de &slony1;, il est possible de compiler &slony1;
- séparemment de &postgres;, rendant libres les distributions
- <productname>Linux</productname> et
+ Il est possible de compiler &slony1; séparemment de &postgres;, rendant
+ libres les distributions <productname>Linux</productname> et
<productname>FreeBSD</productname> d'inclure des packages binaires
précompilés pour &slony1;. Si de tels packages ne sont pas disponibles,
vous devez vous préparer à compiler &slony1; par vous-même.
@@ -198,13 +157,6 @@
</para>
<para>
- Dans la version 8.1 de &postgres;, des modifications ont été apportées à
- l'encodage <envar>UNICODE</envar> car les versions précédentes acceptaient
- des encodages invalides. Cela pouvait conduire à des <link
- linkend="faqunicode">problèmes de replication</link>.
-</para>
-
-<para>
Notez que si l'encodage client (configuré soit dans
<filename>postgresql.conf</filename>, soit par le paramètre
<envar>client_encoding</envar>, soit par la commande
Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/slonik_ref.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -505,8 +505,11 @@
</varlistentry>
<varlistentry><term><literal>EVENT NODE = ival</literal></term>
- <listitem><para>L'identifiant du nœud utilisé pour créer l'événement de configuration,
- qui prévient tous les nœuds existants de l'arrivée du nouveau nœud.
+ <listitem>
+ <para>L'identifiant du nœud utilisé pour créer l'événement de configuration,
+ qui prévient tous les nœuds existants de l'arrivée du nouveau
+ nœud. Ça doit être l'identifiant d'un nœud pré-existant dans
+ le cluster, pas l'identifiant du nouveau nœud.
</para></listitem>
</varlistentry>
</variablelist>
@@ -517,7 +520,7 @@
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
- STORE NODE ( ID = 2, COMMENT = 'Nœud 2');
+ STORE NODE ( ID = 2, COMMENT = 'Node 2', EVENT NODE = 1 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
@@ -2058,6 +2061,27 @@
FAILOVER <emphasis>doit</emphasis> avoir <command>FORWARD = yes</command>.</para></listitem>
</varlistentry>
+ <varlistentry><term><literal> OMIT COPY = boolean </literal></term>
+
+ <listitem><para>Indique si le processus d'abonnement doit omettre la
+ commande <command>COPY</command> pour les données pré-existante dans
+ l'ensemble. En effet, utiliser cette option indique clairement
+ <quote>Faites-moi confiance, les données sont déjà synchronisées !</quote>
+ </para>
+
+ <para>Ceci est particulièrement utile dans les cas suivants :
+ </para>
+
+ <itemizedlist>
+ <listitem><para>Une mise à jour de version majeure (par exemple de &slony1;
+ 1.2 à 2.0) pourra être beaucoup plus rapide. </para> </listitem>
+ <listitem><para>Cloner un <quote>nœud maître</quote>.
+ <xref linkend="stmtcloneprepare"/>/<xref linkend="stmtclonefinish"/> </para> </listitem>
+ <listitem><para> </para> </listitem>
+ </itemizedlist>
+ </listitem>
+
+ </varlistentry>
</variablelist>
<para>Cette commande utilise &funsubscribeset;.</para>
</refsect1>
@@ -2143,6 +2167,10 @@
l'ancien contenu est détruit et le nœud est re-peupler <emphasis>à partir
de zéro</emphasis>.</para> </listitem>
+ <listitem><para> L'option <command>OMIT COPY</command> est un très gros
+ risque car il permet à l'administrateur d'avoir des ensembles de réplication
+ non synchronisés. </para>
+ </listitem>
</itemizedlist>
</refsect1>
@@ -2161,6 +2189,8 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
+ <para>L'option <command>OMIT COPY</command> a été introduit dans &slony1;
+ 2.0.3.</para>
</refsect1>
</refentry>
@@ -3025,7 +3055,7 @@
<refsect1>
<title>Description</title>
<para>
- Cette commande prépare le clonage d'un nœud donné.
+ Cette commande prépare le clonage d'un nœud abonné donné.
</para>
<para>
Modified: traduc/trunk/slony/slonyupgrade.xml
===================================================================
--- traduc/trunk/slony/slonyupgrade.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/slonyupgrade.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -378,4 +378,226 @@
</sect2>
+<sect2 id="upgrade20">
+<title>Mettre à jour en version 2</title>
+
+<para>
+ La version 2 est <emphasis>vraiment</emphasis> différente des versions
+ précédentes, supprimant le support des versions de &postgres; antérieures à la
+ 8.3 car la version 8.3 a ajouté la notion de <quote>rôle de
+ réplication</quote>, éliminant du coup d'avoir recours à des modifications du
+ catalogue système ainsi que du type de données <envar>xxid</envar> pas
+ complètement supporté.
+</para>
+
+<para>
+ Grâce au remplacement du type <envar>xxid</envar> par un type XID natif en
+ 8.3, la commande &lslonik; <xref linkend="stmtupdatefunctions"/> n'est pas
+ adéquate pour mettre à jour d'une ancienne version de &slony1; à la version
+ 2.
+</para>
+
+<para>
+ En version 2.0.2, nous avons ajouté une nouvelle option à <xref
+ linkend="stmtsubscribeset"/>, <command>OMIT COPY</command>, qui permet de
+ prendre une approche alternative pour la mise à jour. Cette approche revient
+ à :
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Désinstaller l'ancienne version de &slony1;.
+ </para>
+
+ <para>
+ Quand &slony1; se désinstalle, les corruptions des catalogues sont
+ corrigées.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Installer &slony1; version 2
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Réabonner les nœuds avec l'option <command>OMIT COPY</command>
+ </para>
+ </listitem>
+</itemizedlist>
+
+<warning>
+ <para>
+ Cela représente un gros risque. Durant le processus de mise à jour,
+ &slony1; n'est pas installé et si une application met à jour l'une ou
+ l'autre base de données, le ré-abonnement, omettant de copier les données,
+ se finira avec des données <emphasis>non synchronisées</emphasis>.
+ </para>
+
+ <para>
+ L'administrateur <emphasis>doit être très attentif</emphasis> car &slony1;
+ ne dispose d'aucun moyen pour s'assurer de l'intégrité des données lors
+ de ce processus.
+ </para>
+</warning>
+
+<para>
+ Le processus suivant est suggéré pour s'assurer d'avoir une mise à jour aussi
+ sûre que possible, étant donné les risques évoqués ci-dessus.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ Utiliser <xref linkend="slonikconfdump"/> pour générer un script &lslonik;
+ de création du cluster de réplication.
+ </para>
+
+ <para>
+ Assurez-vous de vérifier les instructions <xref linkend="admconninfo"/>,
+ car les valeurs sont récupérées de la configuration du PATH, qui ne sont
+ pas forcément convenables pour exécuter &lslonik;.
+ </para>
+
+ <para>
+ Cette étape peut se faire avant la mise hors ligne de l'application.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Détermine les triggers qui ont la configuration <xref
+ linkend="stmtstoretrigger"/> sur les nœuds abonnés.
+ </para>
+
+ <para>
+ Comme indiqué sur <xref linkend="triggers"/>, la gestion a changé
+ fondamentalement entre &slony1; 1.2 et 2.0.
+ </para>
+
+ <para>
+ En général, il faut lancer une requête sur la table
+ <envar>sl_table</envar> de chaque nœud et, pour chaque trigger
+ trouvé dans <envar>sl_table</envar>, il est généralement approprié de
+ configurer un script indiquant soit <command>ENABLE REPLICA
+ TRIGGER</command> soit <command>ENABLE ALWAYS TRIGGER</command> pour
+ ces triggers.
+ </para>
+
+ <para>
+ Cette étape peut se faire avant la mise hors ligne de l'application.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Mettre hors ligne l'application le temps de la mise à jour pour qu'aucune
+ modification ne puisse venir de l'utilisation de l'application.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Pour vous assurer que les applications ne feront pas de modifications,
+ il pourrait être approprié d'empêcher les connexions en modifiant le
+ fichier de configuration <filename>pg_hba.conf</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Assurez-vous que la réplication est synchrone, en examinant la vue
+ <envar>sl_status</envar> et toute donnée de l'application qui serait
+ appropriée.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Arrêter les processus &lslon;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Désinstaller l'ancienne version de &slony1; de la base de données.
+ </para>
+
+ <para>
+ Ceci implique d'exécuter un script &lslonik; qui exécute <xref
+ linkend="stmtuninstallnode"/> sur chaque nœud du cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Assurer vous que les nouveaux exécutables &slony1; sont en place.
+ </para>
+
+ <para>
+ Une méthode simple de le faire est d'avoir les anciens et les nouveaux
+ exécutables dans des répertoires différents, de stopper
+ <application>postmaster</application>, de pointer vers le bon répertoire,
+ et de relancer <application>postmaster</application>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Lancer le script qui reconfigure la réplication générée précédemment.
+ </para>
+
+ <para>
+ Ce script devrait être divisé en deux parties à exécuter séparément :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ En premier, configurer les nœuds, les chemins, les ensembles,
+ et ainsi de suite.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Maintenant, lancer les processus &lslon;.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Enfin, exécuter la portion qui lance <xref
+ linkend="stmtsubscribeset"/>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Diviser le script <xref linkend="slonikconfdump"/> comme décrit ci-dessus
+ est laissé en exercice au lecteur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si des triggers doivent être activés sur les nœuds abonnés, c'est
+ le bon moment pour le faire.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Maintenant, le cluster est nouveau disponible et fonctionnel, prêt à être
+ reconfiguré pour que les applications puissent de nouveau y accéder.
+ </para>
+ </listitem>
+
+</itemizedlist>
+
+</sect2>
+
</sect1>
Modified: traduc/trunk/slony/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2010-05-15 17:53:46 UTC (rev 1502)
+++ traduc/trunk/slony/supportedplatforms.xml 2010-05-15 20:17:20 UTC (rev 1503)
@@ -14,7 +14,7 @@
sur ces plate-formes.
</para>
-<para>Dernière mise à jour : 23 juin 2005</para>
+<para>Dernière mise à jour : 9 août 2009</para>
<para>
Si vous rencontrez des problèmes sur une de ces plate-formes, s'il-vous-plait,
@@ -38,159 +38,96 @@
</row>
</thead>
- <tbody>
+ <tbody>
<row>
- <entry>Fedora Core</entry>
- <entry>3</entry>
- <entry>Intel - 32 bit</entry>
- <entry>22 juin 2005</entry>
- <entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; version 7.4.6</entry>
+ <entry>Debian</entry>
+ <entry>Lenny</entry>
+ <entry>32 et 64 bit</entry>
+ <entry>9 août 2009</entry>
+ <entry>adolfomaltez at gmail dot com</entry>
+ <entry>Version &postgres; : 8.3</entry>
</row>
<row>
- <entry>Red Hat Linux</entry>
- <entry>9</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>dvdm AROBASE truteq.co.za</entry>
- <entry>&postgres; version 7.4.5</entry>
+ <entry>Fedora Core</entry>
+ <entry>9,10,11</entry>
+ <entry>Intel - 32 bit, 64 bit</entry>
+ <entry>9 août 2009</entry>
+ <entry>devrim at gunduz dot org</entry>
+ <entry>Version &postgres; : 8.3.7</entry>
</row>
- <row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
- </row>
<row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 8.0.2</entry>
+ <entry>FreeBSD</entry>
+ <entry>6.X</entry>
+ <entry>AMD64</entry>
+ <entry>9 août 2009</entry>
+ <entry>wmoran at potentialtech dot com </entry>
+ <entry>Version &postgres; : 8.1</entry>
</row>
<row>
- <entry>Debian GNU/Linux</entry>
- <entry>Sid</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.3.9</entry>
+ <entry>FreeBSD</entry>
+ <entry>6.X</entry>
+ <entry>AMD64</entry>
+ <entry>9 août 2009</entry>
+ <entry>wmoran at potentialtech dot com </entry>
+ <entry>Version &postgres; : 8.2</entry>
</row>
<row>
- <entry>AIX</entry>
- <entry>5.1</entry>
- <entry>PPC</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
+ <entry>FreeBSD</entry>
+ <entry>6.X</entry>
+ <entry>AMD64</entry>
+ <entry>9 août 2009</entry>
+ <entry>wmoran at potentialtech dot com </entry>
+ <entry>Version &postgres; : 8.3</entry>
</row>
<row>
- <entry>SunOS (a.k.a. Solaris8)</entry>
- <entry>5.8</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>cbbrowne AROBASE ca.afilias.info</entry>
- <entry>&postgres; version 7.4.8</entry>
+ <entry>FreeBSD</entry>
+ <entry>7.X</entry>
+ <entry>AMD64</entry>
+ <entry>9 août 2009</entry>
+ <entry>wmoran at potentialtech dot com </entry>
+ <entry>Version &postgres; : 8.3</entry>
</row>
<row>
- <entry>Red Hat Enterprise Linux Enterprise Server</entry>
- <entry>3.0</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
+ <entry>Gentoo</entry>
+ <entry>2008</entry>
+ <entry>amd64</entry>
+ <entry>9 août 2009</entry>
+ <entry>vostorga at gmail dot com </entry>
+ <entry>Version &postgres; : 8.1</entry>
</row>
<row>
- <entry>Red Hat Enterprise Linux Enterprise Server</entry>
- <entry>4</entry>
+ <entry>Red Hat Enterprise Linux</entry>
+ <entry>5</entry>
<entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
+ <entry>9 août 2009</entry>
+ <entry>devrim at gunduz dot org</entry>
+ <entry>Version &postgres; : 8.3.7</entry>
</row>
<row>
- <entry>Fedora Core</entry>
- <entry>3</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Fedora Core</entry>
- <entry>4</entry>
- <entry>x86</entry>
- <entry>22 juin 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
- </row>
-
- <row>
- <entry>Red Hat Linux</entry>
+ <entry>Solaris</entry>
<entry>9</entry>
- <entry>x86</entry>
- <entry>14 juillet 2005</entry>
- <entry>devrim AROBASE gunduz.org</entry>
- <entry>&postgres; version 8.0.3, les docs ne compilent pas, la valeur de
- NAMELEN doit être augmentée de 44 à 100 afin de compiler les doc ou
- alors il faut utiliser les RPM de la communauté</entry>
+ <entry>sparc</entry>
+ <entry>9 août 2009</entry>
+ <entry>devrim at gunduz dot org</entry>
+ <entry>Version &postgres; : 8.2 et 8.3</entry>
</row>
<row>
- <entry>FreeBSD</entry>
- <entry>5.X</entry>
- <entry>AMD64</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
- <entry>OpenBSD</entry>
- <entry>3.7</entry>
- <entry>Sparc64</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
- <entry>OpenBSD</entry>
- <entry>3.7</entry>
- <entry>x86</entry>
- <entry>1er juillet 2005</entry>
- <entry>stefan AROBASE kaltenbrunner.cc </entry>
- <entry>&postgres; version 8.0.3</entry>
- </row>
-
- <row>
<entry><trademark>Windows</trademark></entry>
<entry>2000/XP/2003</entry>
<entry>x86</entry>
<entry>21 septembre 2006</entry>
- <entry>dpage AROBASE postgresql.org </entry>
- <entry>&postgres; version 8.1, 8.2</entry>
+ <entry>dpage at postgresql.org </entry>
+ <entry>Version &postgres; : 8.1, 8.2</entry>
</row>
</tbody>
Plus d'informations sur la liste de diffusion Trad