Non transactional Metadata

Metadata which describe tables can be update inside the context of transactions (create table, alter table, drop table....) and so they are treated as common 'data', this kind of data is stored inside local files to the node which is responsible for the tablespace (leader or replica, no difference). This sort of data can be updated only by the leader of the tablespace, and so there is no need of distributed coordination.

But there is another kind of metadata which describe the system and has the following properties:

• They are managed by the whole group of servers, so they need to be handled using distributed coordination
• They are not subject to transactions

Metadata which fall into this case are:

• definition of the tablespaces
• definition of the nodes which form the cluster
• definition of the role of each node in respect to each tablespace (who is leader? who is replica?)

On a distributed setup (cluster) metadata are stored on Apache ZooKeeper which acts the role of managing the global consensus of this special metadata. On a single machine setup these metadata are stored on local disk and are managed using simple local locks.

On ZooKeeper the cluster relies on a base path (defaults to '/herddb') and creates child nodes for each type of metadata

TableSpace metadata

For each tablespace metadata there is a ZK node /herddb/tablespaces/TABLESPACENAME which contains metadata about the TableSpace, the format is the following:

• tableSpaceName: string
• flags: int
• leaderId: string
• expectedReplicaCount: int
• number of replicas: int
• for each replica: -- nodeId: string -- maxLeaderInactivityTime: long

Node metadata

For each node there is a ZK node /herddb/nodes/NODEID which contains metadat about the Node, the format is the following:

• nodeId: string
• flags: int
• host: string
• port: int
• ssl: int (1 = ssl enabled)