forked from gleu/pgdocs_fr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtriggers.xml
217 lines (200 loc) · 11.1 KB
/
triggers.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
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="triggers">
<title>Gestion des triggers &slony1;</title>
<indexterm><primary>gestion des triggers</primary></indexterm>
<para>
&slony1; a connu deux <quote>types</quote> de gestion pour les
triggers
<itemizedlist>
<listitem>
<para>
Jusqu'à la version 1.2, &postgres; n'avait pas conscience de la
réplication, ce qui impliquait que &slony1; avait besoin que l'on
<quote>modifie directement</quote> le catalogue système afin de
désactiver, sur les nœuds abonnés, les triggers qui ne devaient
pas être exécutés.</para>
<para>Ceci provoquait un certain nombre d'effets secondaires pénibles,
tels que :
<itemizedlist>
<listitem>
<para>La corruption du catalogue système sur les nœuds abonnés car
les triggers existants, qui sont généralement placés en cache, sont <quote>modifiés
directement</quote> en changeant <envar>pg_catalog.pg_trigger</envar> pour qu'il
désigne les index utilisés par &slony1; comme <quote>clé primaire</quote>.</para>
<para>Ceci est également vrai pour les règles (« rules »).</para>
<para>L'effet secondaire était que
<application>pg_dump</application> ne pouvait pas être utilisé pour
récupérer proprement les schémas des nœuds abonnés.</para>
</listitem>
<listitem><para>Cela introduit la nécessité de poser des verrous exclusifs
sur <emphasis>toutes les tables répliquées</emphasis> lors de la commande
&rddlchanges; puisque les triggers de chaque table répliquée devaient être
supprimés et ajoutés à nouveau par cette opération.</para>
</listitem>
</itemizedlist>
</para></listitem>
<listitem>
<para>Avec &postgres; version 8.3, il y a de nouvelles fonctionnalités
qui permettent de modifier le comportement des triggers et des règles via
la commande <command>ALTER TABLE</command>, et de spécifier une des
options de triggers suivantes :
<itemizedlist>
<listitem><para><command>DISABLE TRIGGER nom_du_declencheur</command></para></listitem>
<listitem><para><command>ENABLE TRIGGER nom_du_declencheur</command></para></listitem>
<listitem><para><command>ENABLE REPLICA TRIGGER nom_du_declencheur</command></para></listitem>
<listitem><para><command>ENABLE ALWAYS TRIGGER nom_du_declencheur</command></para></listitem>
<listitem><para><command>DISABLE RULE nom_de_la_regle</command></para></listitem>
<listitem><para><command>ENABLE RULE nom_de_la_regle</command></para></listitem>
<listitem><para><command>ENABLE REPLICA RULE nom_de_la_regle</command></para></listitem>
<listitem><para><command>ENABLE ALWAYS RULE nom_de_la_regle</command></para></listitem>
</itemizedlist>
</para>
<para>Une nouvelle variable GUC, <envar>session_replication_role</envar>
contrôle si la session est en mode 'origin', 'replica' ou 'local', ce qui
combiné avec les options d'activation/désactivation permet de contrôler
si un trigger est effectivement exécuté.</para>
<para>On peut déterminer quand les triggers se déclenchent dans une réplication &slony1;
en utilisant la table suivante ; le même principe s'applique aux règles.</para>
<table id="triggerbehaviour">
<title>Comportement du trigger</title>
<tgroup cols="7">
<thead>
<row>
<entry>Type de trigger</entry>
<entry>Condition de déclenchement</entry>
<entry>Trigger de log</entry>
<entry>Trigger denyaccess</entry>
<entry>Action - origin</entry>
<entry>Action - replica</entry>
<entry>Action - local</entry>
</row>
</thead>
<tbody>
<row>
<entry>DISABLE TRIGGER</entry>
<entry>requête utilisateur</entry>
<entry>désactivé sur les nœuds abonnés</entry>
<entry>activé sur les nœuds abonnés</entry>
<entry>ne se déclenche pas</entry>
<entry>ne se déclenche pas</entry>
<entry>ne se déclenche pas</entry>
</row>
<row>
<entry>ENABLE TRIGGER</entry>
<entry>par défaut</entry>
<entry>activé sur les nœuds abonnés</entry>
<entry>désactivé sur les nœuds abonnés</entry>
<entry>se déclenche</entry>
<entry>ne se déclenche pas</entry>
<entry>se déclenche</entry>
</row>
<row>
<entry>ENABLE REPLICA TRIGGER</entry>
<entry>requête utilisateur</entry>
<entry>inapproprié</entry>
<entry>inapproprié</entry>
<entry>ne se déclenche pas</entry>
<entry>se déclenche</entry>
<entry>ne se déclenche pas</entry>
</row>
<row>
<entry>ENABLE ALWAYS TRIGGER</entry>
<entry>requête utilisateur</entry>
<entry>inapproprié</entry>
<entry>inapproprié</entry>
<entry>se déclenche</entry>
<entry>se déclenche</entry>
<entry>se déclenche</entry>
</row>
</tbody>
</tgroup>
</table>
<para>Il y a désormais plusieurs façons pour &slony1; d'interagir avec cela.
Précisons les cas intéressants :
<itemizedlist>
<listitem>
<para>Avant que la réplication ne soit en place,
<emphasis>chaque</emphasis> base de données démarre avec
le statut <quote>origin</quote> et, par défaut, tous les triggers sont du type
<command>ENABLE TRIGGER</command> afin qu'ils soient exécutés, comme
dans un système non répliqué.</para>
</listitem>
<listitem>
<para>Lorsqu'un abonnement &slony1; est mis en place,
sur le nœud d'origine, les triggers <function>logtrigger</function>
et <function>denyaccess</function> sont ajoutés, le premier est activé
et exécuté, le second est désactivé.</para>
<para>Au niveau des verrous, chaque instruction <xref
linkend="stmtsetaddtable"/> demande brièvement un verrou
exclusif sur les table où sont attachés les triggers, ce qui a
toujours été le cas avec &slony1;.</para>
</listitem>
<listitem>
<para>Sur le nœud abonné, le processus d'abonnement ajoutera
les même triggers, mais avec une polarité <quote>inversée</quote>
pour protéger les données d'une corruption accidentelle.</para>
<para>Au niveau des verrous, encore une fois, cela fait peu de différences
avec l'ancien comportement car le processus d'abonnement, qui utilise
<command>TRUNCATE</command> copie les données et altère le schéma des tables,
nécessite de <emphasis>nombreux</emphasis> verrous exclusifs sur les tables,
et les changements dans le comportement des triggers ne modifie pas ce besoin.</para>
<para>Toutefois, notez que la capacité d'activer ou désactiver les triggers
d'une manière supportée par &postgres; signifie qu'il n'est pas nécessaire
de <quote>corrompre</quote> le catalogue système, ainsi nous avons l'avantage
considérable de pouvoir utiliser <application>pg_dump</application> pour
obtenir une sauvegarde complète et cohérente sur n'importe quel nœud du
cluster &slony1;.</para>
</listitem>
<listitem>
<para>Si vous restaurez une sauvegarde d'un n&orlig;ud Slony-I
(réalisé avec pg_dump ou toute autre méthode) et que vous
supprimez le namespace &slony1;, cela supprime proprement tous
les composants Slony-I et laisse la base de données, y compris
son schéma, dans un état cohérent et <quote>vierge</quote>,
prêt pour n'importe quelle utilisation.</para>
</listitem>
<listitem>
<para>L'opération &rddlchanges; est désormais réalisée d'une façon
toute à fait différente : plutôt que d'altérer chaque table répliquée pour
la <quote>retirer du mode répliqué</quote>, &slony1; glissera simplement
en statut <command>local</command> le temps de l'opération. </para>
<para>Sur le nœud origine, cela désactive le trigger
<function>logtrigger</function>.</para>
<para>Sur chaque nœud abonné, cela désactive le trigger
<function>denyaccess</function>.</para>
<para>Ceci devrait rendre les modifications DDL
<emphasis>énormément</emphasis> moins coûteuses car, plutôt que de poser des verrous
exclusifs sur <emphasis>toutes</emphasis> les tables répliquées (nécessaire pour les
opérations de suppression et re-création des triggers &slony1;), seules les tables impactées
par le script DDL sont verrouillées.</para>
</listitem>
<listitem>
<para>Au moment d'invoquer <xref linkend="stmtmoveset"/> sur l'ancien
nœud origine, &slony1; doit transformer ce nœud en nœud abonné, ce qui nécessite
de supprimer les triggers <function>lockset</function>, de désactiver les triggers
<function>logtrigger</function> et d'activer les triggers <function>denyaccess</function>.
</para>
<para>Au même moment, en réalisant <xref linkend="stmtmoveset"/> sur le
nouveau nœud origine, &slony1; doit transformer ce nœud en origine, ce qui
implique la désactivation des triggers <function>denyaccess</function>,
et d'activer les triggers <function>logtrigger</function>.</para>
<para>Au niveau des verrous, ceci ne change pas par rapport aux nouvelles versions
de &slony1; car le verrouillage effectué ici est tout à fait nécessaire.</para>
</listitem>
<listitem>
<para>
De le même manière que <xref linkend="stmtmoveset"/>, <xref linkend="stmtfailover"/> transforme un nœud abonné en nœud origine, ce qui
nécessite de désactiver les triggers <function>denyaccess</function>, et
d'activer les triggers <function>logtrigger</function>. Encore une fois,
l'implémentation des verrous est quasiment identique.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>
</sect1>