1CMAP_KEYS(8) Corosync Cluster Engine Programmer's Manual CMAP_KEYS(8)
2
6 cmap_keys - Overview of keys stored in the Configuration Map
7
10 There are 3 main types of keys stored in CMAP:
11 * Mapping of values stored in the config file.
13 * Runtime statistics.
15 * Other user created values.
17 In this man page, wild-cards have the usual meaning.
19
22 internal_configuration.*
23 Internal configuration data. All keys in this prefix are read
24 only. It's only useful for getting a list of loaded services.
25 logging.*
28 Values read from the configuration file. It's possible to change
29 them at runtime. If subsystem specific configuration is needed,
30 the key must be in the form logging.logger_subsys.SERVICE.key,
31 where SERVICE is upper case name of the service and key is same
32 as in the configuration file. All values are of string type.
33 nodelist.*
36 Values read from the configuration file. Each node element in
37 the configuration file gets assigned it's position starting from
38 zero. So the first node from the config file has
39 nodelist.node.0. prefix. To be a valid entry, each node must
40 have ring0_addr key. To change the nodeid key, use a u32 data
41 type.
42 Local node position is stored in local_node_pos key (RO), so
44 it's easy to find out nodeid/ring addresses of the local node
45 directly from cmap.
46 runtime.blackbox.*
49 Trigger keys for storing fplay data. It's recommended that you
50 the corosync-blackbox command to change keys in this prefix.
51 runtime.connections.*
54 There is information about total number of active connections in
55 given moment in the active key, number of closed connections
56 during whole runtime of corosync in the closed key and informa‐
57 tion about each active IPC connection. All keys in this prefix
58 are read-only.
59 runtime.connections.ID.*
62 Each IPC connection has a unique ID. This is in the form
63 [[short_name:][PID:]internal_id. On some platforms, short_name
64 and PID are not filled and only internal_id is used.
65 Typical keys in this prefix are:
67 client_pid containing PID of IPC connection (unavailable on some
69 platforms).
70 dispatched number of dispatched messages.
72 invalid_request number of requests made by IPC which are invalid
74 (calling non-existing call, ...).
75 name contains short name of the IPC connection (unavailable on
77 some platforms).
78 overload is number of requests which were not processed because
80 of overload.
81 queue_size contains the number of messages in the queue waiting
83 for send.
84 recv_retries is the total number of interrupted receives.
86 requests contains the number of requests made by IPC.
88 responses is the number of responses sent to the IPC client.
90 send_retries contains the total number of interrupted sends.
92 service_id contains the ID of service which the IPC is connected
94 to.
95 runtime.config.*
98 Contains the values actually in use by the totem membership pro‐
99 tocol. Values here are either taken from the Corosync configu‐
100 ration file, defaults or computed from entries in the config
101 file. For information on individual keys please refer to the man
102 page corosync.conf(5).
103 runtime.services.*
106 Prefix with statistics for service engines. Each service has
107 it's own service_id key in the prefix with the name runtime.ser‐
108 vices.SERVICE., where SERVICE is the lower case name of the ser‐
109 vice. Inside the service prefix is the number of messages
110 received and sent by the corosync engine in the format run‐
111 time.services.SERVICE.EXEC_CALL.rx and runtime.services.SER‐
112 VICE.EXEC_CALL.tx, where EXEC_CALL is the internal id of the
113 service call (so for example 3 in cpg service is receive of mul‐
114 ticast message from other nodes).
115 runtime.totem.pg.mrp.srp.*
118 Prefix containing statistics about totem. All keys here are read
119 only. Typical key prefixes:
120 commit_entered Number of times the processor entered COMMIT
122 state.
123 commit_token_lost Number of times the processor lost token in
125 COMMIT state.
126 consensus_timeouts How many times the processor timed out form‐
128 ing a consensus about membership.
129 continuous_gather How many times the processor was not able to
131 reach consensus.
132 firewall_enabled_or_nic_failure Set to 1 when processor was not
134 able to reach consensus for long time. The usual reason is a
135 badly configured firewall or connection failure.
136 gather_entered Number of times the processor entered GATHER
138 state.
139 gather_token_lost Number of times the processor lost token in
141 GATHER state.
142 mcast_retx Number of retransmitted messages.
144 mcast_rx Number of received multicast messages.
146 mcast_tx Number of transmitted multicast messages.
148 memb_commit_token_rx Number of received commit tokens.
150 memb_commit_token_tx Number of transmitted commit tokens.
152 memb_join_rx Number of received join messages.
154 memb_join_tx Number of transmitted join messages.
156 memb_merge_detect_rx Number of received member merge messages.
158 memb_merge_detect_tx Number of transmitted member merge mes‐
160 sages.
161 orf_token_rx Number of received orf tokens.
163 orf_token_tx Number of transmitted orf tokens.
165 recovery_entered Number of times the processor entered recovery.
167 recovery_token_lost Number of times the token was lost in recov‐
169 ery state.
170 rx_msg_dropped Number of received messages which were dropped
172 because they were not expected (as example multicast message in
173 commit state).
174 token_hold_cancel_rx Number of received token hold cancel mes‐
176 sages.
177 token_hold_cancel_tx Number of transmitted token hold cancel
179 messages.
180 mtt_rx_token Mean transit time of token in milliseconds. In
182 other words, time between two consecutive token receives.
183 avg_token_workload Average time in milliseconds of holding time
185 of token on the current processor.
186 avg_backlog_calc Average number of not yet sent messages on the
188 current processor.
189 runtime.totem.pg.mrp.srp.members.*
192 Prefix containing members of the totem single ring protocol.
193 Each member keys has format runtime.totem.pg.mrp.srp.mem‐
194 bers.NODEID.KEY, where key is one of:
195 ip IP address of member. It's stored in format r(RING_ID)
197 ip(IP_ADDRESS).
198 join_count Number of times the processor joined membership with
200 local cluster. When processor fails and rejoins again, this
201 value is incremented.
202 status Status of the processor. Can be one of joined and left.
204 config_version Config version of the member node.
206 resources.process.PID.*
209 Prefix created by applications using SAM with CMAP integration.
210 It contains the following keys:
211 recovery Recovery policy of the process. Can be one of quit or
213 restart.
214 poll_period Value passed in sam_initialize as a time_interval.
216 last_updated Last time SAM received a heartbeat from the client.
218 state State of the client. Can be one of failed, stopped, run‐
220 ning and waiting for quorum.
221 uidgid.*
224 Information about users/groups which are allowed to make IPC
225 connections to corosync. Entries loaded from configuration file
226 are stored with uidgid.config.* prefix and are pruned on config‐
227 uration file reload. Dynamic entries has uidgid.* prefix and a
228 configuration file reload doesn't affect them.
229 quorum.cancel_wait_for_all
232 Tells votequorum to cancel waiting for all nodes at cluster
233 startup. Can be used to unblock quorum if notes are known to be
234 down. For pcs use only.
235 config.reload_in_progress
238 This value will be set to 1 (or created) when a corosync.conf
239 reload is started, and set to 0 when the reload is completed.
240 This allows interested subsystems to do atomic reconfiguration
241 rather than changing each key. Note that individual
242 add/change/delete notifications will still be sent during a
243 reload.
244 config.totemconfig_reload_in_progress
247 This key is similar to config.totemconfig_reload_in_progress but
248 changed after the totem config trigger is processed. It is use‐
249 ful (mainly) for situations when nodelist.local_node_pos must be
250 correctly reinstated before anything else.
251
254 Is the same as in the configuration file. eg: to add UID 500 use
255 # corosync-cmapctl -s uidgid.uid.500 u8 1
257 GID is similar, so to add a GID use
259 # corosync-cmapctl -s uidgid.gid.500 u8 1
261 For removal of permissions, simply delete the key
263 # corosync-cmapctl -d uidgid.gid.500
265
268 Eg. To add the node with address 10.34.38.108 and nodeid 3. This node
269 is called NEW and it's not running corosync yet.
270 * Find a node position in the node list which is not used yet. It's
273 recommended that you use highest_number + 1. Let's say output of
274 corosync-cmapctl looks like:
275 nodelist.local_node_pos (u32) = 1
277 nodelist.node.0.nodeid (u32) = 1
278 nodelist.node.0.ring0_addr (str) = 10.34.38.106
279 nodelist.node.1.nodeid (u32) = 2
280 nodelist.node.1.ring0_addr (str) = 10.34.38.107
281 So next node position will be 2.
283 * Add all entries needed for the node on all running nodes, as:
285 # corosync-cmapctl -s nodelist.node.2.nodeid u32 3
287 # corosync-cmapctl -s nodelist.node.2.ring0_addr str 10.34.38.108
288 Always add the ring0_addr key last. The Corosync engine on all nodes
290 should reply with notice [TOTEM ] adding new UDPU member {10.34.38.108}
291 message.
292 * Add node information to the configuration file on all nodes so that
294 it will survive a restart of corosync.
295 * Copy and edit configuration file to the NEW node.
297 * Start corosync on the NEW node.
299 Removal of a UDPU node is a very similar, slightly reversed action, so
301 * Stop corosync on the OLD node.
303 * Remove the relevant entries from cmap on all nodes.
305 * Change the configuration file on all nodes.
307
310 corosync_overview(8), corosync.conf(5), corosync-cmapctl(8)
311corosync Man Page 10/10/2012 CMAP_KEYS(8)