Changeset 938

Show
Ignore:
Timestamp:
03/02/08 23:49:13 (10 months ago)
Author:
daamien
Message:

1ere traduction

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/versionupgrade.xml

    r901 r938  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="versionupgrade"><title>Using &slony1; for &postgres; Upgrades</title> 
     7<sect1 id="versionupgrade"><title>Utiliser &slony1; pour les mises à jour &postgres;</title> 
    88 
    9 <indexterm><primary>version upgrades for &postgres; using 
    10 &slony1;</primary></indexterm> 
     9<indexterm><primary>Mettre à jour la version de &postgres; en utilisant &slony1;</primary></indexterm> 
    1110 
    12 <para> A number of people have found 
    13 &slony1; useful for helping perform upgrades 
    14 between major &postgres; releases 
    15 (<emphasis> e.g.</emphasis> which mandates running 
    16 <application>initdb</application> to create a new database instance) 
    17 without requiring a substantial downtime.</para> 
     11<para> Un certain nombre de personnes ont trouvé que &slony1; était pratique pour effectuer les mises à jours de versions majeures  ( <emphasis>par exemple</emphasis> celles qui nécessitent d'éxécuter <application>initdb</application> afin de recréer une nouvelle instance ) sans subir une coupure de service importante. 
     12</para> 
    1813 
    19 <para> The <quote>simple</quote> way that one might imagine doing such 
    20 an upgrade would involve running <application>pg_dump</application> on 
    21 the database running the older version, and then submit the results 
    22 into a <application>psql</application> session connected to a database 
    23 instance running the newer version.  Unfortunately, the time consumed 
    24 from start to end, for this approach, may be prohibitive.  For a 
    25 database containing 40GB of data with numerous indices, the process 
    26 required involves: 
     14<para>La méthode simple que l'on peut imaginer pour effectuer une telle mise à jour consiste à éxecuter  <application>pg_dump</application> sur l'ancienne version de la base, puis d'envoyer le résultat dans une session <application>psql</application> connectée à la nouvelle version de la base. Malheureusement le temps nécessaire pour cette approche peut être prohibitif. Pour une base contenant 40Go de données ainsi que de nombreux index, le processus nécessite les étapes suivantes : 
     15<itemizedlist> 
     16<listitem><para> Arrêtez toutes les applications qui peuvent modifier les données; </para></listitem> 
     17<listitem><para> Lancez le <application>pg_dump</application>, et charger les données dans la nouvelle base;</para></listitem> 
     18<listitem><para> Attendez 40 heures que le processus d'extraction/chargement se termine;</para></listitem> 
     19<listitem><para> Faites pointer les applications <quote>en écriture</quote> vers la nouvelle base</para></listitem>   
     20<itemizedlist>  
     21</para>   
     22 
     23<para>Notez que cette opération a provoqué une coupure de service de 40 heures.</para> 
     24 
     25<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   
     27<para> Au moment de basculer vers la nouvelle base de données, la procédure est beaucoup moins longue : 
    2728 
    2829<itemizedlist> 
    29 <listitem><para> Stop all applications that might modify the data</para></listitem> 
    30 <listitem><para> Start the <application>pg_dump</application>, and load that into the new database</para></listitem> 
    31 <listitem><para> Wait 40 hours for the dump/load to complete</para></listitem> 
    32 <listitem><para> Point <quote>write</quote> applications to the new database</para></listitem> 
    33 </itemizedlist></para> 
     30<listitem><para> Arrêtez toutes les applications qui peuvent modifier les données;</para></listitem> 
    3431 
    35 <para> And note that this led to a 40 hour outage.</para> 
     32<listitem><para> Verrouillez le set contre les lectures des applications clientes en utilisant <xref linkend="stmtlockset"/>;</para></listitem> 
    3633 
    37 <para> &slony1; offers an opportunity to replace that long outage with 
    38 one a few minutes or even a few seconds long.  The approach taken is 
    39 to create a &slony1; replica in the new version.  It is possible that 
    40 it might take much longer than 40h to create that replica, but once 
    41 it's there, it can be kept very nearly up to date.</para> 
     34<listitem><para> Lancez le commande Slonik <xref 
     35linkend="stmtmoveset"/> pour déplacer l'origine de l'ensemble de réplication depuis l'ancienne base vers la nouvelle.</para></listitem> 
    4236 
    43 <para> When it is time to switch over to the new database, the 
    44 procedure is rather less time consuming: 
    45  
    46 <itemizedlist> 
    47  
    48 <listitem><para> Stop all applications that might modify the data</para></listitem> 
    49  
    50 <listitem><para> Lock the set against client application updates using 
    51 <xref linkend="stmtlockset"/></para></listitem> 
    52  
    53 <listitem><para> Submit the Slonik command <xref 
    54 linkend="stmtmoveset"/> to shift the origin from the old database to 
    55 the new one</para></listitem> 
    56  
    57 <listitem><para> Point the applications at the new database</para></listitem> 
    58 </itemizedlist></para> 
    59  
    60 <para> This procedure should only need to take a very short time, 
    61 likely bound more by how quickly you can reconfigure your applications 
    62 than anything else.  If you can automate all the steps, it might take 
    63 less than a second.  If not, somewhere between a few seconds and a few 
    64 minutes is likely.</para> 
    65  
    66 <para> Note that after the origin has been shifted, updates now flow 
    67 into the <emphasis>old</emphasis> database.  If you discover that due 
    68 to some unforeseen, untested condition, your application is somehow 
    69 unhappy connecting to the new database, you could easily use <xref 
    70 linkend="stmtmoveset"/> again to shift the origin back to the old 
    71 database.</para> 
    72  
    73 <para> If you consider it particularly vital to be able to shift back 
    74 to the old database in its state at the time of the changeover, so as 
    75 to be able to outright roll back the whole change, and would like as 
    76 well the ability to shift back to the old version (with any updates 
    77 since the changeover), the following steps would accomplish that: 
    78  
    79 <itemizedlist> 
    80 <listitem><para> Prepare <emphasis> two </emphasis> &slony1; replicas 
    81 of the database: 
    82  
    83 <itemizedlist> 
    84 <listitem><para> One running the new version of &postgres;</para></listitem> 
    85 <listitem><para> One running the old version of &postgres;</para></listitem> 
    86 </itemizedlist></para> 
    87  
    88 <para> Thus, you have <emphasis>three</emphasis> nodes, one running 
    89 the new version of &postgres;, and the other two the old version.</para></listitem> 
    90  
    91 <listitem><para> Once they are roughly <quote>in sync</quote>, stop 
    92 all applications that might modify the data</para></listitem> 
    93  
    94 <listitem><para> Allow them to get in sync, then 
    95 <command>stop</command> the <application>slon</application> daemon 
    96 that has been feeding the subscriber running the old version of 
    97 &postgres;</para> 
    98  
    99 <para> You may want to use <xref linkend="stmtuninstallnode"/> to 
    100 decommission this node, making it into a standalone database, or 
    101 merely kill the <application>slon</application>, depending on how 
    102 permanent you want this all to be.</para></listitem> 
    103  
    104 <listitem><para> Then use <xref linkend="stmtmoveset"/> to shift the 
    105 origin, as before.</para></listitem> 
     37<listitem><para> Faites pointer les applications vers la nouvelle base;</para></listitem> 
    10638 
    10739</itemizedlist></para> 
    10840 
    109 <para> Supposing a <quote>small</quote> disaster strikes, you might 
    110 recover back to the node running the old database that has been seeing 
    111 updates come through; if you run into larger problems, you would have 
    112 to abandon the two nodes and go to the one which had been shut off.</para> 
     41<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>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. 
     44</para> 
    11345 
    114 <para> This isn't to say that it is routine to have the sorts of 
    115 problems that would mandate such a <quote>paranoid</quote> procedure; 
    116 people worried about process risk assessments can be reassured if you 
    117 have choices like this. 
     46<para>Si vous considerez qu'il est particuliÚrement vital de pouvoir revenir à l'ancienne base dans l'état où elle se trouvait avant la bascule, afin de pouvoir revenir complÚtement en arriÚre et que vous souhaitez également pouvoir revenir à l'ancienne version (mise à jour depuis la bascule), accomplissez les étapes suivantes : 
     47   
     48<itemizedlist> 
     49   
     50<listitem><para> Préparez <emphasis> deux </emphasis>  réplicats &slony1; de la base; 
     51<itemizedlist> 
     52<listitem><para> Un pour la nouvelle version de &postgres;;</para></listitem> 
     53<listitem><para> Un pour l'ancienne version de &postgres;.</para></listitem> 
     54</itemizedlist></para> 
    11855 
    119 <note><para> &slony1; does not support versions of &postgres; older 
    120 than 7.3.3 because it needs namespace support that did not solidify 
    121 until that time.  Rod Taylor <quote>hacked up</quote> a version of 
    122 &slony1; to work on 7.2 by allowing the &slony1; objects to live in 
    123 the global schema.  He found it pretty fiddly, and that some queries 
    124 weren't very efficient (the &postgres; query optimizer has improved 
    125 <emphasis>considerably</emphasis> since 7.2), but that this was more 
    126 workable for him than other replication systems such as 
    127 <productname>eRServer</productname>.  If you desperately need that, 
    128 look for him on the &postgres; Hackers mailing list.  It is not 
    129 anticipated that 7.2 will be supported by any official &slony1; 
    130 release.</para></note></para> 
     56<para>Ainsi vous avez <emphasis>trois</emphasis> noeuds, un avec la nouvelle versin de &postgres;, et deux autres avec l'ancienne version.</para></listitem> 
     57 
     58<listitem><para> Une fois qu'ils sont à peu prÚs <quote>synchronisés</quote>, arrêtez toutes les applications qui peuvent modifier les données. 
     59</para></listitem> 
     60 
     61<listitem><para> Lancez la synchronisation des noeuds, puis  
     62<command>arrêtez</command> le démon <application>slon</application> qui a synchronisé le noeud esclave qui héberge l'ancienne version de &postgres; 
     63</para> 
     64 
     65<para>Vous voudrez peut-être utiliser <xref linkend="stmtuninstallnode"/> pour 
     66isoler ce noeud et ainsi le transformer en une base indépendante, ou simplement tuer le démon <application>slon</application>, selon  
     67votre volonté de rendre cette transformation permanente ou non. 
     68</para></listitem> 
     69 
     70<listitem><para> Ensuite utilisez <xref linkend="stmtmoveset"/> pour déplacer l'origine, comme décrit précédemment.</para></listitem> 
     71 
     72</itemizedlist></para> 
     73 
     74<para> Si de <quote>petits</quote> problÚmes apparaissent, vous pourrez récupérer 
     75  le noeud qui héberge l'ancienne base qui a reçues les mises à jours de données;  
     76 Si vous découvrez des problÚmes plus importants, vous pouvez abandonner les deux noeuds  
     77 et revenir à la base qui a été isolée.</para>  
     78 
     79<para>Il ne s'agit pas ici de dire qu'il est courant  
     80  de rencontrer des problÚmes qui nécessitent une procédure aussi <quote>paranoïaque</quote>;  
     81  Toutefois les personnes soucieuses d'évaluer les risques peuvent être rassurées  
     82  par de tels choix.  
     83   
     84<note><para>&slony1; ne supporte pas les versions de &postgres antérieures à la 7.3.3  
     85    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  
     87    les objets &slony1; à se placer dans le schéma global. Il trouva cela assez compliqué, de plus  
     88    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; 
     89 
     90</para></note></para> 
    13191 
    13292</sect1>