Changeset 1127

Show
Ignore:
Timestamp:
08/24/08 22:54:14 (3 months ago)
Author:
daamien
Message:

Slony : addthings ( à relire )

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/addthings.xml

    r1125 r1127  
    66 
    77<sect1 id="addthings"> 
    8 <title>Une vue des taches  &slony1;</title> 
     8<title>Ajouter des objets à la réplication</title> 
    99 
    1010<indexterm><primary>ajouter des objets à la réplication</primary></indexterm> 
    …… 
    3838il existait toujours un problÚme avec <xref linkend="stmtmergeset"/>, 
    3939si la commande était lancée avant que tous les abonnements soient complets, 
    40 des <quote>perturbations</quote> pouvaient apparaitre sur les noeuds  
     40des <quote>perturbations</quote> pouvaient apparaître sur les noeuds  
    4141où l'activité d'abonnement n'était pas terminée. </para> 
    4242 
    …… 
    6060complexes en s'assurant qu'un changement a été parfaitement réussi avant  
    6161de passer au suivant. Il est beaucoup plus simple de corriger un problÚme 
    62 unique que de réparer les dégats provoqués par l'interaction erronée de cing commandes 
     62unique que de réparer les dégâts provoqués par l'interaction erronée de cinq commandes 
    6363successives.<</para> 
    6464 
    …… 
    7070<indexterm><primary> ajouter une table dans le cluster de réplication </primary></indexterm> 
    7171 
    72 <para> &slony1; ne vous permet pas d'ajouter une table dans un ensemblde de 
     72<para> &slony1; ne vous permet pas d'ajouter une table dans un ensemble de 
    7373qui est déjà en cours de réplication. En principe, c'est certainement  
    7474<emphasis>possible</emphasis>; mais cela implique l'événement SET_ADD_TABLE  
    …… 
    137137de tables répliquées ?</quote></para> 
    138138 
    139 <para>Si vous changez la <quote>shape</quote> d'une table répliquée, vous devez le  
     139<para>Si vous changez la <quote>forme</quote> d'une table répliquée, vous devez le  
    140140faire au même instant dans le <quote>flux de transaction</quote> sur tous les noeuds 
    141141qui sont abonnés à l'ensemble qui contient la table.</para> 
    …… 
    160160<itemizedlist> 
    161161<listitem><para> Vous <emphasis>ne devez absolument jamais</emphasis> inclure 
    162 des commandes de controle de transaction, notamment <command>BEGIN</command> 
     162des commandes de contrÃŽle de transaction, notamment <command>BEGIN</command> 
    163163et <command>COMMIT</command>, à l'intérieur de ces scripts. &slony1; 
    164164encapsule les scripts DDL avec une paire <command>BEGIN</command>/<command>COMMIT</command>  
    165 ; ajouter de opérateur de controle de transaction supplémentaire  
     165; ajouter de opérateur de contrÃŽle de transaction supplémentaire  
    166166implique que des parties des ordres DDL seront <quote>committés</quote> 
    167 en dehors du controle de &slony1; </para></listitem> 
     167en dehors du contrÃŽle de &slony1; </para></listitem> 
    168168 
    169169<listitem><para> Avant la  version 1.2, il était nécessaire d'être  
    …… 
    172172 
    173173<para> Il était interdit de placer du texte <command>'entre quotes'</command>  
    174 dans le script, car cela l'empéchait d'être stocké et transmis correctement 
     174dans le script, car cela l'empêchait d'être stocké et transmis correctement 
    175175. A partir de la version 1.2, les quotes sont correctement prises en compte. </para> 
    176176 
    177 <para> Si vous soumettez une séries d'order DDL, les derniers 
     177<para> Si vous soumettez une séries d'ordre DDL, les derniers 
    178178ne peuvent pas faire référence aux objets créés par les premiers, 
    179179car tous les ordres sont soumis dans un requête unique, 
    180 dont le plan d'execution est basé sur l'état de la base de donnée 
     180dont le plan d'exécution est basé sur l'état de la base de donnée 
    181181au <emphasis>début</emphasis>, avant que les modifications ne soient 
    182182effectuées. À partir de la version 1.2, il y a 12 ordres SQL, chacun est soumis 
    …… 
    220220pour supprimer un noeud du cluster. Ceci provoquera la suppression 
    221221des triggers et tout ce qui se trouve dans schéma cluster. 
    222 Le processus <xref linkend="slon"/> sera automatiquement mourrir.</para></listitem> 
     222Le processus <xref linkend="slon"/> sera automatiquement mourir.</para></listitem> 
    223223 
    224224<listitem><para> Dans le cas d'un noeud en échec ( lorsque vous avez utilisé 
    …… 
    232232En général, la base ne survive que lorsque la panne matérielle est un  
    233233problÚme de réseau qui n'endommage pas les données mais qui vous oblige à  
    234 supprimer le noeud à cause de coupures réseau persitantes. 
     234supprimer le noeud à cause de coupures réseau persistantes. 
    235235</para></listitem> 
    236236 
    …… 
    279279<listitem><para> Si le noeud était un noeud en échec, vous devez lancer 
    280280la commande  <xref linkend="slonik"/> <xref linkend="stmtdropnode"/>  
    281 afin de vous débarasser de ses vestiges dans le cluster et de supprimer 
     281afin de vous débarrasser de ses vestiges dans le cluster et de supprimer 
    282282le schéma que &slony1; a créé. 
    283283</para></listitem> 
    …… 
    288288 
    289289<listitem><para> À cet instant, vous pouvez lancer le démon &lslon; sur le nouveau  
    290 noeud. Il ne connaitra rien des autres noeuds, donc les logs de ce noeud seront 
     290noeud. Il ne connaîtra rien des autres noeuds, donc les logs de ce noeud seront 
    291291particuliÚrement calmes. 
    292292</para></listitem> 
    …… 
    302302 
    303303<listitem><para> A cet instant, lancer le script  
    304 <command>test_slony_state-dbi.pl</command> est une excellente idée, which rummages 
    305 through the state of the entire cluster, pointing out any anomalies 
    306 that it finds.  This includes a variety of sorts of communications 
    307 problems.</para> </listitem> 
    308  
    309 <listitem><para> Issue the slonik 
    310 command <xref linkend="stmtsubscribeset"/> to subscribe the node to 
    311 some replication set. 
    312 </para></listitem> 
    313  
    314 </itemizedlist> 
    315 </sect2> 
    316  
    317 <sect2><title> How do I reshape subscriptions?</title> 
    318  
    319 <para> For instance, I want subscriber node 3 to draw data from node 
    320 1, when it is presently drawing data from node 2. </para> 
    321  
    322 <para> This isn't a case for <xref linkend="stmtmoveset"/>; we're not 
    323 shifting the origin, just reshaping the subscribers. </para> 
    324  
    325 <para> For this purpose, you can simply submit <xref 
    326 linkend="stmtsubscribeset"/> requests to <emphasis>revise</emphasis> 
    327 the subscriptions.  Subscriptions will not be started from scratch; 
    328 they will merely be reconfigured.  </para></sect2> 
    329  
    330 <sect2><title> How do I use <link linkend="logshipping">Log Shipping?</link> </title>  
    331 <para> Discussed in the <link linkend="logshipping"> Log Shipping </link> section... </para> 
    332 </sect2> 
    333  
    334 <sect2><title> How do I know replication is working?</title>  
    335  
    336 <para> The ultimate proof is in looking at whether data added at the 
    337 origin makes it to the subscribers.  That's a <quote>simply matter of 
    338 querying</quote>.</para> 
    339  
    340 <para> There are several ways of examining replication status, however: </para> 
    341 <itemizedlist> 
    342 <listitem><para> Look in the &lslon; logs.</para>  
    343  
    344 <para> They won't say too much, even at very high debugging levels, on 
    345 an origin node; at debugging level 2, you should see, on subscribers, 
    346 that SYNCs are being processed.  As of version 1.2, the information 
    347 reported for SYNC processing includes counts of the numbers of tables 
    348 processed, as well as numbers of tuples inserted, deleted, and 
    349 updated.</para> </listitem> 
    350  
    351 <listitem><para> Look in the view <command> sl_status </command>, on 
    352 the origin node. </para> 
    353  
    354 <para> This view will tell how far behind the various subscribing 
    355 nodes are in processing events from the node where you run the query. 
    356 It will only be <emphasis>very</emphasis> informative on a node that 
    357 originates a replication set.</para> </listitem> 
    358  
    359 <listitem><para> Run the <filename>tools</filename> 
    360 script <command>test_slony_state-dbi.pl</command>, which rummages 
    361 through the state of the entire cluster, pointing out any anomalies 
    362 that it notices, as well as some information on the status of each 
    363 node. </para> </listitem> 
    364  
    365 </itemizedlist> 
    366  
    367 </sect2> 
    368  
    369 <sect2><title>How do I upgrade &slony1; to a newer version? </title> 
    370  
    371 <para> Discussed  <link linkend="slonyupgrade"> here </link> </para> </sect2> 
    372  
    373 <sect2><title> What happens when I fail over?</title>  
    374  
    375 <para> Some of this is described under <xref linkend="failover"/> but 
    376 more of a procedure should be written...</para> </sect2> 
    377  
    378 <sect2><title> How do I <quote>move master</quote> to a new node? </title>  
    379  
    380 <para> You must first pick a node that is connected to the former 
    381 origin (otherwise it is not straightforward to reverse connections in 
    382 the move to keep everything connected). </para> 
    383  
    384 <para> Second, you must run a &lslonik; script with the 
    385 command <xref linkend="stmtlockset"/> to lock the set on the origin 
    386 node.  Note that at this point you have an application outage under 
    387 way, as what this does is to put triggers on the origin that rejects 
    388 updates. </para> 
    389  
    390 <para> Now, submit the &lslonik; <xref linkend="stmtmoveset"/> request. 
    391 It's perfectly reasonable to submit both requests in the same 
    392 &lslonik; script.  Now, the origin gets switched over to the new 
    393 origin node.  If the new node is a few events behind, it may take a 
    394 little while for this to take place. </para> </sect2> 
    395  
    396 <sect2> <title> How Do I Do A <quote>Full Sync</quote> On A Table? </title> 
    397  
    398 <para> The &slony1; notion of a <command>SYNC</command> is actually 
    399 always an <emphasis>incremental</emphasis> thing; a 
    400 <command>SYNC</command> represents the set of updates that were 
    401 committed during the scope of a particular <command>SYNC</command> 
    402 event on the origin node.  If a set of updates that altered the entire 
    403 contents of a table were committed in a single 
    404 <command>SYNC</command>, that would affect the entire contents of the 
    405 table.  But as far as &slony1; is concerned, this change is 
    406 <quote>incremental</quote> even though the increment happened to be 
    407 <quote>the whole table.</quote> </para> 
    408  
    409 <para> The only time that &slony1; <quote>synchronizes</quote> the 
    410 contents of a table is at the time the subscription is set up, at 
    411 which time it uses <command>COPY</command> to draw in the entire 
    412 contents from the provider node.</para> 
    413  
    414 <para> Since subscriber tables are protected against modification by 
    415 anything other than &slony1;, there should be no way (aside from 
    416 horrible bugs) for tables to fall out of synchronization.  If they do, 
    417 there is some rather serious problem with &slony1;. </para> 
    418  
    419 <para> If some such severe corruption takes place, the answer is to 
    420 drop the table from replication, then create a new replication set and 
    421 add it back. </para> 
    422  
    423 </sect2> 
    424  
     304<command>test_slony_state-dbi.pl</command> est une excellente idée. 
     305Ce script parcours le cluster le tout entier et pointe les anomalies 
     306qu'il trouve.  Il peut notamment identifier une grande variété de  
     307problÚmes de communication.</para> </listitem> 
     308 
     309<listitem><para> Lancer commande slonik 
     310<xref linkend="stmtsubscribeset"/> pour abonner le noeud à l'ensemble de réplication. 
     311</para></listitem> 
     312 
     313</itemizedlist> 
     314</sect2> 
     315 
     316<sect2><title> Comment remanier les abonnements ?</title> 
     317 
     318<para> Par exemple, on souhaite que le noeud 3 reçoivent les données 
     319en provenance du noeud 1, alors qu'actuellement il reçoit les données du noeud 2. </para> 
     320 
     321<para> Il ne s'agit pas d'un cas d'utilisation de la commande <xref linkend="stmtmoveset"/>;  
     322car on ne souhaite pas déplacer l'origine, mais simplement remanier les abonnés. 
     323</para> 
     324 
     325<para> Pour cela, on peut simplement soumettre des requêtes <xref 
     326linkend="stmtsubscribeset"/> pour <emphasis>modifier</emphasis> 
     327les abonnements.  Ces abonnements ne seront pas redémarrés à partir de zéro, 
     328mais simplement reconfigurés. 
     329</para></sect2> 
     330 
     331<sect2><title> Comment utiliser le <link linkend="logshipping">Log Shipping</link> ?</title>  
     332<para> Cette question est largement débattue dans la section <link linkend="logshipping"> Log Shipping </link>... </para> 
     333</sect2> 
     334 
     335<sect2><title> Comment savoir si la réplication fonctionne ?</title>  
     336 
     337<para> La preuve ultime est le fait que les données ajoutées sur l'origine  
     338soit présentes sur les abonnés. Il suffit <quote>simplement de lancer une 
     339requête</quote> pour le savoir.</para> 
     340 
     341<para> Cependant, il existe quelques autres méthode pour examiner l'état de la réplication : </para> 
     342<itemizedlist> 
     343<listitem><para> Regarder les logs des processus &lslon;.</para>  
     344 
     345<para> Ils ne vous diront pas grand chose, même à une niveau de debug  
     346élevé sur le noeud origine; Au niveau 2 de debug, vous devriez voir 
     347sur les abonnés les événements SYNCs qui sont en cours de traitement. 
     348À partir de la version 1.2, les informations sur le traitement des  
     349SYNCs incluent le nombres de tables traitées, ainsi que le nombre 
     350de tuples insérés, supprimés et mis à jour.</para> </listitem> 
     351 
     352<listitem><para> Regarder dans la vue <command> sl_status </command>, sur 
     353le noeud origine. </para> 
     354 
     355<para> Cette vue indique quel est le retard des différents noeuds abonnés. 
     356Cette information n'est pertinente que sur un noeud origine.</para> </listitem> 
     357 
     358<listitem><para> Lancer le script 
     359script <command>test_slony_state-dbi.pl</command> qui se trouve dans le répertoire  
     360<filename>tools</filename>. Ce script parcours le cluster tout entier et pointe les  
     361anomalies qu'il détecte, ainsi que des informations sur le statut de chaque noeud. 
     362</para> </listitem> 
     363 
     364</itemizedlist> 
     365 
     366</sect2> 
     367 
     368<sect2><title>Comment mettre à jour la version de &slony1; ? </title> 
     369 
     370<para> La réponse se trouve  <link linkend="slonyupgrade"> ici </link> </para> </sect2> 
     371 
     372<sect2><title> Que se passe-t-il lors d'une bascule d'urgence ?</title>  
     373 
     374<para> Une partie de la réponse se trouve dans la section <xref linkend="failover"/> 
     375mais il reste beaucoup de choses à écrire sur le sujet...</para> </sect2> 
     376 
     377<sect2><title> Comment <quote>déplacer le maître</quote> vers un autre noeud ? </title>  
     378 
     379<para> Tout d'abord il faut choisir un noeud qui est connecté à l'ancienne origine 
     380(sinon il n'est pas évident de conserver les connexions lors du changement). </para> 
     381 
     382<para> DeuxiÚmement, vous devez lancer un script &lslonik; avec la commande  
     383<xref linkend="stmtlockset"/> pour verrouiller l'ensemble de réplication sur  
     384le noeud origine. Notez qu'à cet instant votre application risque de ne plus fonctionner, 
     385car cette opération pose des triggers sur l'origine qui rejetent toutes les mises  
     386à jour. </para> 
     387 
     388<para> Maintenant, lancez la requête &lslonik; <xref linkend="stmtmoveset"/>. 
     389Il parfaitement raisonnable de soumettre les deux requêtes à l'intérieur 
     390d'un même script &lslonik;.   
     391 
     392Désormais, l'origine est basculée vers le nouveau noeud origine. Si le nouveau noeud a quelques  
     393événement de retard, il faudra un peu de temps pour que tout se mette en place. </para> </sect2> 
     394 
     395<sect2> <title> Comment réaliser <quote>synchronisation complÚte</quote> sur une table? </title> 
     396 
     397<para> Pour &slony1;, la  notion de <command>SYNC</command> est toujours quelque chose  
     398d'<emphasis>incrémental</emphasis>; un <command>SYNC</command> représente 
     399un ensemble de mises à jour qui furent <quote>committée</quote> pendant 
     400durée d'un événement <command>SYNC</command> donné sur le noeud origine. 
     401Si des mises à jour qui ont altérées l'ensemble du contenu d'une  
     402table sont <quote>committées</quote> au cours d'un  
     403<command>SYNC</command> unique, alors cela affectera l'ensemble 
     404du contenu de la table. Mais du point de vue de &slony1;, ce changement est  
     405<quote>incrémental</quote> même si la modification concerne 
     406<quote>la table toute entiÚre</quote>.</para> 
     407 
     408<para> La seule fois où &slony1; <quote>synchronise</quote> le contenu  
     409d'une table est lors de la mise en place de l'abonnement, à ce moment-là 
     410il utilise la commande <command>COPY</command> pour rapatrier la totalité  
     411du contenu de la table à partir du noeud fournisseur.</para> 
     412 
     413<para> Puisque les tables abonnées sont protégées contre les modifications 
     414réalisées par un autre utilisateur que &slony1;, il est impossible 
     415(mis à part d'horribles bogues) que les tables soient désynchronisées.   
     416Si c'est le cas, alors il y a vraiment un gros problÚme dans &slony1;. </para> 
     417 
     418<para> Si une corruption trÚs grave se produit, la réponse est de retirer la table  
     419hors de la réplication, puis de créer un nouvel ensemble de réplication et de l'ajouter  
     420à nouveau. </para> 
     421</sect2> 
    425422</sect1>