forked from gleu/pgdocs_fr
/
slonik_ref.xml
3117 lines (2628 loc) · 127 KB
/
slonik_ref.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<article id="slonikref">
<title>Tour d'horizon des commandes Slonik</title>
<sect1><title>Introduction</title>
<para><application>Slonik</application> est un utilitaire en ligne de commande
conçu spécifiquement pour mettre en place et modifier la configuration
du système de réplication &slony1;.</para>
<sect2 id="outline">
<title>Considérations générales</title>
<para>
L'utilitaire en ligne de commande <application>slonik</application>
est supposé être intégré dans des scripts shell et lit
les commandes à partir d'un fichier ou de stdin (voir plus
bas pour des exemples). Presque tout le travail de configuration
<emphasis>réel</emphasis> est effectué en appelant des procédures
stockées après avoir chargé la base de support &slony1; dans
la base de données. Vous pouvez trouver de la documentation sur
ces procédures dans le chapitre <ulink url="schemadoc">Documentation
du schéma de &slony1;</ulink>, ainsi que dans les commentaires
qui sont associés aux procédures dans la base de données.
</para>
<para>
<application>Slonik</application> a été créé car :
<itemizedlist>
<listitem><para>Les procédures stockées ont des besoins d'informations
spécifiques telles que l'identifiant du nœud de réplication
sur lequel elles sont appelées ;</para></listitem>
<listitem><para>L'absence de paramètres nommés dans les
procédures stockées rend difficile de faire cela depuis
l'invite de commande <application>psql</application> ;
</para></listitem>
<listitem><para><application>psql</application> n'a pas la possibilité
de maintenir plusieurs connexions avec des transactions ouvertes.
</para></listitem>
</itemizedlist>
</para>
<para>
</para>
<sect3><title>Commandes</title>
<para>Le format du langage de commande slonik est libre.
Les commandes commencent par des mots-clefs et sont terminées
par un point-virgule. La plupart des commandes ont une liste de
paramètres, certains ont une valeur par défaut et sont donc
facultatifs. Les paramètres de commandes sont entourés par des
parenthèses. Chaque option est constituée d'un ou plusieurs
mots-clefs, suivis d'un symbole égal, suivi d'une valeur. Les
options multiples à l'intérieur de parenthèses sont séparées par
des virgules. Tous les mot-clefs sont sensibles à la casse. Le
langage devrait rappeler le SQL.</para>
<para>Les valeurs d'option peuvent être :</para>
<itemizedlist>
<listitem><para>des entiers ;</para></listitem>
<listitem><para>des chaînes de caractères entourés de guillemets ;</para></listitem>
<listitem><para>des valeurs booléennes {TRUE|ON|YES} ou {FALSE|OFF|NO} ;</para></listitem>
<listitem><para>des mots-clefs dans des cas spécifiques.</para></listitem>
</itemizedlist>
</sect3>
<sect3><title>Commentaires</title>
<para>Les commentaires commencent par un dièse (#) et vont jusqu'à la fin de la ligne.</para>
</sect3>
<sect3><title>Groupes de commandes</title>
<para>Les commandes peuvent être combinées par groupes de commandes avec une
éventuellement une condition <command>on error</command> et
<command>on success</command>.
La syntaxe est la suivante :
<programlisting>
try {
commands;
}
[on error { commands; }
[on success { commands; }
</programlisting></para>
<para>Ces commandes sont regroupées ensemble au sein d'une transaction
pour chaque nœud participant.</para>
<para>
Notez que ceci ne force par le groupement des actions sur une seule
transaction pour tous les nœuds. Par exemple, jetez un œil
au code slonik suivant :
</para>
<programlisting>
try {
execute script (set id = 1, filename = '/tmp/script1.sql', event node=1);
execute script (set id = 1, filename = '/tmp/script2.sql', event node=1);
}
</programlisting>
<para>
Ceci <emphasis>pourrait</emphasis> être taitré dans une transaction
simple sur le nœud 1. Néanmoins, les requêtes sont séparées en
deux événements <command>DDL_SCRIPT</command> de façon à ce que chacune
d'elle soit exécutée individuellement, dans des transactions séparées,
sur les autres nœuds du cluster.
</para>
</sect3>
</sect2>
</sect1>
</article>
<!-- ************************************************************ -->
<reference id="metacmds">
<title>Méta-commandes Slonik</title>
<partintro>
<para>Les commandes suivantes sont utilisées pour séparer
les définitions des composants des scripts Slonik ;
<xref linkend="stmtinclude"/> regroupe la configuration
dans des fichiers centraux qui peuvent être réutilisés, et
<xref linkend="stmtdefine"/> permet de remplacer les identifiants
numériques et ésotériques des objets par des identifiants mnémotechniques.</para>
</partintro>
<!-- **************************************** -->
<refentry id ="stmtinclude">
<refmeta><refentrytitle>SLONIK INCLUDE</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv>
<refname>INCLUDE</refname>
<refpurpose>insérer du code slonik à partir d'un autre fichier</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>include </command>
<arg><replaceable class="parameter"><chemin></replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Ceci injecte le script slonik spécifié à l'intérieur du script actuel.
Si le <option>chemin</option> est relatif, <xref linkend="slonik"/>
cherchera à partir du répertoire de travail.</para>
<para>Les inclusions imbriquées sont supportées. Le scanner et l'analyseur
retournent le bon nom de fichier et le numéro ligne correcte en cas
d'erreur.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
include </tmp/preamble.slonik>;
</programlisting>
</refsect1>
<refsect1><title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.1.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id ="stmtdefine"><refmeta><refentrytitle>SLONIK DEFINE</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>DEFINE</refname>
<refpurpose>Définir un nom symbolique</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>define </command>
<arg><replaceable class="parameter">nom</replaceable></arg>
<arg><replaceable class="parameter">valeur</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Ceci définit un nom symbolique. Les noms symboliques doivent
respecter les règles de slonik en matière de construction d'identifiants,
en commençant par une lettre, suivie de lettres, de nombres et de soulignés
(« _ »).</para>
<para>Les valeurs des noms symboliques peuvent contenir des espaces et peuvent contenir
des références à des noms symboliques, de manière récursive.</para>
<para>Les symboles sont référencés en utilisant une arobase <quote>@</quote> suivi
du nom symbolique. Notons que le référencement d'un symbole est annulé
à l'intérieur des chaînes de caractères.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
define cluster films;
define sakai 1;
define chen 2;
define fqn fully qualified name;
cluster name = @cluster;
node @sakai admin conninfo = 'service=sakai-replication';
node @chen admin conninfo = 'service=chen-replication';
define setFilms id = 1;
define sakaiFilms @setFilms, origin = @sakai;
create set ( @sakaiFilms, comment = 'films' );
set add table( set @sakaiFilms, id = 1, @fqn = 'public.clients',
comment = 'sakai customers' );
set add table( set @sakaiFilms, id = 2, @fqn = 'public.cassettes',
comment = 'sakai cassettes' );
echo '@sakaiFilms sera affiché comme une chaîne, et ne sera pas interprété';
</programlisting>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.1.</para>
</refsect1>
</refentry>
</reference>
<!-- **************************************** -->
<reference id="hdrcmds">
<title>Commandes slonik préliminaires</title>
<partintro>
<para>Les commandes suivantes doivent apparaître en <quote>préambule</quote>
de chaque script de commande <application>slonik</application>.
Ils ne provoquent aucune action directement sur les nœuds du
système de réplication, mais affecte l'exécution du script tout entier.</para>
</partintro>
<refentry id ="clustername">
<refmeta><refentrytitle>SLONIK CLUSTER NAME</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv>
<refname>CLUSTER NAME</refname>
<refpurpose>préambule - identifier le cluster &slony1;</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>CLUSTER NAME = </command>
<arg><replaceable class="parameter">nom</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Ceci doit être la toute première ligne de chaque script
<application>slonik</application>. Elle définit le schéma
dans lequel toutes les fonctions spécifiques, les procédures,
les tables et les séquences de &slony1; sont déclarées.
Le nom du schéma est construit en préfixant la chaîne
de caractères fournie par un souligné. Ce schéma sera
identique sur toutes les bases de données qui participent
au même groupe de réplication.</para>
<para>Aucun objet utilisateur n'est supposé être placé dans ce schéma,
et ce schéma ne doit pas exister avant l'ajout de la base de données
dans le système de réplication. Ainsi, si vous ajoutez un nouveau nœud
en utilisant <command>pg_dump -s</command> sur une base qui est déjà
dans le cluster de réplication, vous devrez supprimer le schéma
avec la commande SQL <command> DROP SCHEMA _testcluster CASCADE;</command>.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
CLUSTER NAME = testcluster;
</programlisting>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<refentry id ="admconninfo">
<refmeta><refentrytitle>SLONIK ADMIN CONNINFO</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv>
<refname>ADMIN CONNINFO</refname>
<refpurpose>preambule - identifier la base &postgres;</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>NODE ival ADMIN CONNINFO = 'DSN';</command>
<arg><replaceable class="parameter">ival</replaceable></arg>
<arg><replaceable class="parameter">'conninfo'</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Décrit comment l'utilitaire <application>slonik</application> peut
atteindre les bases des nœuds du cluster à partir de l'endroit
où il se trouve (en général le poste de travail de l'administrateur).
La chaîne connifo est l'argument passé à la fonction
libpq <function>PQconnectdb()</function>. L'utilisateur qui se connecte
doit être un super-utilisateur spécifique à la réplication car certaines
actions réalisées par la suite comprennent des opérations strictement réservées
aux super-utilisateurs du serveur &postgres;.</para>
<para>L'utilitaire <application>slonik</application> n'essaie de se connecter
à une base de donnée que si une commande nécessite une connexion.</para>
<note><para>Comme indiqué dans les document originaux, &slony1; est conçu comme
un système de réplication d'entreprises pour centres de données. Lors du développement
du logiciel, on présuppose que les serveurs de bases de données et les postes
de travail impliqués dans la réplication et/ou dans les activités de mise en place et
de configuration peuvent utiliser des méthodes simples d'authentification telle que
<quote>trust</quote>. Cependant, libpq peut lire les mots de passe dans le fichier
<filename>.pgpass</filename>.</para></note>
<note><para>Si vous devez changer les informations DSN pour un nœud, par exemple si
l'adresse IP d'un hôte est modifiée, vous devez soumettre cette nouvelle
information avec la commande <xref linkend="stmtstorepath"/>,
et la configuration sera propagée. Certains processus
<application>slon</application> existant devront être relancés afin qu'ils
soient avertis de ce changement de configuration.</para></note>
<para>Pour plus de détails sur la distinction entre ceci et <xref
linkend="stmtstorepath"/>, consultez le chapitre &rplainpaths;.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
</reference>
<!-- ************************************************************ -->
<reference id="cmds">
<title>Commande de configuration et d'action</title>
<refentry id ="stmtecho">
<refmeta>
<refentrytitle>SLONIK ECHO</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv>
<refname>ECHO</refname>
<refpurpose>Outil générique de sortie</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>echo</command>
<arg><replaceable class="parameter">'message'</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Affiche un message littéral sur la sortie standard.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
ECHO 'Nœud 1 initialisé correctement';
</programlisting>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id ="stmtexit"><refmeta><refentrytitle>SLONIK EXIT</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>EXIT</refname>
<refpurpose>Termine un script Slonik avec un signal</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>exit</command>
<arg><replaceable class="parameter"> [-]ival</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
Termine immédiatement un script d'exécution, annulant toute
les transactions ouvertes (ROLLBACK) sur toutes les bases de données
connectées. L'utilitaire <application>slonik</application> retournera
la valeur indiquée comme code de terminaison du programme.
</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
EXIT 0;
</programlisting>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtinitcluster">
<refmeta>
<refentrytitle>SLONIK INIT CLUSTER</refentrytitle>
<manvolnum>7</manvolnum>
</refmeta>
<refnamediv>
<refname>INIT CLUSTER</refname>
<refpurpose>Initialise le cluster &slony1;</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>INIT CLUSTER</command>
<arg>ID = <replaceable class="parameter">entier</replaceable></arg>
<arg>COMMENT = <replaceable class="parameter">'chaîne'</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para> Initialise le premier nœud d'un nouveau cluster de réplication &slony1;.
Le processus d'initialisation consiste à créer le schéma du cluster, à
charger toutes les tables, les fonctions, les procédures et à initialiser le nœud
avec &funinitializelocalnode; et &funenablenode;.
<variablelist>
<varlistentry><term><literal>ID</literal></term>
<listitem><para>L'identifiant numérique et unique du nœud.</para></listitem>
</varlistentry>
<varlistentry><term><literal>COMMENT = 'commentaire'</literal></term>
<listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
la table &slnode;.
</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>Pour que ce processus fonctionne, les scripts SQL du système
&slony1; doivent être installés sur le poste de travail de l'administrateur
(l'ordinateur utilisé pour exécuter l'utilitaire <application>slonik</application>),
tandis que sur le serveur qui héberge le nœud de base de donnée contenant les
objets partagés, &slony1; doit être installé dans le répertoire qui contient
les bibliothèques de &postgres;. De plus le langage procédural
PL/pgSQL doit être installé au préalable sur la base de données cible.
</para>
</refsect1>
<refsect1>
<title>Exemple</title>
<programlisting>
INIT CLUSTER (
ID = 1,
COMMENT = 'Nœud 1'
);
</programlisting>
<note> <para> Cette commande fonctionne de manière similaire à
<xref linkend="stmtstorenode"/>, la différence étant que <command>INIT
CLUSTER</command> n'a pas besoin de récupérer la configuration des autres nœuds.
</para> </note>
<note> <para>Soyez conscients que certains objets qui sont créés contiennent
le nom du cluster à l'intérieur de leur nom (notamment, les index
partiels sur <envar>sl_log_1</envar> et <envar>sl_log_2</envar>).
Ceci implique que les noms de cluster <emphasis>très longs</emphasis>
sont une mauvaise idée car ils entraînent un dépassement des noms
d'objets au delà de la limite de 63 caractères.
</para> </note>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Cette commande crée un nouveau schéma et configure les
tables à l'intérieur ; aucun objet public ne doit être verrouillé
pendant l'exécution de cette commande.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id ="stmtstorenode"><refmeta><refentrytitle>SLONIK STORE NODE</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>STORE NODE</refname>
<refpurpose>Initialise un nœud &slony1;</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>STORE NODE (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Initialise un nouveau nœud et l'ajoute dans la configuration du
cluster existant.</para>
<para>Le processus d'initialisation consiste à la création du schéma
sur le nouveau nœud (la base elle-même doit déjà exister), au
chargement des tables, des fonctions, des procédures et à l'initialisation
du nœud. La configuration existante du reste du nœud est copiée
à partir d'un <quote>nœud d'événement</quote>.
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
<listitem><para>L'identifiant numérique et unique du nouveau nœud.</para>
<para>Notez que l'identifiant n'est pas <emphasis>modifiable</emphasis>
cat il a été utilisé comme base des communications pour les événements
inter-nœuds.</para>
</listitem>
</varlistentry>
<varlistentry><term><literal> COMMENT = 'description' </literal></term>
<listitem><para>Un texte descriptif ajouté à la ligne du nœud dans
la table &slnode;</para></listitem>
</varlistentry>
<varlistentry><term><literal>SPOOLNODE = booléen</literal></term>
<listitem><para>Spécifie qu'un nœud est un nœud virtuel de récupération
pour l'archivage de journaux de réplication. Si ce paramètre est à true,
<application>slonik</application> n'essaiera pas d'initialiser la base de
donnée avec le schéma de réplication.</para>
<warning><para>Ne jamais utiliser la valeur de SPOOLNODE -
aucune version sortie de &slony1; ne s'est comportée de la façon décrite
précédemment. Le log shipping, de la façon dont il a été finalement
implanté en 1.2.11, ne nécessite par d'initialiser les <quote>nœuds
du spool</quote>.</para> </warning></listitem>
</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. Ç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>
</para>
<para>Ceci utilise &funinitializelocalnode; et &funenablenode;.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
STORE NODE ( ID = 2, COMMENT = 'Node 2', EVENT NODE = 1 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Cette commande crée un nouveau schéma et configure les tables
à l'intérieur ; aucun objet public ne doit être verrouillé
pendant l'exécution de cette commande.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0. Le paramètre <envar>SPOOLNODE</envar>
fut introduit dans la version 1.1 mais n'était pas implémentée dans cette version.
La fonctionnalité <envar>SPOOLNODE</envar> est arrivée dans la
version 1.2 mais <envar>SPOOLNODE</envar> n'était pas utiliser dans ce but.
Dans des versions ultérieures, <envar>SPOOLNODE</envar> ne sera pas disponible.</para>
<para>Dans la version 2.0, la valeur par défaut <envar>EVENT NODE</envar> a été supprimée,
donc un nœud doit être spécifié.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtdropnode"><refmeta><refentrytitle>SLONIK DROP NODE</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>DROP NODE</refname>
<refpurpose>Supprime un nœud de la réplication</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>DROP NODE (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
Supprime un nœud. Cette commande retire complètement le nœud spécifié
de la configuration du système de réplication.
Si le démon de réplication est toujours en fonctionnement sur ce nœud
(et qu'ils traitent les événements), il tentera de désinstaller le système
de réplication et s'arrêtera de lui-même.
<variablelist>
<varlistentry><term><literal> ID = ival </literal></term>
<listitem><para>L'identifiant du nœud à supprimer.</para></listitem>
</varlistentry>
<varlistentry><term><literal> EVENT NODE = ival </literal></term>
<listitem><para>L'identifiant du nœud qui génère l'événement.
</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>Cette commande utilise &fundropnode;.</para>
<para>Quand vous invoquez <command>DROP NODE</command>, une des étapes
consiste à lancer <command>UNINSTALL NODE</command>.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
DROP NODE ( ID = 2, EVENT NODE = 1 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Lorsqu'on supprime des triggers d'une table de l'application,
cela nécessite un accès exclusif à chaque table répliquée sur le nœud
que l'on supprime.</para>
</refsect1>
<refsect1><title>Comportement dangereux ou non-intuitif</title>
<para>Si vous utilisez des connexions qui cachent les plans d'exécution
(ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
des pools de connexions), les connexions peuvent cacher des plans
de requêtes qui se basent sur une vision pré-<command>DROP NODE</command>,
ce qui implique que vous obtiendrez des &rmissingoids;.</para>
<para>Ainsi après avoir supprimé un nœud, il est préférable de réinitialiser
les connexions de votre applications.</para>
<para>Vous ne pouvez pas soumettre cela à un <command>EVENT
NODE</command> ayant le même numéro que le nœud que vous supprimez ;
la requête doit aller vers un nœud qui restera dans le cluster.
</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
<para>Dans la version 2.0, la valeur par défaut pour <envar>EVENT NODE</envar> a été supprimée,
donc un nœud doit être spécifié.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtuninstallnode"><refmeta><refentrytitle>SLONIK UNINSTALL NODE</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>UNINSTALL NODE</refname>
<refpurpose>Désinstaller un nœud &slony1;</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>UNINSTALL NODE (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Restaure toutes les tables dans leur état non verrouillé, avec
les triggers d'origines, les contraintes et les règles. Les éventuelles colonnes
spécifiques de &slony1; contenant des clefs SERIAL sont supprimées.
Enfin, le schéma &slony1; est effacé. Le nœud redevient une base de données
indépendante. Les données ne sont pas modifiées.
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
<listitem><para>Identifiant du nœud à désinstaller.</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>Cette commande utilise &fununinstallnode;.</para>
<para>La différence entre <command>UNINSTALL NODE</command>
et <command>DROP NODE</command> est que <command>UNINSTALL
NODE</command> se contente de supprimer la configuration &slony1; ;
il ne retire la configuration du nœud sur l'ensemble de réplication.
</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
UNINSTALL NODE ( ID = 2 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Lorsqu'on supprime les triggers des tables de l'application,
cela nécessite un accès exclusif à chaque table répliquée sur le nœud
que l'on désinstalle.</para>
</refsect1>
<refsect1><title>Comportement dangereux ou non-intuitif</title>
<para>Si vous utilisez des connexions qui cachent les plans d'exécution
(ce qui est particulièrement commun pour les frameworks applicatifs Java utilisant
des pools de connexion), les connexions peuvent cacher des plans
de requêtes qui se basent sur une vision pré-<command>UNINSTALL NODE</command>,
ce qui implique que vous obtiendrez des &rmissingoids;.</para>
<para>Ainsi après avoir désinstallé un nœud, il est préférable de réinitialiser
les connexions de votre applications.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtrestartnode"><refmeta><refentrytitle>SLONIK RESTART NODE</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>RESTART NODE</refname>
<refpurpose>Redémarre un nœud &slony1;</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>RESTART NODE options;</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para> Provoque l'arrêt et le redémarrage d'un démon
(processus <application>slon</application>)
de réplication sur le nœud spécifié.
Théoriquement, cette commande est obsolète. En pratique,
les délais TCP peuvent retarder les changements critiques
de configuration jusqu'à ce qu'il soit effectué alors que le
nœud expéditeur est en échec et doit être ignoré par les
nœuds abonnés.
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
<listitem><para>Identifiant du nœud à redémarrer.</para></listitem>
</varlistentry>
</variablelist>
</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
RESTART NODE ( ID = 2 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0 ; une utilisation
fréquente devient inutile à partir de la version 1.0.5. Néanmoins, dans certains
cas occasionnels, il devient nécessaire d'interrompre le processus
<application>slon</application> et ceci vous permet de scripter via slonik.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtstorepath"><refmeta><refentrytitle>SLONIK STORE
PATH</refentrytitle><manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>STORE PATH</refname>
<refpurpose>Configure la connexion d'un nœud &slony1;</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>STORE PATH (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Configure la connexion d'un démon de réplication d'un nœud
à la base de données d'un autre nœud. Si le système
de réplication est supposé utiliser un segment spécial de réseau,
c'est ici qu'on définit les adresses IP ou les noms d'hôtes.
Une configuration existante peut se trouver écrasée.
</para>
<para>Le paramètre conninfo doit contenir toutes les informations
pour se connecter à la base en tant super-utilisateur de la réplication.
Les termes <quote>serveur</quote> et <quote>client</quote> n'ont
rien à voir avec le rôle particulier d'un nœud dans la configuration
d'un cluster. On peut simplement voir cela comme un
<quote>serveur</quote> ayant un message or une donnée qu'un
<quote>client est supposé obtenir</quote>.
Pour une installation simple avec deux nœuds, les chemins dans les deux
directions doivent être configurés.
</para>
<para>Il ne pose aucun problème de configurer un chemin entre chaque
nœud (produit en croix complète). Les connexions ne sont établis que
si cela est nécessaire pour transférer un événement ou une confirmation
à cause des entrées <emphasis>listen</emphasis> ou une donnée à cause de
<emphasis>souscriptions</emphasis>.
<variablelist>
<varlistentry><term><literal>SERVER = ival</literal></term>
<listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
</varlistentry>
<varlistentry><term><literal>CLIENT = ival</literal></term>
<listitem><para>Identifiant du nœud du démon de réplication qui se connecte.</para></listitem>
</varlistentry>
<varlistentry><term><literal>CONNINFO = string</literal></term>
<listitem><para>Argument <function>PQconnectdb()</function> pour établir la connexion.</para></listitem>
</varlistentry>
<varlistentry><term><literal>CONNRETRY = ival</literal></term>
<listitem><para>Nombre de secondes d'attente avant qu'un autre tentative
de connexion soit faite dans le cas où le serveur est indisponible.
La valeur par défaut est 10.
</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>Cette commande utilise &funstorepath;.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
STORE PATH ( SERVER = 1, CLIENT = 2,
CONNINFO = 'dbname=testdb host=serveur1 user=slony'
);
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtdroppath"><refmeta><refentrytitle>SLONIK DROP PATH</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>DROP PATH</refname>
<refpurpose>Supprime un chemin de connexion &slony1;</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>DROP PATH (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Supprime les informations de connexion entre un <quote>serveur</quote> et un
<quote>client</quote>.</para>
<variablelist>
<varlistentry><term><literal>SERVER = ival</literal></term>
<listitem><para>Identifiant du nœud de la base à laquelle on doit se connecter.</para></listitem>
</varlistentry>
<varlistentry><term><literal>CLIENT = ival</literal></term>
<listitem><para>Identifiant du nœud du démon qui se connecte.</para></listitem>
</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 annonce à tous les nœuds existants que le chemin a été supprimé.
La valeur par défaut est l'identifiant du nœud <quote>client</quote>.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
DROP PATH ( SERVER = 1, CLIENT = 2 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtstorelisten"><refmeta><refentrytitle>SLONIK STORE LISTEN</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>STORE LISTEN</refname>
<refpurpose>Configure un nœud &slony1; en lui indiquant où il
doit écouter les événements</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>STORE LISTEN (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Pour chaque entrée <quote>listen</quote>, le nœud récepteur demande
à un nœud fournisseur de lui envoyer les événements d'un autre nœud
ainsi que les confirmations en provenance de tous les autres nœuds existants.
Un <quote>chemin</quote> doit exister pour
que le récepteur (le client) puisse se connecter au fournisseur (le serveur).</para>
<para>Chaque nœud du système doit écouter les événements
de tous les autres nœuds. En règle générale, un abonné
(voir <xref linkend="stmtsubscribeset"/>) doit écouter les événements
d'un ensemble origine sur un fournisseur unique, qui lui envoie
les données. En retour, l'origine de l'ensemble de réplication
doit écouter les événements dans la direction opposée.
Un nœud peut écouter simultanément les événements d'un même ensemble d'origine
en provenance de différents fournisseurs. Cependant, pour traiter les
événements <command>SYNC</command> de cet ensemble d'origine, tous les
fournisseurs de données doivent avoir un niveau de synchronisation égal
ou supérieur, afin d'éviter des comportements de réplication trop
rapide.
</para>
<variablelist>
<varlistentry><term><literal>ORIGIN = ival</literal></term>
<listitem><para>L'identifiant du nœud d'origine que le récepteur écoute.</para></listitem>
</varlistentry>
<varlistentry><term><literal>PROVIDER = ival</literal></term>
<listitem><para>L'identifiant du nœud qui envoie au récepteur les événements
produits par le nœud origine. Si cette valeur n'est pas spécifiée,
il s'agit du nœud origine.</para></listitem>
</varlistentry>
<varlistentry><term><literal>RECEIVER = ival</literal></term>
<listitem><para>L'identifiant du nœud recevant les événements.</para></listitem>
</varlistentry>
</variablelist>
<para>Cette commande utilise &funstorelisten;.</para>
<para>Pour plus de détails, consultez &rlistenpaths;.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title> <para>Cette commande fut introduite
dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmtdroplisten"><refmeta><refentrytitle>SLONIK DROP LISTEN</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>DROP LISTEN</refname>
<refpurpose>Élimine la configuration qui décrit comment un nœud
&slony1; écoute les événements
</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>DROP LISTEN (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Supprime une <quote>voie d'écoute</quote> de la configuration.</para>
<variablelist>
<varlistentry><term><literal>ORIGIN = ival</literal></term>
<listitem><para>Identifiant du nœud origine que le récepteur écoute.</para></listitem>
</varlistentry>
<varlistentry><term><literal>PROVIDER = ival</literal></term>
<listitem><para>Identifiant du nœud qui envoie au récepteur les événements
produits par l'origine. Si cette valeur n'est pas spécifiée, alors il
s'agit de l'origine.</para></listitem>
</varlistentry>
<varlistentry><term><literal>RECEIVER = ival</literal></term>
<listitem><para>L'identifiant du nœud qui reçoit les événements.</para></listitem>
</varlistentry>
</variablelist>
<para>Cette commande utilise &fundroplisten;.</para>
</refsect1>
<refsect1><title>Exemple</title>
<programlisting>
DROP LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
</programlisting>
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title> <para>Cette commande fut introduite
dans &slony1; 1.0. À partir de la version 1.1, vous ne <emphasis>devriez</emphasis>
pas avoir besoin de cette commande car les voies d'écoute sont générées automatiquement.
</para>
</refsect1>
</refentry>
<!-- **************************************** -->
<refentry id="stmttableaddkey"><refmeta><refentrytitle>SLONIK TABLE ADD KEY</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>TABLE ADD KEY</refname>
<refpurpose> Ajoute une clef primaire pour
&slony1; dans une table qui n'en possède pas
</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>TABLE ADD KEY (options);</command>