The maprcli dump zkinfo command enables you to view a snapshot of the data stored in Zookeeper as a result of cluster operations. For best results, use the -json option when running dump zkinfo from the command line.

ZooKeeper prevents service coordination conflicts by enforcing a rigid set of rules and conditions, provides cluster-wide information about running services and their configuration, and provides a mechanism for almost instantaneous service failover. Warden will not start any services unless ZooKeeper is reachable and more than half of the configured ZooKeeper nodes are live.

The script calls the maprcli dump supportdump command to gather cluster diagnostics for troubleshooting. For more information, see


maprcli dump zkinfo
    [-cluster <cluster name>]
    [-zkconnect <connect string>]




-cluster <cluster name>

The cluster on which to run the command. If this parameter is omitted, the command is run on the same cluster where it is issued. In multi-cluster contexts, you can use this parameter to specify a different cluster on which to run the command.

-zkconnect <connection string>

A ZooKeeper connect string, which specifies a list of the hosts running ZooKeeper, and the port to use on each, in the format: '<host>[:<port>][,<host>[:<port>]...]'. To obtain zookeeper connection strings, use the maprcli node listzookeepers command.


The maprcli dump zkinfo command is run as part of support dump tools to view the current state of the Zookeeper service. The command should always be run using the -json option, since output in the default tabular format is not useful. Command output displays the data stored in the ZooKeeper hierarchical tree of znodes.

# maprcli dump zkinfo -json
		"/_Stats":"\ncZxid = 0,ctime = Wed Dec 31 16:00:00 PST 1969,mZxid = 0,mtime = Wed Dec 31 16:00:00 PST 1969,pZxid = 516,cversion = 12,dataVersion = 0,aclVersion = 0,ephemeralOwner = 0,dataLength = 0,numChildren = 13",

Output fields

You can use the maprcli dump zkinfo command as you would use a database snapshot. The /services, /services_config, /servers, and /*_locks znodes are used by Warden to store and exchange information.




The /services directory is used by Warden to store and exchange information about services.


The /datacenter directory contains CLDB "vital signs" that you can use to identify the CLDB master, the most recent epoch, and other key data. For more information, see Moving CLDB Data below.


The /services_config directory is used by Warden to store and exchange information.


The /zookeeper directory stores information about the ZooKeeper service.


The /servers directory is used by Warden to store and exchange information.


The /nodes directory (znode) stores key information about the nodes.


Moving CLDB Data

In a Community Edition-licensed cluster, CLDB data must be recovered from a failed CLDB node and installed on another node. The cluster can continue normally as soon as the CLDB is started on another node. For more information, see Recovering from a Failed CLDB Node on a Community Edition Cluster.

Use the maprcli dump zkinfo command to identify the latest epoch of the CLDB, identify the nodes where replicates of the CLDB are stored, and select one of those nodes to serve the new CLDB node. Perform the following steps on any cluster node:

  1. Log in as root or use sudo for the following commands.
  2. Issue the maprcli dump zkinfo command using the -json flag.

    # maprcli dump zkinfo -json

    The output displays the ZooKeeper znodes.

  3. In the /datacenter/controlnodes/cldb/epoch/1 directory, locate the CLDB with the latest epoch.

        "/datacenter/controlnodes/cldb/epoch/1/KvStoreContainerInfo":" Container ID:1
        VolumeId:1 Master: Servers: Inactive Servers: Unused Servers:
        Latest epoch:13"

    The Latest Epoch field identifies the current epoch of the CLDB data. In this example, the latest epoch is 13.

  4. Select a CLDB from among the copies at the latest epoch. For example, indicates that the node has a copy at epoch 13 (the latest epoch).