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
|
The events/ directory contains event scripts used by CTDB. Event
scripts are triggered on certain events, such as startup, monitoring
or public IP allocation. Scripts may be specific to services,
networking or internal CTDB operations.
Scripts are divided into subdirectories for different CTDB components.
Right now the only component is "legacy".
All event scripts start with the prefix 'NN.' where N is a digit. The
event scripts are run in sequence based on NN. Thus 10.interface will
be run before 60.nfs. It is recommended to keep each NN unique.
However, scripts with the same NN prefix will be executed in
alphanumeric sort order.
As a special case, any eventscript that ends with a '~' character will be
ignored since this is a common postfix that some editors will append to
older versions of a file. Similarly, any eventscript with multiple '.'s
will be ignored as package managers can create copies with additional
suffix starting with '.' (e.g. .rpmnew, .dpkg-dist).
Only executable event scripts are run by CTDB. Any event script that
does not have execute permission is ignored.
The eventscripts are called with varying number of arguments. The
first argument is the event name and the rest of the arguments depend
on the event name.
Event scripts must return 0 for success and non-zero for failure.
Output of event scripts is logged. On failure the output of the
failing event script is included in the output of "ctdb scriptstatus".
The following events are supported (with arguments shown):
init
This event is triggered once when CTDB is starting up. This
event is used to do some basic cleanup and initialisation.
During the "init" event CTDB is not listening on its Unix
domain socket, so the "ctdb" CLI will not work.
Failure of this event will cause CTDB to terminate.
Example: 00.ctdb creates $CTDB_SCRIPT_VARDIR
setup
This event is triggered once, after the "init" event has
completed.
For this and any subsequent events the CTDB Unix domain socket
is available, so the "ctdb" CLI will work.
Failure of this event will cause CTDB to terminate.
Example: 11.natgw checks that it has valid configuration
startup
This event is triggered after the "setup" event has completed
and CTDB has finished its initial database recovery.
This event starts all services that are managed by CTDB. Each
service that is managed by CTDB should implement this event
and use it to (re)start the service.
If the "startup" event fails then CTDB will retry it until it
succeeds. There is no limit on the number of retries.
Example: 50.samba uses this event to start the Samba daemon.
shutdown
This event is triggered when CTDB is shutting down.
This event shuts down all services that are managed by CTDB.
Each service that is managed by CTDB should implement this
event and use it to stop the service.
Example: 50.samba uses this event to shut down the Samba
daemon.
monitor
This event is run periodically. The interval between
successive "monitor" events is configured using the
MonitorInterval tunable, which defaults to 15 seconds.
This event is triggered by CTDB to continuously monitor that
all managed services are healthy. If all event scripts
complete then the monitor event successfully then the node is
marked HEALTHY. If any event script fails then no subsequent
scripts will be run for that event and the node is marked
UNHEALTHY.
Each service that is managed by CTDB should implement this
event and use it to monitor the service.
Example: 10.interface checks that each configured interface
for public IP addresses has a physical link established.
startrecovery
This event is triggered every time a database recovery process
is started.
This is rarely used.
recovered
This event is triggered every time a database recovery process
is completed.
This is rarely used.
takeip <interface> <ip-address> <netmask-bits>
This event is triggered for each public IP address taken by a
node during IP address (re)assignment. Multiple "takeip"
events can be run in parallel if multiple IP addresses are
being assigned.
Example: In 10.interface the "ip" command (from the Linux
iproute2 package) is used to add the specified public IP
address to the specified interface. The "ip" command can
safely be run concurrently. However, the "iptables" command
cannot be run concurrently so a wrapper is used to serialise
runs using exclusive locking.
If substantial work is required to reconfigure a service when
a public IP address is taken over it can be better to defer
service reconfiguration to the "ipreallocated" event, after
all IP addresses have been assigned.
Example: 60.nfs uses ctdb_service_set_reconfigure() to flag
that public IP addresses have changed so that service
reconfiguration will occur in the "ipreallocated" event.
releaseip <interface> <ip-address> <netmask-bits>
This event is triggered for each public IP address released by
a node during IP address (re)assignment. Multiple "releaseip"
events can be run in parallel if multiple IP addresses are
being unassigned.
In all other regards, this event is analogous to the "takeip"
event above.
updateip <old-interface> <new-interface> <ip-address> <netmask-bits>
This event is triggered for each public IP address moved
between interfaces on a node during IP address (re)assignment.
Multiple "updateip" events can be run in parallel if multiple
IP addresses are being moved.
This event is only used if multiple interfaces are capable of
hosting an IP address, as specified in the public addresses
configuration file.
This event is similar to the "takeip" event above.
ipreallocated
This event is triggered on all nodes as the last step of
public IP address (re)assignment. It is unconditionally
triggered after any "releaseip", "takeip" and "updateip"
events, even though these events may not run on some nodes if
there are no relevant changes. That is, the "ipreallocated"
event is triggered unconditionally, even on nodes where public
IP addresses assignments have not changed.
This event is used to reconfigure services.
Since "ipreallocated" is always run, this allows
reconfiguration to depend on the states of other nodes rather
that just IP addresses.
Example: 11.natgw recalculates the NAT gateway master and
updates the relevant network configuration on each node if the
NAT gateway master has changed.
Additional notes for "takeip", "releaseip", "updateip",
"ipreallocated":
* Failure of any of these events causes IP allocation to be retried.
* An event script can use ctdb_service_set_reconfigure() in "takeip",
"releaseip" or "updateip" events to flag that its service needs to
be reconfigured. The "ipreallocated" event can then use
ctdb_service_needs_reconfigure() to test if there were public IPs
changes to determine what type of reconfiguration (if any) is
needed.
|
