gistfile1.txt

zookeeper.ssl.keyStore.location="/path/to/your/keystore"
zookeeper.ssl.keyStore.password="keystore_password"
zookeeper.ssl.trustStore.location="/path/to/your/truststore"
zookeeper.ssl.trustStore.password="truststore_password"
zookeeper.client.secure=true

zookeeper.clientCnxnSocket="org.apache.zookeeper.ClientCnxnSocketNetty"
zookeeper.serverCnxnFactory="org.apache.zookeeper.server.NettyServerCnxnFactory"

secureClientPort=2281

An example setup for running bin/zkServer.sh:
environmental variable
export SERVER_JVMFLAGS="
-Dzookeeper.serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
-Dzookeeper.ssl.keyStore.location=/root/zookeeper/ssl/testKeyStore.jks 
-Dzookeeper.ssl.keyStore.password=testpass 
-Dzookeeper.ssl.trustStore.location=/root/zookeeper/ssl/testTrustStore.jks 
-Dzookeeper.ssl.trustStore.password=testpass" 

For bin/zkCli.sh: 
environmental variable
export CLIENT_JVMFLAGS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty 
-Dzookeeper.client.secure=true 
-Dzookeeper.ssl.keyStore.location=/root/zookeeper/ssl/testKeyStore.jks 
-Dzookeeper.ssl.keyStore.password=testpass 
-Dzookeeper.ssl.trustStore.location=/root/zookeeper/ssl/testTrustStore.jks 
-Dzookeeper.ssl.trustStore.password=testpass"

zookeeper.ssl.keyStore.location
zookeeper.ssl.keyStore.password
zookeeper.ssl.trustStore.location
zookeeper.ssl.trustStore.password


To create a deployment that can tolerate the failure of F machines, you should count on deploying 2xF+1 machines


    group.1=1:2:3
    group.2=4:5:6
    group.3=7:8:9
   
    weight.1=1
    weight.2=1
    weight.3=1
    weight.4=1
    weight.5=1
    weight.6=1
    weight.7=1
    weight.8=1
    weight.9=1
 	leaderServes
  electionAlg
maxSessionTimeout
traceFile

maxClientCnxns
clientPortAddressminSessionTimeout
globalOutstandingLimit

czxid
The zxid of the change that caused this znode to be created.
mzxid
The zxid of the change that last modified this znode.
ctime
The time in milliseconds from epoch when this znode was created.
mtime
The time in milliseconds from epoch when this znode was last modified.
version
The number of changes to the data of this znode.
cversion
The number of changes to the children of this znode.
aversion
The number of changes to the ACL of this znode.
ephemeralOwner
The session id of the owner of this znode if the znode is an ephemeral node. If it is not an ephemeral node, it will be zero.
dataLength
The length of the data field of this znode.
numChildren
The number of children of this znode.
      peerType=observer

      server.1:localhost:2181:3181:observer
      bin/zkCli.sh -server localhost:2181
Two example use cases for Observers are listed below. In fact, wherever you wish to scale the numbe of clients of your ZooKeeper ensemble, or where you wish to insulate the critical part of an ensemble from the load of dealing with client requests, Observers are a good architectural choice.

As a datacenter bridge: Forming a ZK ensemble between two datacenters is a problematic endeavour as the high variance in latency between the datacenters could lead to false positive failure detection and partitioning. However if the ensemble runs entirely in one datacenter, and the second datacenter runs only Observers, partitions aren't problematic as the ensemble remains connected. Clients of the Observers may still see and issue proposals.
As a link to a message bus: Some companies have expressed an interest in using ZK as a component of a persistent reliable message bus. Observers would give a natural integration point for this work: a plug-in mechanism could be used to attach the stream of proposals an Observer sees to a publish-subscribe system, again without loading the core ensemble.