Changeset 959

Show
Ignore:
Timestamp:
03/25/08 07:05:33 (10 months ago)
Author:
daamien
Message:

1ere traduction, à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/slonyupgrade.xml

    r937 r959  
    66 
    77<sect1 id="slonyupgrade"> 
    8 <title> &slony1; Upgrade </title> 
    9 <indexterm><primary>upgrading &slony1; to a newer version</primary></indexterm> 
    10  
    11 <para> When upgrading &slony1;, the installation on all nodes in a 
    12 cluster must be upgraded at once, using the &lslonik; 
    13 command <xref linkend="stmtupdatefunctions"/>.</para> 
    14  
    15 <para> While this requires temporarily stopping replication, it does 
    16 not forcibly require an outage for applications that submit 
    17 updates. </para> 
    18  
    19 <para>The proper upgrade procedure is thus:</para> 
    20 <itemizedlist> 
    21 <listitem><para> Stop the &lslon; processes on all nodes. 
    22 (<emphasis>e.g.</emphasis> - old version of &lslon;)</para></listitem> 
    23 <listitem><para> Install the new version of &lslon; software on all 
    24 nodes.</para></listitem> 
    25 <listitem><para> Execute a &lslonik; script containing the 
    26 command <command>update functions (id = [whatever]);</command> for 
    27 each node in the cluster.</para> 
    28 <note><para>Remember that your slonik upgrade script like all other  
    29 slonik scripts must contain the proper preamble commands to function. 
     8<title> Mise à jour de &slony1;</title> 
     9<indexterm><primary>Remplacer &slony1; par une nouvelle version</primary></indexterm> 
     10 
     11<para>Lorsque l'on met à jour &slony1;, chaque noeud du cluster doit être mis à jour simultanément, en utilisant  
     12  la commande &lslonik; <xref linkend="stmtupdatefunctions"/>.</para> 
     13 
     14<para> Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique pas obligatoirement une  
     15  coupure de service au niveau des applications qui utilisent le cluster. </para> 
     16 
     17<para>La procédure correcte est la suivante :</para> 
     18<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> 
     21<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 
     25les fonctions adéquates pour fonctionner. 
    3026</para></note></listitem> 
    31 <listitem><para> Start all slons.  </para> </listitem> 
    32 </itemizedlist> 
    33  
    34 <para> The overall operation is relatively safe: If there is any 
    35 mismatch between component versions, the &lslon; will refuse to start 
    36 up, which provides protection against corruption. </para> 
    37  
    38 <para> You need to be sure that the C library containing SPI trigger 
    39 functions has been copied into place in the &postgres; build.  There 
    40 are multiple possible approaches to this:</para> 
    41  
    42 <para> The trickiest part of this is ensuring that the C library 
    43 containing SPI functions is copied into place in the &postgres; build; 
    44 the easiest and safest way to handle this is to have two separate 
    45 &postgres; builds, one for each &slony1; version, where the postmaster 
    46 is shut down and then restarted against the <quote>new</quote> build; 
    47 that approach requires a brief database outage on each node.</para> 
    48  
    49 <para> While that approach has been found to be easier and safer, 
    50 nothing prevents one from carefully copying &slony1; components for 
    51 the new version into place to overwrite the old version as 
    52 the <quote>install</quote> step.  That might <emphasis>not</emphasis> 
    53 work on <trademark>Windows</trademark> if it locks library files that 
    54 are in use.</para> 
     27<listitem><para> Démarrez tous les slons.  </para> </listitem> 
     28</itemizedlist> 
     29 
     30<para>Toute cette opération est relativement sûre : s'il y a une incohérence  
     31entre les versions des composants, le &lslon; refusera de démarrer, ce  
     32qui consitue une protection contre les corruption. 
     33 </para> 
     34 
     35<para>Vous devez vous assurer que la librairie C contenant les fonctions 
     36  trigger SPI ont été copié à la bonne place dans lors de la compilation  
     37  de &postgres;. Il existe de multiples approches pour cela :</para> 
     38 
     39<para>La partie la plus compliquée consiste à s'assurer que la librairie C  
     40  contenant les fonctions SPI est copié au bon endroit lors de la compilation  
     41  de &postgres;; la maniÚre la plus simple et la plus sûre de faire cela consiste  
     42  à avoir deux versions compilées de &postgres;, une pour chaque version de &slony1;  
     43  puis d'éteindre le serveur et le relancer avec la <quote>nouvelle</quote> version compilée; 
     44  cette approche implique une courte coupure de service sur chaque noeud.</para> 
     45 
     46<para>Si cette approche est réputée plus simple et plus rapide, 
     47  rien ne vous empêche de mettre en place avec précaution les composants &slony1; 
     48  pour écraser l'ancienne version comme décrit dans l'étape d'installation. 
     49  Ceci ne fonctionnera <emphasis>pas</emphasis> sous Windows si Windows pose un verrou  
     50  sur les fichiers qui sont utilisés.</para> 
    5551 
    5652<variablelist> 
    5753 
    58 <varlistentry><term>Run <command>make install</command> to install new 
    59 &slony1; components on top of the old</term> 
    60  
    61 <listitem><para>If you build &slony1; on the same system on which it 
    62 is to be deployed, and build from sources, overwriting the old with 
    63 the new is as easy as <command>make install</command>.  There is no 
    64 need to restart a database backend; just to stop &lslon; processes, 
    65 run the <command>UPDATE FUNCTIONS</command> script, and start new 
    66 &lslon; processes.</para> 
    67  
    68 <para> Unfortunately, this approach requires having a build 
    69 environment on the same host as the deployment.  That may not be 
    70 consistent with efforts to use common &postgres; and &slony1; binaries 
    71 across a set of nodes. </para> 
     54<varlistentry><term>Exécuter <command>make install</command> pour installer les nouveaux 
     55    composants &slony1; au dessus des anciens.</term> 
     56 
     57<listitem><para>Si vous compiler &slony1; sur le systÚme sur où il sera  
     58    déployé et que vous compiler à partir des sources, écraser l'ancienne 
     59    version avec la nouvelle se fait simplement avec <command>make install</command>. 
     60    Il n'est pas nécessaire de relancer la base de donnée, il faut juste arrêter les 
     61    processus &slony1;, exécuter le script <command>UPDATE FUNCTIONS</command> et démarrer  
     62    les nouveaux processus &lslon;.</para> 
     63 
     64<para>Malheureusement cette approche nécessite un environnement de  
     65  compilation sur le serveur où la mise à jour sera déployée.  
     66  Ceci n'est pas forcément compatible avec la volonté d'utiliser  
     67  des binaires commun à &postgres; et &slony; sur l'ensemble des noeuds. 
     68</para> 
    7269</listitem></varlistentry> 
    7370 
    74 <varlistentry><term>Create a new &postgres; and &slony1; build</term> 
    75  
    76 <listitem><para>With this approach, the old &postgres; build with old 
    77 &slony1; components persists after switching to a new &postgres; build 
    78 with new &slony1; components. In order to switch to the new &slony1; 
    79 build, you need to restart the 
    80 &postgres; <command>postmaster</command>, therefore interrupting 
    81 applications, in order to get it to be aware of the location of the 
    82 new components. </para></listitem></varlistentry> 
     71<varlistentry><term>Compiler à nouveau &postgres; et &slony1;</term> 
     72 
     73<listitem><para>Avec cette approche, l'ancienne version de &postgres; accompagnée des  
     74    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  
     76    vers la nouvelle version de &slony1; vous devez redémarrer le  
     77    serveur <command>postmaster</command> &postgres;, ce qui implique l'interruption des  
     78    applications. afin que le serveur soit informé de l'emplacement des nouveaux composants. 
     79 </para></listitem></varlistentry> 
    8380 
    8481</variablelist> 
    8582 
    86 <sect2> <title> TABLE ADD KEY issue in &slony1; 2.0 </title>  
    87  
    88 <para> Usually, upgrades between &slony1; versions have required no 
    89 special attention to the condition of the existing replica.  That is, 
    90 you fairly much merely need to stop &lslon;s, put new binaries in 
    91 place, run <xref linkend="stmtupdatefunctions"/> against each node, and 
    92 restart &lslon;s.  Schema changes have been internal to the cluster 
    93 schema, and <xref linkend="stmtupdatefunctions"/> has been capable to 
    94 make all of the needed alterations.  With version 2, this changes, if 
    95 there are tables that used <xref linkend="stmttableaddkey"/>.  Version 
    96 2 does not support the <quote>extra</quote> column, and 
    97 <quote>fixing</quote> the schema to have a proper primary key is not 
    98 within the scope of what <xref linkend="stmtupdatefunctions"/> can 
    99 perform.  </para> 
    100  
    101 <para> When upgrading from versions 1.0.x, 1.1.x, or 1.2.x to version 
    102 2, it will be necessary to have already eliminated any such 
    103 &slony1;-managed primary keys. </para> 
    104  
    105 <para> One may identify the tables affected via the following SQL 
    106 query: <command> select n.nspname, c.relname from pg_class c, 
    107 pg_namespace n where c.oid in (select attrelid from pg_attribute where 
    108 attname like '_Slony-I_%rowID' and not attisdropped) and reltype <> 0 
     83<sect2> <title> ProblÚme avec TABLE ADD KEY dans &slony1; 2.0 </title>  
     84 
     85<para> Généralement, les mises à jour de versions &slony1; ne nécessitent 
     86  pas de porter une attention particuliÚre au réplicat existant. C'est à dire  
     87  que vous pouvez simplement arrêter les &slon;s, mettre en place les binaires,  
     88  lancer  <xref linkend="stmtupdatefunctions"/> sur chaque noeud et redémarrer &lslon;s. 
     89  Les modifications de schéma étant internes au schéma du cluster, <xref linkend="stmtupdatefunctions"/> 
     90  est capable de réaliser toutes les altérations. Avec la version 2, cela change si il existe des 
     91  tables qui utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas la colonne  
     92  <quote>extra</quote>, et <quote>réparer</quote> le schéma pour obtenir une clé primaire correcte 
     93  n'est pas dans les attributions de <xref linkend="stmtupdatefunctions"/>.</para> 
     94 
     95<para> Lorsque que l'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une version  
     96  2, il est nécessaire de supprimer toute clé primaire gérée par &slony1;.</para> 
     97 
     98<para>On peut identifier les tables concernées avec la requête SQL suivantes : 
     99   <command> SELECT n.nspname, c.relname FROM pg_class c, 
     100pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE 
     101attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype <> 0 
    109102and n.oid = c.relnamespace order by n.nspname, c.relname; </command> 
    110103</para> 
    111104 
    112 <para> The simplest approach that may be taken to rectify the 
    113 <quote>broken</quote> state of such tables is as follows: </para> 
    114  
    115 <itemizedlist> 
    116  
    117 <listitem><para> Drop the table from replication using the &lslonik; 
    118 command <xref linkend="stmtsetdroptable"/>. </para> 
    119  
    120 <para> This does <emphasis>not</emphasis> drop out the 
    121 &slony1;-generated column. </para> 
    122 </listitem> 
    123  
    124 <listitem><para> On each node, run an SQL script to alter the table, 
    125 dropping the extra column.</para> <para> <command> alter table 
    126 whatever drop column "_Slony-I_cluster-rowID";</command> </para> 
    127  
    128 <para> This needs to be run individually against each node.  Depending 
    129 on your preferences, you might wish to use <xref 
    130 linkend="stmtddlscript"/> to do this. </para> 
    131  
    132 <para> If the table is a heavily updated one, it is worth observing 
    133 that this alteration will require acquiring an exclusive lock on the 
    134 table.  It will not hold this lock for terribly long; dropping the 
    135 column should be quite a rapid operation as all it does internally is 
    136 to mark the column as being dropped; it <emphasis>does not</emphasis> 
    137 require rewriting the entire contents of the table.  Tuples that have 
    138 values in that column will continue to have that value; new tuples 
    139 will leave it NULL, and queries will ignore the column.  Space for 
    140 those columns will get reclaimed as tuples get updated.  </para> 
    141  
    142 <para> Note that at this point in the process, this table is not being 
    143 replicated.  If a failure takes place, replication is not, at this 
    144 point, providing protection on this table.  This is unfortunate but 
    145 unavoidable. </para> 
    146 </listitem> 
    147  
    148 <listitem><para> Make sure the table has a legitimate candidate for 
    149 primary key, some set of NOT NULL, UNIQUE columns.  </para> 
    150  
    151 <para> The possible variations to this are the reason that the 
    152 developers have made no effort to try to assist automation of 
    153 this.</para> 
    154  
    155 <itemizedlist> 
    156  
    157 <listitem><para> If the table is a small one, it may be perfectly 
    158 reasonable to do alterations (note that they must be applied to 
    159 <emphasis>every node</emphasis>!) to add a new column, assign it via a 
    160 new sequence, and then declare it to be a primary key.  </para> 
    161  
    162 <para> If there are only a few tuples, this should take a fraction of 
    163 a second, and, with luck, be unnoticeable to a running 
    164 application. </para> 
    165  
    166 <para> Even if the table is fairly large, if it is not frequently 
    167 accessed by the application, the locking of the table that takes place 
    168 when you run <command>ALTER TABLE</command> may not cause much 
    169 inconvenience. </para></listitem> 
    170  
    171 <listitem> <para> If the table is a large one, and is vital to and 
    172 heavily accessed by the application, then it may be necessary to take 
    173 an application outage in order to accomplish the alterations, leaving 
    174 you necessarily somewhat vulnerable until the process is 
    175 complete. </para> 
    176  
    177 <para> If it is troublesome to take outages, then the upgrade to 
    178 &slony1; version 2 may take some planning... </para> 
    179 </listitem> 
    180  
    181 </itemizedlist> 
    182 </listitem> 
    183  
    184 <listitem><para> Create a new replication set (<xref 
    185 linkend="stmtcreateset"/>) and re-add the table to that set (<xref 
     105<para> L'approche la plus simple pour rectifier l'état de ces tables est la suivante : </para> 
     106 
     107<itemizedlist> 
     108 
     109<listitem><para> Retirer la table de la réplication avec la commande &lslonik; 
     110<xref linkend="stmtsetdroptable"/>. </para> 
     111 
     112<para> Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par  
     113&slony1;. </para> 
     114</listitem> 
     115 
     116<listitem><para> Sur chaque noeud, exécutez un script SQL pour modifier  
     117    la table et supprimer les colonnes additionnelles.</para>  <para>  
     118    <command> alter table 
     119nom_table drop column "_Slony-I_cluster-rowID";</command> </para> 
     120 
     121<para>Ceci doit être exécuté sur chaque noeud. Selon votre préférence, vous pouvez utiliser  
     122  <xref linkend="stmtddlscript"/>  pour cela.</para> 
     123 
     124 
     125<para>Si la table est une table massivement mise à jour, sachez que cette modification 
     126  posera un verrou exclusif sur la table. Elle ne détiendra pas ce verrou trÚs longtemps;  
     127  supprimer une colonne est une opération assez rapide car cela ce contente de marquer 
     128  la colonne comme supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire tout le  
     129  contenu de la table. Les tuples qui ont une valeur dans cette colonne continueront à  
     130  avoir cette valeur. Pour les nouveaux tuples le valeur sera NULL, et les requêtes ignorerons 
     131  cette colonne. L'espace occupé par ces colonnes sera récupéré lorsque les tuples  
     132  sera mis à jour. </para> 
     133 
     134<para>Notez qu'à cette étape de la procédure, cette table n'est pas répliquée. 
     135  Si une erreur a lieu, la réplication à cet instant n'apporte aucune protection. 
     136  sur cette table. C'est dommage mais inévitable.</para> 
     137</listitem> 
     138 
     139<listitem><para>Assurez-vous que la table possÚde un candidat éligible  
     140    pour une clé primaire, c'est à dire un ensemble de colonnes  NOT NULL et UNIQUE.</para> 
     141 
     142<para>Les différents cas possibles font que les développeurs  
     143  n'ont pas fait d'efforts pour automatiser cette procédure.</para> 
     144 
     145<itemizedlist> 
     146 
     147<listitem><para> Si la table est petite, il peut être parfaitement 
     148    raisonnable d'ajouter une nouvelle colonne (notez que cela doit 
     149    être fait sur <emphasis>chaque noeud</emphasis> ! ), lui assigner 
     150    une nouvelle séquence et la déclarer comme clé primaire. </para> 
     151 
     152<para>Si il n'y a que quelques tuples, cela ne prendre qu'une fraction de seconde et  
     153  avec de la chance, cela n'aura pas d'impact sur l'application.</para> 
     154 
     155<para>Même si la table est relativement large, mais qu'elle n'est pas  
     156  accédée fréquemment par l'application, alors le verrouillage de la table  
     157  provoqué par <command>ALTER TABLE</command> n'entraînera pas d'inconvénients. 
     158</para></listitem> 
     159 
     160<listitem> <para>Si la table est large, qu'elle est vitale et fortement utilisée 
     161    par l'application, alors il peut être nécessaire de prévoir une coupure  
     162    de service de l'application afin d'accomplir les modifications, ce qui 
     163    vous laissera un peu vulnérable tant que la procédure ne sera pas complétée. 
     164    </para> 
     165 
     166<para>Si une coupure de service est problématique, alors la mise à jour vers  
     167  &slony1; version 2 devra être planifiée avec soin...</para> 
     168</listitem> 
     169 
     170</itemizedlist> 
     171</listitem> 
     172 
     173<listitem><para>Créez un nouvel ensemble de réplication (<xref 
     174linkend="stmtcreateset"/> et ajouter à nouveau la table 
     175    dans cet ensemble (<xref 
    186176linkend="stmtsetaddtable"/>).  </para> 
    187177 
    188 <para> If there are multiple tables, they may be handled via a single 
    189 replication set.</para> 
    190 </listitem> 
    191  
    192 <listitem><para> Subscribe the set (<xref linkend="stmtsubscribeset"/>) 
    193 on all the nodes desired. </para> </listitem> 
    194  
    195 <listitem><para> Once subscriptions are complete, merge the set(s) in, 
    196 if desired (<xref linkend="stmtmergeset"/>). </para> </listitem> 
    197  
    198 </itemizedlist> 
    199  
    200 <para> This approach should be fine for tables that are relatively 
    201 small, or infrequently used.  If, on the other hand, the table is 
    202 large and heavily used, another approach may prove necessary, namely 
    203 to create your own sequence, and <quote>promote</quote> the formerly 
    204 &slony1;-generated column into a <quote>real</quote> column in your 
    205 database schema.  An outline of the steps is as follows: </para> 
    206  
    207 <itemizedlist> 
    208  
    209 <listitem><para> Add a sequence that assigns values to the 
    210 column. </para> 
    211  
    212 <para> Setup steps will include SQL <command>CREATE 
    213 SEQUENCE</command>, SQL <command>SELECT SETVAL()</command> (to set the 
    214 value of the sequence high enough to reflect values used in the 
    215 table), Slonik <xref linkend="stmtcreateset"/> (to create a set to 
    216 assign the sequence to), Slonik <xref linkend="stmtsetaddsequence"/> 
    217 (to assign the sequence to the set), Slonik <xref 
    218 linkend="stmtsubscribeset"/> (to set up subscriptions to the new 
    219 set)</para> 
    220 </listitem> 
    221  
    222 <listitem><para> Attach the sequence to the column on the 
    223 table. </para> 
    224  
    225 <para> This involves <command>ALTER TABLE ALTER COLUMN</command>, 
    226 which must be submitted via the Slonik command <xref 
     178 
     179<para>Si il existe plusieurs tables, elles peuvent être gérées via  
     180  un ensemble de réplication unique.</para> 
     181</listitem> 
     182 
     183<listitem><para>Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>) 
     184sur tous les noeuds désirés. </para> </listitem> 
     185 
     186<listitem><para>Une fois que l'abonnement est complété, fusionnez les ensembles de réplications 
     187    si nécessaire (<xref linkend="stmtmergeset"/>). </para> </listitem> 
     188 
     189</itemizedlist> 
     190 
     191<para>Cette approche devrait fonctionner pour les tables qui sont  
     192  relativement petites, ou rarement utilisées. D'autre part, si la table  
     193  est large et massivement utilisée, une autre approche pourrait être nécessaire, 
     194  c'est à dire créer votre propre séquence, et <quote>promouvoir</quote> l'ancienne 
     195  colonne générée par &slony1; dans une colonne  <quote>réelle</quote> au sein  
     196  du schéma de votre base de données. Les grandes lignes de cette procédure sont 
     197  les suivantes : 
     198 </para> 
     199 
     200<itemizedlist> 
     201 
     202<listitem><para>Ajouter une séquence qui assigne des valeurs à la colonne.</para> 
     203 
     204<para>Les étapes d'installation incluent les commandes SQL <command>CREATE 
     205SEQUENCE</command>, SQL <command>SELECT SETVAL()</command> ( pour définir une valeur  
     206de séquence assez haute pour refléter les valeurs utilisées dans la table), Slonik <xref linkend="stmtcreateset"/> 
     207( pour créer un ensemble de réplication dans lequel on placera la séquence ),  
     208 Slonik <xref linkend="stmtsetaddsequence"/> ( pour placer la séquence dans l'ensemble de réplication), 
     209 Slonik <xref linkend="stmtsubscribeset"/> ( pour définir les abonnements de ce nouvel 
     210 ensemble de réplication )</para> 
     211</listitem> 
     212 
     213<listitem><para>Attachez la séquence à la colonne dans la table. </para> 
     214 
     215<para> Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>, 
     216qui doivent être exécutées via la commande Slonik <xref 
    227217linkend="stmtddlscript"/>. </para> 
    228218</listitem> 
    229219 
    230 <listitem><para> Rename the column 
    231 <envar>_Slony-I_@CLUSTERNAME@_rowID</envar> so that &slony1; won't 
    232 consider it to be under its control.</para> 
    233  
    234 <para> This involves <command>ALTER TABLE ALTER COLUMN</command>, 
    235 which must be submitted via the Slonik command <xref 
     220<listitem><para> Renommez la colonne  
     221<envar>_Slony-I_@CLUSTERNAME@_rowID</envar> afin que &slony1; ne considÚre  
     222pas qu'elle est sous son contrÃŽle.</para> 
     223 
     224<para> Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>, 
     225qui doivent être exécutées via la commande Slonik <xref 
    236226linkend="stmtddlscript"/>. </para> 
    237  
    238 <para> Note that these two alterations might be accomplished via the 
    239 same <xref linkend="stmtddlscript"/> request. </para> 
     227</listitem> 
     228 
     229<para>Notez que ces deux modifications peuvent être accomplies au sein 
     230  d'une requête <xref linkend="stmtddlscript"/> unique. </para> 
    240231</listitem> 
    241232 
    …… 
    244235</sect2> 
    245236 
    246 <sect2> <title> New Trigger Handling in &slony1; Version 2 </title> 
    247  
    248 <para> One of the major changes to &slony1; is that enabling/disabling 
    249 of triggers and rules now takes place as plain SQL, supported by 
    250 &postgres; 8.3+, rather than via <quote>hacking</quote> on the system 
    251 catalog. </para> 
    252  
    253 <para> As a result, &slony1; users should be aware of the &postgres; 
    254 syntax for <command>ALTER TABLE</command>, as that is how they can 
    255 accomplish what was formerly accomplished via <xref 
    256 linkend="stmtstoretrigger"/> and <xref linkend="stmtdroptrigger"/>.  
     237<sect2> <title> Nouvelle gestion des triggers dans &slony1; Version 2 </title> 
     238 
     239<para> Un des changement majeurs de &slony1; est que l'activation et la désactivation 
     240  des triggers et rÚgles ("rules") se fait maintenant entiÚrement en SQL, supporté  
     241  par &postgres; 8.3+, plutÃŽt que via des modifications directes dans le catalogue 
     242  systÚme. </para> 
     243 
     244<para>Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe &postgres; pour 
     245<command>ALTER TABLE</command>, car c'est ainsi qu'ils accompliront ce qu'ils accomplissait  
     246précédemment via les commandes <xref 
     247linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.  
    257248</para> 
    258249</sect2>