CMAP_KEYS(8) Corosync Cluster Engine Programmer's Manual CMAP_KEYS(8)NAMEcmap_keys - Overview of keys stored in the Configuration Map
OVERVIEW
There are roughly 3 types of keys stored in CMAP:
* Mapping of values stored in config file.
* Runtime statistics.
* Other user created values.
In this man page, wild-cards are used with usual meaning.
KEYS
internal_configuration.*
Internal configuration data. This keys (whole prefix) is read
only. It's only useful for getting list of loaded services.
logging.*
Values read from configuration file. It's possible to change
them at runtime. If subsystem specific configuration is needed,
key must be in form logging.logger_subsys.SERVICE.key, where
SERVICE is upper case name of service and key is same as in con‐
figuration file. All values are of string type.
nodelist.*
Values read from configuration file. Each node element in con‐
figuration file gets assigned it's position starting from zero.
So first node from config file has nodelist.node.0. prefix. To
be valid entry, each node must have ring0_addr key. For change
of nodeid key, use u32 data type.
Local node position is stored in local_node_pos key (RO), so
it's easy to find out nodeid/ring addresses of local node
directly from cmap.
runtime.blackbox.*
Trigger keys for store fplay data. It's recommended to use
corosync-blackbox command to change keys in this prefix.
runtime.connections.*
There are informations about total number of active connections
in given moment in active key, number of closed connections dur‐
ing whole runtime of corosync in closed key and informations
about each active IPC connection. All keys in this prefix are
read-only.
runtime.connections.ID.*
Each IPC connection has unique ID. This is in form
[[short_name:][PID:]internal_id. On some platforms, short_name
and PID are not filled and only internal_id is used.
Typical keys in prefix are:
client_pid containing PID of IPC connection (unavailable on some
platforms).
dispatched with number of dispatched messages.
invalid_request is number of requests made by IPC which are
invalid (calling non-existing call, ...).
name containing short name of IPC connection (unavailable on
some platforms).
overload is number of requests which were not processed because
of overload.
queue_size contains number of messages in queue waiting for
send.
recv_retries is total number of interrupted receives.
requests contains number of requests made by IPC.
responses is number of responses sent to IPC client.
send_retries contains total number of interrupted sends.
service_id contains ID of service which IPC is connected to.
runtime.services.*
Prefix with statistics for service engines. Each service has
it's own service_id key in prefix with name runtime.ser‐
vices.SERVICE., where SERVICE is lower case name of service.
Inside service prefix is number of received and send messages by
corosync engine in format runtime.services.SERVICE.EXEC_CALL.rx
and runtime.services.SERVICE.EXEC_CALL.tx, where EXEC_CALL is
internal id of service call (so for example 3 in cpg service is
receive of multicast message from other nodes).
runtime.totem.pg.mrp.srp.*
Prefix with statistics about totem. All keys there are read
only. Typical key prefixes:
commit_entered Number of times processor entered COMMIT state.
commit_token_lost Number of times processor lost token in COMMIT
state.
consensus_timeouts How many times processor timeouted making
consensus about membership.
continuous_gather How many times was processor not able to reach
consensus.
firewall_enabled_or_nic_failure Set to 1 when processor was not
able to reach consensus for long time. Usual reason is badly
configured firewall or connection failure.
gather_entered Number of times processor entered GATHER state.
gather_token_lost Number of times processor lost token in GATHER
state.
mcast_retx Number of retransmitted messages.
mcast_rx Number of received multicast messages.
mcast_tx Number of transmitted multicast messages.
memb_commit_token_rx Number of received commit tokens.
memb_commit_token_tx Number of transmitted commit tokens.
memb_join_rx Number of received join messages.
memb_join_tx Number of transmitted join messages.
memb_merge_detect_rx Number of received member merge messages.
memb_merge_detect_tx Number of transmitted member merge mes‐
sages.
orf_token_rx Number of received orf tokens.
orf_token_tx Number of transmitted orf tokens.
recovery_entered Number of times processor entered recovery.
recovery_token_lost Number of times token was lost in recovery
state.
rx_msg_dropped Number of received messages which was dropped
because they were not expected (as example multicast message in
commit state).
token_hold_cancel_rx Number of received token hold cancel mes‐
sages.
token_hold_cancel_tx Number of transmitted token hold cancel
messages.
mtt_rx_token Mean transit time of token in milliseconds. In
other words, time between two consecutive token receives.
avg_token_workload Average time in milliseconds of holding time
of token on current processor.
avg_backlog_calc Average number of not yet sent messages of cur‐
rent processor.
runtime.totem.pg.mrp.srp.members.*
Prefix containing members of totem single ring protocol. Each
member keys has format runtime.totem.pg.mrp.srp.mem‐
bers.NODEID.KEY, where key is one of:
ip IP address of member. It's stored in format r(RING_ID)ip(IP_ADDRESS).
join_count Number of times processor joined membership with
local processor. When processor fails and rejoins again, this
value is incremented.
status Status of processor. Can be one of joined and left.
config_version Config version of member node.
resources.process.PID.*
Prefix created by applications using SAM with CMAP integration.
It contains following keys:
recovery Recovery policy of process. Can be one of quit or
restart.
poll_period Value passed in sam_initialize as time_interval.
last_updated Last time when SAM received heartbeat from client.
state State of client. Can be one of failed, stopped, running
and waiting for quorum.
uidgid.*
Informations about users/groups which are allowed to do IPC con‐
nection to corosync.
config.reload_in_progress
This value will be set to 1 (or created) when corosync.conf
reload is started, and set to 0 when the reload is completed.
This allows interested subsystems to do atomic reconfiguration
rather than changing each key. Note that individual
add/change/delete notifications will still be sent during a
reload.
DYNAMIC CHANGE USER/GROUP PERMISSION TO USE COROSYNC IPC
Is very same as in configuration file. To add UID 500 use
# corosync-cmapctl -s uidgid.uid.500 u8 1
GID is similar, so to add GID use
# corosync-cmapctl -s uidgid.gid.500 u8 1
For removal of permission, simply delete key
# corosync-cmapctl -d uidgid.gid.500
DYNAMIC ADD/REMOVE OF UDPU NODE
We will need to add node with address 10.34.38.108 and nodeid 3. This
node is called NEW and it's not running corosync yet.
* Find a node position in node list which is not used yet. It's recom‐
mended to use highest_number + 1. Let's say output of corosync-cmapctl
looks like:
nodelist.local_node_pos (u32) = 1
nodelist.node.0.nodeid (u32) = 1
nodelist.node.0.ring0_addr (str) = 10.34.38.106
nodelist.node.1.nodeid (u32) = 2
nodelist.node.1.ring0_addr (str) = 10.34.38.107
So next node position will be 2.
* Add all entries needed for node on all running nodes, as:
# corosync-cmapctl -s nodelist.node.2.nodeid u32 3
# corosync-cmapctl -s nodelist.node.2.ring0_addr str 10.34.38.108
Always add ring0_addr key as last. Corosync engine on all nodes should
reply with notice [TOTEM ] adding new UDPU member {10.34.38.108} mes‐
sage.
* Add node information to configuration file on all nodes so it will
survive restart of corosync.
* Copy and edit configuration file to NEW node.
* Start corosync on NEW node.
Removal of UDPU node is very similar slightly reversed action, so
* Stop corosync old OLD node.
* Remove relevant entries from cmap on all nodes.
* Change configuration file on all nodes.
SEE ALSOcorosync_overview(8), corosync.conf(5), corosync-cmapctl(8)corosync Man Page 10/10/2012 CMAP_KEYS(8)
