About a month ago, I wrote a blog entry about how to connect to a ZooKeeper. Now, I will talk about how to create, read, delete, and write the znodes, which are what I will refer to as the permission sets later on. First way is to do it via command prompt (in Windows) as a client, and on my next blog entry, I will talk about how to do them in Java.
Each znode has its own permission sets. They are: Create, Read, Delete, Write, and Admin (abbreviated CRDWA). I will talk more in detail about the permission sets, how to set them, as well as the access control list (ACL) in the later blog posts.
1. Types of Znodes
Before I get into creating them, let’s briefly talk about the types of znodes: persistent, ephemeral, and sequential.
1.1. Persistent Znodes
These are the default znodes in ZooKeeper. They will stay in the zookeeper server permanently, as long as any other clients (including the creator) leave it alone.
1.2. Ephemeral Znodes
Ephemeral znodes (also referred as session znodes) are temporary znodes. Unlike the persistent znodes, they are destroyed as soon as the creator client logs out of the ZooKeeper server. For example, let’s say client1 created
eznode1. Once client1 logs out of the ZooKeeper server, the
eznode1 gets destroyed.
1.3. Sequential Znodes
Sequential znode is given a 10-digit number in a numerical order at the end of its name. Let’s say client1 created a
sznode1. In the ZooKeeper server, the
sznode1 will be named like this:
If client1 creates another sequential znode, it would bear the next number in a sequence. So the next sequential znode will be called
2. Znode “Anatomy”
Each znode has variety of different stats, such as its path, name, data it stores, when it was created, its own permission sets, etc. For the sake of simplicity and demonstration, I will only talk about the path, name and data.
Path of all znodes will ALWAYS start with the root, or a slash symbol. In this example, the path of
znode1 would be as follows:
/znode1, and its name is
znode1. All znodes consist of data (it can also be blank). Keep in mind that data is stored in a byte array, because this will be important to know by the time we deal with znode data in Java.
In order to do anything with a znode, you must specify its path. If you only specify its name, it will tell you about the syntax error, so keep that in mind.
3. Creating a Znode
As mentioned earlier, znodes are persistent by default. In a ZooKeeper client, we type in commands to perform different actions with the znode, such as create, delete, update its data, etc.
To create a znode, we need to specify its path (see above). Now remember, a path of any znode ALWAYS starts with the root znode. The command syntax for creating a znode is as follows:
create -<options> /<znode-name> <znode-data>
With that in mind, following are the examples for creating different types of znodes:
create /znode mydata
create –e /eznode mydata
create –s /sznode mydata
Each znode can also have a child znodes; this really depends on the permission set of that particular znode. For instance, if a nochild znode has a RDWA permission set, where create is not allowed, then nochild znode cannot have any children znodes. Please note that in the following syntax:
create /<parent-znode>/<child-znode> <child-znode-data>
<parent-znode> MUST exist in order to create the
<child-znode%gt;; otherwise, it will not work.
** NOTE: ephemeral znodes CANNOT contain any child znode! Because ephemeral znodes are temporary, they will be destroyed should the creator client logs out of the ZooKeeper server, meaning all children znodes under that ephemeral znode will be destroyed automatically as well. To prevent that, ephemeral znodes cannot bear any child znode.
4. Deleting a Znode
There are 2 ways to delete a znode. First way is to just typical deletion, and second way is recursive deletion.
We have a
deleteme znode, and as you may have guessed, following command deletes the
If we wanted to delete a child znode (
i_am_bug in this example) instead, we just need to specify the path of that child znode, like so:
Second way to delete a znode is recursive deletion. This method is necessary to delete a znode with child(ren) znode(s), because using the
delete command will not work.
Recursion in general is taking a big problem, and taking baby steps to solve it. It’s also known as the “divide and conquer” approach of solving the problem. In this case, it will start deleting znodes at the lowermost level first, one by one, then work its way up.
I really like this command, because it works with znodes without child(ren) z(s) as well. In that case, might as well use rmr command for any other znodes, just be careful not to delete the child znode you need to keep.
5. Reading a Znode Data
Here, we use the
get command to fetch the data of that particular znode. As always, specify the path of the znode you want to get the data off of.
This command will also return what’s also known as the stat. Data is located on the top line. Stat provides the detailed information of the znode, such as when it was created/re-written, version, number of children it contains, etc.
The only time
get command will not work on a znode is if the read permission is not allowed in the permission set, or if the znode has ACL (Access Control List) set to digest, hosts (depends on the hosts), or IP (also depends on the IP). I will talk more about the ACL in my later blog posts.
6. (Re) Writing a Znode Data
We use the
set command to overwriting the znode data. As always, specify the path of the znode you want to overwrite.
set /<znode-name> <new-data>
Once executed, it will return the stat of the znode, excluding the new data you have set. Like the
get command, the
set command will not work if the write permission is not allowed in the permission set, or if its ACL has been configured accordingly.
By now, you should be able to execute basic commands for the znodes. In the next blog post, I will talk about how to do them in Java.