Changeset 969

Show
Ignore:
Timestamp:
03/31/08 01:19:46 (9 months ago)
Author:
daamien
Message:

correction XML mal formé
test compilation OK

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/adminscripts.xml

    r937 r969  
    683683<itemizedlist> 
    684684<listitem><para> <filename> schema.sql </filename> </para>  
    685 <para> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</listitem> 
     685<para> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</para></listitem> 
    686686<listitem><para> <filename> slonik.preamble </filename> </para>  
    687687 
    …… 
    705705</sect2> 
    706706</sect1> 
    707 <!-- Keep this comment at the end of the file 
    708 Local variables: 
    709 mode:sgml 
    710 sgml-omittag:nil 
    711 sgml-shorttag:t 
    712 sgml-minimize-attributes:nil 
    713 sgml-always-quote-attributes:t 
    714 sgml-indent-step:1 
    715 sgml-indent-data:t 
    716 sgml-parent-document:"slony.sgml" 
    717 sgml-exposed-tags:nil 
    718 sgml-local-catalogs:("/usr/lib/sgml/catalog") 
    719 sgml-local-ecat-files:nil 
    720 End: 
    721 --> 
     707 

  • traduc/trunk/slony/bestpractices.xml

    r937 r969  
    66 
    77<sect1 id="bestpractices"> 
    8 <title> &slony1; <quote>Best Practices</quote> </title> 
    9 <indexterm><primary>best practices for &slony1; usage</primary></indexterm> 
    10  
    11 <para> It is common for managers to have a desire to operate systems 
    12 using some available, documented set of <quote>best practices.</quote> 
    13 Documenting that sort of thing is essential to ISO 9000, ISO 9001, and 
    14 other sorts of organizational certifications. </para> 
    15  
    16 <para> It is worthwhile to preface a discussion of <quote>best 
    17 practices</quote> by mentioning that each organization that uses 
    18 &slony1; is unique, and there may be a need for local policies to 
    19 reflect unique local operating characteristics.  It is for that reason 
    20 that &slony1; does <emphasis>not</emphasis> impose its own policies 
    21 for such things as <link linkend="failover"> failover </link>; those 
    22 will need to be determined based on the overall shape of your network, 
    23 of your set of database servers, and of your usage patterns for those 
    24 servers. </para> 
    25  
    26 <para> There are, however, a number of things that early adopters of 
    27 &slony1; have discovered which can at least help to suggest the sorts 
    28 of policies you might want to consider. </para> 
    29  
    30 <itemizedlist> 
    31  
    32 <listitem> 
    33 <para> &slony1; is a complex multi-client, multi-server 
    34 system, with the result that there are almost an innumerable set of 
    35 places where problems can arise.  </para>  
    36  
    37 <para> As a natural result, maintaining a clean, consistent 
    38 environment is really valuable, as any sort of environmental 
    39 <quote>messiness</quote> can either cause unexpected problems or mask 
    40 the real problem. </para> 
    41  
    42 <para> Numerous users have reported problems resulting from mismatches 
    43 between &slony1; versions, local libraries, and &postgres; libraries. 
    44 Details count: you need to be clear on what hosts are running what 
    45 versions of what software. </para> 
    46  
    47 <para> This is normally a matter of being disciplined about how your 
    48 software is deployed, and the challenges represent a natural 
    49 consequence of being a distributed system comprised of a large number 
    50 of components that need to match. </para> 
    51 </listitem> 
    52  
    53 <listitem><para> If a slonik script does not run as expected in a 
    54 first attempt, it would be foolhardy to attempt to run it again until 
    55 a problem has been found and resolved.  </para> 
    56  
    57 <para> There are a very few slonik commands such as <xref 
    58 linkend="stmtstorepath"/> that behave in a nearly idempotent manner; if 
    59 you run <xref linkend="stmtstorepath"/> again, that merely updates 
    60 table <envar>sl_path</envar> with the same value.  </para> 
    61  
    62 <para> In contrast <xref linkend="stmtsubscribeset"/> behaves in two 
    63 <emphasis>very</emphasis> different ways depending on whether the 
    64 subscription has been activated yet or not; if initiating the 
    65 subscription didn't work at a first attempt, submitting the request 
    66 again <emphasis>won't</emphasis> help make it happen. </para> 
    67 </listitem> 
    68  
    69 <listitem> 
    70 <para> Principle: Use an unambiguous, stable time zone such 
    71 as UTC or GMT.</para> 
    72  
    73 <para> Users have run into problems with &lslon; functioning properly 
    74 when their system uses a time zone that &postgres; was unable to 
    75 recognize such as CUT0 or WST.  It is necessary that you use a 
    76 timezone that &postgres; can recognize correctly.  It is furthermore 
    77 preferable to use a time zone where times do not shift around due to 
    78 Daylight Savings Time. </para> 
    79  
    80 <para> The <quote>geographically unbiased</quote> choice seems to be 
    81 <command><envar>TZ</envar>=UTC</command> or 
    82 <command><envar>TZ</envar>=GMT</command>, and to make sure that 
    83 systems are <quote>in sync</quote> by using NTP to synchronize clocks 
    84 throughout the environment. </para> 
    85  
    86 <para> See also <xref linkend="times"/>.</para> 
    87 </listitem> 
    88  
    89 <listitem> 
    90 <para> Principle: Long running transactions are Evil </para> 
    91  
    92 <para> The FAQ has an entry on <link linkend="pglistenerfull"> growth 
    93 of &pglistener; </link> which discusses this in a fair bit of detail; 
    94 the long and short is that long running transactions have numerous ill 
    95 effects.  They are particularly troublesome on an 
    96 <quote>origin</quote> node, holding onto locks, preventing vacuums 
    97 from taking effect, and the like.</para> 
    98  
    99 <para> In version 1.2, some of the <quote>evils</quote> should be 
    100 lessened, because:</para> 
    101  
    102 <itemizedlist> 
    103  
    104 <listitem><para> Events in &pglistener; are only generated when 
    105 replication updates are relatively infrequent, which should mean that 
    106 busy systems won't generate many dead tuples in that table 
     8<title> &slony1; <quote>Bonnes Pratiques</quote> </title> 
     9<indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm> 
     10 
     11<para> Il est courant pour les administrateurs de vouloir exploiter des systÚmes  
     12  en utilisant un ensemble de <quote>bonnes pratiques</quote> disponibles et documentées. 
     13  Documenter ce genre de choses est essentiel pour l'ISO 9000, l'ISO 9001,  
     14  et d'autres type de certifications d'organisation. </para> 
     15 
     16<para> Il est intéressant d'introduire toute discussion sur des <quote>bonnes 
     17pratiques</quote> en mentionnant que chaque organisation utilisant &slony1; est unique, 
     18et qu'il est nécessaire qu'une politique locale reflÚte les caractéristiques administratives locales. 
     19C'est pour cette raison que &slony1; n'impose <emphasis>as</emphasis> ses propres rÚgles pour des  
     20choses telles que <link linkend="failover">les bascules d'urgence</link>; elles devront être déterminées 
     21en fonction de l'architecture globale de votre réseau, de votre ensemble de serveurs de base de données,  
     22et de votre maniÚre d'utiliser ces serveurs.</para> 
     23 
     24<para> Il ya toutefois, un certain nombre de choses que les pioniers de &slony1; ont 
     25  découvertes qui peuvent au moins aider à concevoir le genre de rÚgles d'administration 
     26  que vous pourriez mettre en place. </para> 
     27 
     28<itemizedlist> 
     29 
     30<listitem> 
     31<para> &slony1; est systÚme multi-clients et multi-serveurs complexe, 
     32ce qui implique qu'il existe un ensemble presque infini d'endroits  
     33où des problÚmes peuvent surgir.</para>  
     34 
     35<para> c'est donc naturellement que la maintenance d'un environement propre, cohérent 
     36 est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement 
     37 peut provoquer des problÚmes ou masquer le problÚme réel. </para> 
     38 
     39<para> De nombreux utilisateurs ont rapportés des problÚmes provenants d'incompatibilités 
     40  entre les versions de &slony1;, les librairies locales, et les librairies de &postgres;. 
     41  Chaque détail compte : vous devez identifier clairement sur quels hÃŽtes sont hébergées  
     42  quelles versions de quels logiciels. </para> 
     43 
     44<para> Normalement il s'agit juste d'être discipliné lors du déploiement de vos logiciels, et  
     45  ce défi est une conséquence naturelle lorsqu'on met en place un systÚme distribué constitué 
     46  par un grand nombre de composants qui doivent correspondre.</para> 
     47</listitem> 
     48 
     49<listitem><para> Si un script slonik ne fonctionne pas comme prévu à la premiÚre  
     50    tentative, il serait téméraire de tenter de l'exécuter à nouveau tant que le  
     51    problÚme n'a pas été trouvé et résolu.  </para> 
     52 
     53<para> Il y a trÚs peu de commandes slonik tel que <xref 
     54linkend="stmtstorepath"/> qui se comporte de maniÚre déterministe; 
     55  si vous exécuter <xref linkend="stmtstorepath"/> plusieurs fois, 
     56  cela mettra plusieurs fois la même valeur dans la table 
     57  <envar>sl_path</envar>.  </para> 
     58 
     59<para> Au contraire <xref linkend="stmtsubscribeset"/> se comporte de  
     60  deux maniÚres <emphasis>trÚs</emphasis> différentes selon si  
     61  l'abonnement a déjà été activé ou pas; si l'initialisation de  
     62  l'abonnement n'a pas fonctionné à la toute premiÚre tentative,  
     63  soumettre à nouveau cette requête n'arrangera <emphasis>pas</emphasis> 
     64  la situation. </para> 
     65</listitem> 
     66 
     67<listitem> 
     68<para> Principe: Utilisez un zone de temps ("timezone") stable et non-ambigÃŒe  
     69  tel que UTC ou GMT.</para> 
     70 
     71<para> Les utilisateurs ont rencontrés des problÚmes pour faire fonctionner 
     72  &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 
     74  que vous utilisiez une zone de temps que &postgres; reconnaît correctement. 
     75  De plus, il est préférable d'utiliser une zone qui n'est pas soumise au  
     76  basculement entre heure d'été et heure d'hivers.</para> 
     77 
     78<para> Le choix <quote>géographiquement neutre</quote> semble être 
     79 <command><envar>TZ</envar>=UTC</command> ou 
     80<command><envar>TZ</envar>=GMT</command>, par ailleurs assurez-vous que  
     81vos serveurs sont <quote>synchronisés</quote> grace à l'utilisation  
     82de NTP sur l'ensemble de votre environnement. </para> 
     83 
     84<para> Voir aussi <xref linkend="times"/>.</para> 
     85</listitem> 
     86 
     87<listitem> 
     88<para> Principe: Les transactions longues c'est mal </para> 
     89 
     90<para> La FAQ a un chapitre sur la<link linkend="pglistenerfull">croissance de 
     91 &pglistener; </link> qui explique tout cela en détails; pour simplifier : 
     92les transactions longues ont de nombreux effets secondaires. Elles sont problématiques 
     93en particulier sur un noeud <quote>origine</quote>, s'accaparant les verrous, rendant inefficace  
     94les vacuums , et ainsi de suite.</para> 
     95 
     96<para> Dans la version 1.2, certains comportement <quote>désagréables</quote> devraient 
     97  être diminués car :</para> 
     98 
     99<itemizedlist> 
     100 
     101<listitem><para> Les événements dans &pglistener; sont seulement générés lorsque 
     102    les mise à jours de réplication sont relativement rare, ce qui devrait  
     103    impliquer que les systÚmes chargés ne vont pas générer beaucoup de tuples morts 
     104    dans cette table. 
    107105</para></listitem> 
    108106 
    109 <listitem><para> The system will periodically rotate (using 
    110 <command>TRUNCATE</command> to clean out the old table) between the 
    111 two log tables, <xref linkend="table.sl-log-1"/> and <xref 
    112 linkend="table.sl-log-2"/>, preventing unbounded growth of dead space 
    113 there.  </para></listitem> 
    114 </itemizedlist> 
    115  
    116 </listitem> 
    117  
    118 <listitem> 
    119 <para> <link linkend="Failover"> Failover </link> policies 
    120 should be planned for ahead of time.  </para> 
    121  
    122 <para> This may simply involve thinking about what the priority lists 
    123 should be of what should fail to what, as opposed to trying to 
    124 automate it.  But knowing what to do ahead of time cuts down on the 
    125 number of mistakes made.</para> 
    126  
    127 <para> At Afilias, a variety of internal <citation>The 3AM Unhappy 
    128 DBA's Guide to...</citation> guides have been created to provide 
    129 checklists of what to do when certain <quote>unhappy</quote> events 
    130 take place.  This sort of material is highly specific to the 
    131 environment and the set of applications running there, so you would 
    132 need to generate your own such documents.  This is one of the vital 
    133 components of any disaster recovery preparations. 
     107<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, 
     109   <xref linkend="table.sl-log-1"/> et <xref 
     110linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit.  </para></listitem> 
     111</itemizedlist> 
     112 
     113</listitem> 
     114 
     115<listitem> 
     116<para>Les rÚgles de  <link linkend="Failover"> Bascule en urgence </link>  
     117  devraient être planifiées à l'avance.  </para> 
     118 
     119<para> Cela peut simplement se résumer à réfléchir à une liste 
     120  de priorité indiquant ce qui devrait basculer vers quoi, plutot  
     121  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. 
     123  </para> 
     124 
     125<para> Chez Afilias, une grande variété de guide interne, tel que <citation>Le guide  
     126    de l'administrateur réveillé à 3 heures du matin..</citation>, ont été 
     127    rédigé pour fournir les procédures à suivre en cas d'événements <quote>malheureux</quote>. 
     128    Ce genre de matériel est hautement spécifique à l'environnement  et à l'ensemble d'applications 
     129    présentes, donc vous devriez rédiger vos propres documents. Ceci est un des composants vitaux de  
     130    tout procédure de reprise aprÚs crash. 
    134131</para> 
    135132</listitem> 

  • traduc/trunk/slony/failover.xml

    r937 r969  
    4747or less in sync.  We do controlled switchover using <xref 
    4848linkend="stmtmoveset"/>. 
    49  
     49</para> 
    5050<itemizedlist> 
    5151 
    …… 
    6464are a number of ways that this may be configured, and therefore, a 
    6565number of possible methods for accomplishing the change: 
    66  
     66</para> 
     67</listitem> 
    6768<itemizedlist> 
    6869 
    …… 
    9798re-opening them, then there may be no need to restart it. </para> 
    9899 
    99 </listitem> 
     100 
    100101 
    101102 
    …… 
    126127seconds.</para></listitem> 
    127128 
    128 </itemizedlist></para> 
     129</itemizedlist> 
    129130 
    130131<para> You may now simply shutdown the server hosting node1 and do 

  • traduc/trunk/slony/faq.xml

    r937 r969  
    13931393<answer><para> The thresholds for switching between these modes are 
    13941394controlled by the configuration parameters <xref 
    1395 linkend="slon-config-sync-interval"> and <xref 
    1396 linkend="slon-config-sync-interval-timeout">; if the timeout value 
     1395linkend="slon-config-sync-interval"/> and <xref 
     1396linkend="slon-config-sync-interval-timeout"/>; if the timeout value 
    13971397(which defaults to 10000, implying 10s) is kept low, that makes it 
    13981398easy for the &lslon; to decide to return to <quote>listening</quote> 

  • traduc/trunk/slony/filelist.xml

    r937 r969  
    4949<!ENTITY slonyupgrade       SYSTEM "slonyupgrade.xml"> 
    5050<!ENTITY releasechecklist   SYSTEM "releasechecklist.xml"> 
    51 <!ENTITY raceconditions     SYSTEM "raceconditions.sgml"> 
    52 <!ENTITY partitioning       SYSTEM "partitioning.sgml"> 
    53 <!ENTITY triggers           SYSTEM "triggers.sgml"> 
     51<!ENTITY raceconditions     SYSTEM "raceconditions.xml"> 
     52<!ENTITY partitioning       SYSTEM "partitioning.xml"> 
     53<!ENTITY triggers           SYSTEM "triggers.xml"> 
    5454 
    5555<!-- back matter --> 

  • traduc/trunk/slony/legal.xml

    r940 r969  
    1414 
    1515 <para> 
    16   <productname>PostgreSQL</productname> est sous le Copyright &copy; 2004-2007 
     16  <productname>PostgreSQL</productname> est sous le Copyright &amp;copy; 2004-2007 
    1717  du PostgreSQL Global Development Group  et est distribué sous les termes 
    1818  de la licence de l'Université de Californie ci-dessous. 

  • traduc/trunk/slony/maintenance.xml

    r937 r969  
    391391<envar>SLON_BINARY</envar> the full path name of the slon binary (default <command>which slon</command>)</para></listitem> 
    392392</itemizedlist> 
    393  
     393</sect3> 
    394394<sect3><title>logrep-mkservice.sh</title> 
    395395 

  • traduc/trunk/slony/raceconditions.xml

    r965 r969  
    2525 
    2626<listitem><para> Entre la version 1.0 et la version 1.1, 
    27    <xref linkend="stmtmoveset"> a avait un problÚme car les noeuds n'avait  
     27   <xref linkend="stmtmoveset"/> a avait un problÚme car les noeuds n'avait  
    2828     aucun moyen d'empêcher le traitement des événements <command>SYNC</command> 
    2929     en provenance du noeud origine ( qu'ils considéraient comme un simple fournisseur, 
    …… 
    4343 
    4444<listitem><para> L'option &lslon; <xref 
    45 linkend="slon-config-sync-interval-timeout"> est utilisée pour éviter les situations  
     45linkend="slon-config-sync-interval-timeout"/> est utilisée pour éviter les situations  
    4646      de compétition dans lesquelles la séquence d'action est dégagée par le trigger 
    4747      au moment de l'insertion de ligne de log, ce qui rend le <quote>dégagement</quote> immédiatement 

  • traduc/trunk/slony/slonik_ref.xml

    r937 r969  
    11071107    taken from any node.  That leaves the <quote>kludgy</quote> 
    11081108    columns created via <command>TABLE ADD KEY</command> as the only 
    1109     thing that prevents <xref linkend="stmtuninstallnode"> from being 
     1109    thing that prevents <xref linkend="stmtuninstallnode"/> from being 
    11101110    comprised of the SQL statement <command>drop schema _ClusterName 
    11111111    cascade;</command>.</para> </warning>     
    …… 
    18491849    <emphasis>before</emphasis> it is installed.  That allows you to 
    18501850    be certain that it becomes active on all nodes immediately upon 
    1851     its installation via <xref linkend="stmtddlscript">; there is no 
     1851    its installation via <xref linkend="stmtddlscript"/>; there is no 
    18521852    risk of events getting through in between the <command>EXECUTE 
    18531853    SCRIPT</command> and <command>STORE TRIGGER</command> 
    …… 
    30373037    for the clone to miss some events. </para> 
    30383038 
    3039    </Refsect1> 
    3040    <Refsect1><Title>Example</Title> 
     3039   </refsect1> 
     3040   <refsect1><Title>Example</Title> 
    30413041    <Programlisting> 
    30423042     clone prepare (id = 33, provider = 22, comment='Clone 33'); 
    …… 
    30443044     sync (id=22); 
    30453045     </Programlisting> 
    3046    </Refsect1> 
     3046   </refsect1> 
    30473047   <refsect1> <title> Version Information </title> 
    30483048    <para> This command was introduced in &slony1; 1.2.0. </para> 
    30493049   </refsect1> 
    3050   </Refentry> 
     3050  </refentry> 
    30513051 
    30523052 
    …… 
    30733073    <para> 
    30743074     This completes the work done by <xref 
    3075      linkend="stmtcloneprepare">, establishing confirmation data for 
     3075     linkend="stmtcloneprepare"/>, establishing confirmation data for 
    30763076     the new <quote>clone</quote> based on the status found for the 
    30773077     <quote>provider</quote> node. 
    30783078    </para> 
    3079    </Refsect1> 
    3080    <Refsect1><Title>Example</Title> 
     3079   </refsect1> 
     3080   <refsect1><Title>Example</Title> 
    30813081    <Programlisting> 
    30823082     clone finish (id = 33, provider = 22); 
    30833083    </Programlisting> 
    3084    </Refsect1> 
     3084   </refsect1> 
    30853085   <refsect1> <title> Version Information </title> 
    30863086    <para> This command was introduced in &slony1; 1.2.0. </para> 
    30873087   </refsect1> 
    3088   </Refentry> 
     3088  </refentry> 
    30893089 
    30903090   

  • traduc/trunk/slony/slony.xml

    r967 r969  
    5858<!ENTITY lslonik "<xref linkend='slonik'/>"> 
    5959<!ENTITY frenchtranslation "<xref linkend='frenchtranslation'/>"> 
     60 
    6061 
    6162]> 

  • traduc/trunk/slony/slonyupgrade.xml

    r959 r969  
    1717<para>La procédure correcte est la suivante :</para> 
    1818<itemizedlist> 
    19 <listitem><para> Arrêtez les processus &lslon; sur chaque noeud.  
    20 (<emphasis>c.a.d</emphasis> l'ancienne version de &lslon;)</para></listitem> 
     19<listitem> 
     20  <para> Arrêtez les processus &lslon; sur chaque noeud.  
     21  (<emphasis>c.a.d</emphasis> l'ancienne version de &lslon;) 
     22  </para> 
     23</listitem> 
    2124<listitem><para> Installez la nouvelle version du logiciel &lslon; sur tous les noeuds.</para></listitem> 
    22 <listitem><para> Exécutez un script &lslonik; contenant la commande  
    23     <command>update functions (id = [valeur]);</command> pour chaque noeud du cluster.</para> 
    24 <note><para>Souvenez-vous que le script de mise à jour, comme tous les scripts &slonik; doit contenir 
    25 les fonctions adéquates pour fonctionner. 
    26 </para></note></listitem> 
     25<listitem> 
     26  <para> Exécutez un script &lslonik; contenant la commande  
     27    <command>update functions (id = [valeur]);</command> pour chaque noeud du cluster. 
     28  </para> 
     29  <note> 
     30    <para>Souvenez-vous que le script de mise à jour, comme tous les scripts &slonik; doit contenir 
     31    les fonctions adéquates pour fonctionner. 
     32     </para> 
     33   </note> 
     34</listitem> 
    2735<listitem><para> Démarrez tous les slons.  </para> </listitem> 
    2836</itemizedlist> 
    …… 
    6573  compilation sur le serveur où la mise à jour sera déployée.  
    6674  Ceci n'est pas forcément compatible avec la volonté d'utiliser  
    67   des binaires commun à &postgres; et &slony; sur l'ensemble des noeuds. 
     75  des binaires commun à &postgres; et &slony1; sur l'ensemble des noeuds. 
    6876</para> 
    6977</listitem></varlistentry> 
    …… 
    7381<listitem><para>Avec cette approche, l'ancienne version de &postgres; accompagnée des  
    7482    anciens composants &slony1; sont conservés aprÚs la bascule vers une nouvelle 
    75     version &postgres; accompagnée des nouveaux composants &slony;. Afin de bascule  
     83    version &postgres; accompagnée des nouveaux composants &slony1;. Afin de bascule  
    7684    vers la nouvelle version de &slony1; vous devez redémarrer le  
    7785    serveur <command>postmaster</command> &postgres;, ce qui implique l'interruption des  
    …… 
    99107   <command> SELECT n.nspname, c.relname FROM pg_class c, 
    100108pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE 
    101 attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype <> 0 
     109attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &amp;lt&amp;gt 0 
    102110and n.oid = c.relnamespace order by n.nspname, c.relname; </command> 
    103111</para> 
    …… 
    225233qui doivent être exécutées via la commande Slonik <xref 
    226234linkend="stmtddlscript"/>. </para> 
    227 </listitem> 
     235 
    228236 
    229237<para>Notez que ces deux modifications peuvent être accomplies au sein 

  • traduc/trunk/slony/startslons.xml

    r901 r969  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="slonstart"> <title>Slon daemons</title> 
     7<sect1 id="slonstart"> <title>Les démons Slon</title> 
    88 
    99<indexterm><primary>running slon</primary></indexterm> 

  • traduc/trunk/slony/testbed.xml

    r964 r969  
    197197     un fichier de configuration <filename>slon.conf</filename> 
    198198     spécifique pour chaque noeud.</link> </para>  
     199</glossdef> 
    199200</glossentry> 
    200201 

  • traduc/trunk/slony/triggers.xml

    r963 r969  
    99 
    1010<para> &slony1; a connu deux <quote>types</quote> des gestion de triggers 
    11  
     11</para> 
    1212<itemizedlist> 
    1313 
    …… 
    1717    désactiver, sur les noeuds abonnés, les triggers qui ne devaient pas être  
    1818    exécutés.</para> 
    19  
     19</listitem> 
     20   
    2021<para> Ceci provoquait un nombre d'effets secondaires pénibles, tels que :</para>  
    2122<itemizedlist> 
    …… 
    4344    la commande <command>ALTER TABLE</command>, et de spécifier une des  
    4445    options de triggers suivantes :</para> 
    45  
     46</listitem> 
    4647<itemizedlist> 
    4748 
    …… 
    6465<para> On peut déterminer quand les triggers se déclenche dans une réplication &slony1; 
    6566  en utilisant la table suivante; le même principe s'applique aux rÚgles. 
    66  
     67</para> 
    6768 
    6869<table id="triggerbehaviour"> <title>Comportement du trigger</title> 
    …… 
    115116</row> 
    116117</tbody> 
     118</tgroup> 
     119</table> 
    117120 
    118121<para> Il y a désormais plusieurs façons pour &slony1; d'interagir avec cela.  
    …… 
    124127<listitem><para> Avant que la réplication soit en place,  
    125128    <emphasis>chaque</emphasis> chaque base de données démarre avec  
    126     le statut <quote>origin<quote> et, par défaut, tous les triggers sont du type 
     129    le statut <quote>origin</quote> et, par défaut, tous les triggers sont du type 
    127130    <command>ENABLE TRIGGER</command>, afin qu'ils soient exécutés, comme  
    128131    dans un systÚme non-répliqué. </para> </listitem> 
    …… 
    210213 
    211214</itemizedlist> 
    212  
     215</itemizedlist> 
    213216</sect1> 

  • traduc/trunk/slony/versionupgrade.xml

    r938 r969  
    1818<listitem><para> Attendez 40 heures que le processus d'extraction/chargement se termine;</para></listitem> 
    1919<listitem><para> Faites pointer les applications <quote>en écriture</quote> vers la nouvelle base</para></listitem>   
    20 <itemizedlist>  
     20</itemizedlist>  
    2121</para>   
    2222 
    …… 
    2424 
    2525<para> &slony1; offre une opportunité de remplacer cette longue coupure de service par une autre de quelques minutes, voire quelques secondes. Cette approche consiste à créer un réplicat &slony1; utilisant la nouvelle version de &postgres;. Il est possible que cela prenne plus de 40 heures pour créer ce réplicat, mais une fois qu'il est créé, il peut être rafraîchi rapidement. 
     26</para>   
    2627   
    2728<para> Au moment de basculer vers la nouvelle base de données, la procédure est beaucoup moins longue : 
    …… 
    4041 
    4142<para> Cette procédure devrait prendre un temps trÚs court, qui dépendra principalement de votre rapidité lors de la reconfiguration de vos applications. Si vous pouvez souhaiter automatiser toutes ces étapes, il est possible que cela prenne moins d'une seconde. Sinon il est probable que cela prenne entre quelques secondes et quelques minutes. 
    42    
     43</para> 
     44 
    4345<para>Notez qu'aprÚs le déplacement de l'origine, les mises à jour vont vers l'<emphasis>ancienne</emphasis> base. Si vous découvrez qu'à cause d'un problÚme imprévu ou non-testé, votre application rencontre certains problÚmes pour se connecter à la nouvelle base, vous pouvez facilement utiliser  <xref linkend="stmtmoveset"/> à nouveau pour re-déplacer l'origine vers l'ancienne base. 
    4446</para> 
    …… 
    8284  par de tels choix.  
    8385   
    84 <note><para>&slony1; ne supporte pas les versions de &postgres antérieures à la 7.3.3  
     86<note><para>&slony1; ne supporte pas les versions de &postgres; antérieures à la 7.3.3  
    8587    parcequ'il a besoin des espaces de noms ("namespaces") qui n'étaient pas stable jusque là. 
    86     Rod Taylor modifia une version de &slony1 pour qu'elle fonctionne avec la 7.2 en autorisant  
     88    Rod Taylor modifia une version de &slony1; pour qu'elle fonctionne avec la 7.2 en autorisant  
    8789    les objets &slony1; à se placer dans le schéma global. Il trouva cela assez compliqué, de plus  
    8890    certaines requêtes n'était pas assez rapides ( l'optimiseur de requêtes de &postgres; a été <emphasis>considérablement</emphasis> amélioré depuis la version 7.2), cependant cette solution était plus pratique pour lui que les autres systÚmes de réplication tels que <productname>eRServer</productname>. Si vous recherchez désespérement ce type de solution, contactez-le sur la liste des hackers de &postgres;. Il n'est pas prévu que la version 7.2 de &postgres; soit supportée par une version officielle de &slony1;