Zookeeper can be installed in multiple ways, and zookeeper can be installed in multiple ways.
System: Centos6.5 x64
1. Installation in standalone Mode
Ii. Installation in pseudo cluster mode
Iii. cluster mode installation
1. Install zookeeper in standalone Mode
1.1 create an account zk
12 |
[root@master ~] # useradd -d /opt/zk zk [root@master ~] # echo "zk" |passwd --stdin zk |
1.2 download, decompress,
123456 |
[root@master ~] # su - zk [zk@master ~]$ pwd /opt/zk [zk@master ~]$ wget [zk@master ~]$ tar zxvf zookeeper-3.5.0-alpha. tar .gz [zk@master ~]$ mv zookeeper-3.5.0-alpha zk |
1.3 configure the current user environment variable
123 |
export ZOOKEEPER_HOME= /opt/zk/zk PATH=$ZOOKEEPER_HOME /bin :$PATH export PATH |
1.4 configure the configuration file zoo. cfg
1234567 |
[zk@master conf]$ cat zoo.cfg initLimit=10 syncLimit=5 clientPort=2181 tickTime=2000 dataDir= /opt/zk/zk/data dataLogDir= /opt/zk/zk/logs |
1.5 start zk
123 |
[zk@master bin]$ pwd /opt/zk/zk/bin [zk@master bin]$ . /zkServer .sh start |
1.6 client link test:
1234567891011121314151617181920 |
[zk@master bin]$ pwd /opt/zk/zk/bin [zk@master bin]$ . /zkCli .sh -server localhost:2181 Connecting to localhost:2181 。。。 [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] [zk: localhost:2181(CONNECTED) 1] create /Test hellozk Created /Test [zk: localhost:2181(CONNECTED) 2] get /Test hellozk [zk: localhost:2181(CONNECTED) 3] set /Test hellozookeeper [zk: localhost:2181(CONNECTED) 4] get /Test hellozookeeper [zk: localhost:2181(CONNECTED) 5] delete /Test [zk: localhost:2181(CONNECTED) 6] get /Test Node does not exist: /Test [zk: localhost:2181(CONNECTED) 7] quit 2014-11-19 03:53:50,180 [myid:] - INFO [main:ZooKeeper@968] - Session: 0x149c475d7db0000 closed 2014-11-19 03:53:50,182 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down |
Description of the zookeeper configuration file:
12345678910111213141516171819202122232425 |
clientPort # The port on which the client connects to the server, that is, the external service port, which is generally set to 2181. dataDir # The snapshot file snapshot directory. Transaction logs are stored here by default. We recommend that you configure the dataLogDir parameter at the same time. The Write Performance of transaction logs directly affects zk performance. tickTime # A time unit in ZK. All time in ZK is configured as an integer multiple based on this time unit. For example, the minimum timeout value of a session is 2 * tickTime. dataLogDir # Transaction log output directory. Configure a separate disk or mount point for the output of transaction logs as much as possible, which will greatly improve ZK performance. globalOutstandingLimit # Maximum number of requests accumulated. The default value is 1000. When ZK is running, although the server is no longer idle to process more client requests, it still allows the client to submit requests to the server to improve throughput performance. Of course, in order to prevent Server memory overflow, this number of requests must be limited. Java system property: zookeeper. globalOutstandingLimit. preAllocSize # Pre-opened disk space for subsequent transaction log writing. The default value is 64 MB, and the size of each transaction log is 64 MB. If the snapshot frequency of ZK is large, we recommend that you reduce this parameter. snapCount # After each snapCount transaction log output, a snapshot is triggered. At this time, ZK generates a snapshot. * file and creates a new transaction log file log .*. The default value is 100000. (In real code implementation, random number processing is performed to prevent all servers from performing snapshots at the same time and affecting performance ). traceFile # Logs used to record all requests, which can be used during debugging, but are not recommended in the production environment, which seriously affects performance. maxClientCnxns # The number of connections between a single client and a single server is at the ip address level. The default value is 60. If it is set to 0, no restrictions are imposed. Note that this restriction only applies to the number of connections between a single client machine and a single ZK server. It does not apply to the specified Client IP address or the number of connections of a ZK cluster, it is not the limit on the number of connections of all clients for a single ZK. clientPortAddress # For machines with multiple NICs, you can specify different listening ports for each IP address. By default, all IP addresses listen to the port specified by clientPort. minSessionTimeoutmaxSessionTimeout # Session Timeout time limit. If the timeout time set by the client is not in this range, it is forcibly set to the maximum or minimum time. The default Session timeout value is 2 * tickTime ~ 20 * tickTime. fsync.warningthresholdms # When the transaction log is output, if the fsync method is called beyond the specified Timeout time, the warning information is output in the log. The default value is 1000 ms. autopurge.purgeInterval # In versions 3.4.0 and later, ZK provides the function of automatically clearing transaction logs and snapshot files. This parameter specifies the cleaning frequency, in hours, and requires a 1 or greater integer, the default value is 0, and automatic cleaning is disabled for tables. autopurge.snapRetainCount # This parameter is used with the preceding parameter. This parameter specifies the number of files to be retained. By default, three are retained. electionAlg # In earlier versions, this parameter configuration allows us to select the leader Election Algorithm. However, in later versions, only the "TCP-based version of fast leader election" algorithm is left, so this parameter does not seem to be used at present. initLimit # When a Follower is started, it synchronizes all the latest data from the Leader and determines the Starting Status of its external services. Leader allows F to complete this task within the initLimit time. In general, we do not need to care too much about the setting of this parameter. If the amount of data in the ZK cluster is large, the time for synchronizing data from the Leader will also become longer when F is started. Therefore, in this case, it is necessary to increase this parameter properly. syncLimit # During running, the Leader is responsible for communicating with all machines in the ZK cluster. For example, it uses some heartbeat detection mechanisms to detect the survival status of machines. If the heartbeat packet sent by L has not received the response from F after syncLimit, then the F is considered offline. Note: Do not set this parameter too large. Otherwise, some problems may be covered up. leaderServes # By default, the Leader accepts client connections and provides normal read/write services. However, if you want the Leader to focus on the coordination of machines in the cluster, you can set this parameter to no, which will greatly improve the performance of write operations. server.X=A:B:C # X is a number, indicating the number of server. A is the IP address of the server. b. Configure the port used by the server and the leader in the cluster to exchange messages. c. Configure the port used to elect the leader. here, x is a number, which is consistent with the id in the myid file. You can configure two ports on the right. The first port is used for data synchronization between F and L and other communications. The second port is used for voting communication during Leader election. group.x=nnnnn[:nnnnn]weight.x=nnnnn # Set machine group and weight, cnxTimeout # The timeout time for enabling a connection during the Leader election. The default value is 5 s. zookeeper.DigestAuthenticationProvider.superDigest # ZK permission settings skipACL # No ACL check is performed for all client requests. If a permission restriction is set on the previous node, once this header is opened on the server, it will also become invalid. forceSync # This parameter determines whether FileChannel. force needs to be called when transaction logs are submitted to ensure full data synchronization to the disk. jute.maxbuffer # The maximum data volume of each node. The default value is 1 MB. This restriction takes effect only when both the server and client are configured. |
2. Installation in pseudo cluster mode:
A pseudo cluster starts multiple zookeeper processes on a single machine and forms a cluster. Take starting three zookeeper processes as an example.
2.1 copy the zk directory zk2 and zk3
12 |
[zk@master ~]$ cp -r zk zk2 [zk@master ~]$ cp -r zk zk3 |
2.2 modify the configuration file separately
1234567891011 |
[zk@master conf]$ vim zoo.cfg initLimit=10 syncLimit=5 clientPort=2181 tickTime=2000 dataDir= /opt/zk/zk/data dataLogDir= /opt/zk/zk/logs server.0=127.0.0.1:5555:6666 server.1=127.0.0.1:5556:6667 server.2=127.0.0.1:5557:6668 |
Modify their zk directory configuration files dataDir, dataLogDir, and clientPort respectively.
Create a myid file in zk, zk2, zk3, and dataDir respectively, and write a number indicating the number of the server. the number must be equal to zoo. server. X in X corresponds to one by one.
/Opt/zk/data/myid file write 0,/opt/zk/zk2/data/myid file write 1, /opt/zk/zk3/data/myid file write 2.
123 |
[zk@master ~]$ echo 0 > /opt/zk/zk/data/myid [zk@master ~]$ echo 1 > /opt/zk/zk2/data/myid [zk@master ~]$ echo 2 > /opt/zk/zk3/data/myid |
2.3 start
Omitted
3. cluster mode installation
The configuration of the cluster mode is basically the same as that of the pseudo cluster.
In cluster mode, servers are deployed on different machines, so the conf/zoo. cfg files of each server can be identical.
Example:
123456789 |
tickTime=2000 initLimit=5 syncLimit=2 dataDir= /opt/zk/zk/data dataLogDir= /opt/zk/zk/logs clientPort=2180 server.0=192.168.10.128:5555:6666 server.1=192.168.10.129:5555:6666 server.2=192.168.10.130:5555:6666 |
Three zookeeper servers are deployed in the sample file, respectively at 192.168.10.128 ~ 130. Note that the numbers in the myid file under the dataDir directory of each server must be different.
Welcome to my personal website