cmap_keys man page on Oracle

Man page or keyword search:  
man Server   33470 pages
apropos Keyword Search (all sections)
Output format
Oracle logo
[printable version]

CMAP_KEYS(8)	  Corosync Cluster Engine Programmer's Manual	  CMAP_KEYS(8)

       cmap_keys - Overview of keys stored in the Configuration Map

       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.

	      Internal	configuration  data.  This keys (whole prefix) is read
	      only.  It's only useful for getting list of loaded services.

	      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.

	      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.

	      Trigger keys for store  fplay  data.  It's  recommended  to  use
	      corosync-blackbox command to change keys in this prefix.

	      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

	      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

	      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

	      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.*
	      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
	      and,  where  EXEC_CALL is
	      internal id of service call (so for example 3 in cpg service  is
	      receive of multicast message from other nodes).*
	      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

	      consensus_timeouts  How  many  times  processor timeouted making
	      consensus about membership.

	      continuous_gather How many times was processor not able to reach

	      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

	      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‐

	      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

	      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‐

	      token_hold_cancel_tx  Number  of	transmitted  token hold cancel

	      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.*
	      Prefix  containing  members  of totem single ring protocol. Each
	      member	keys	has    format‐
	      bers.NODEID.KEY, where key is one of:

	      ip  IP  address  of  member.  It's  stored  in format r(RING_ID)

	      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.

	      Prefix created by applications using SAM with CMAP  integration.
	      It contains following keys:

	      recovery	Recovery  policy  of  process.	Can  be one of quit or

	      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.

	      Informations about users/groups which are allowed to do IPC con‐
	      nection to corosync.

	      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

       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

       We  will	 need to add node with address 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) =
       nodelist.node.1.nodeid (u32) = 2
       nodelist.node.1.ring0_addr (str) =

       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

       Always add ring0_addr key as last. Corosync engine on all nodes	should
       reply  with  notice [TOTEM ] adding new UDPU member {} mes‐

       * 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.

       corosync_overview(8), corosync.conf(5), corosync-cmapctl(8)

corosync Man Page		  10/10/2012			  CMAP_KEYS(8)

List of man pages available for Oracle

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net