You are viewing an older version of this section. View current production version.
Leaf
In a MemSQL cluster, a leaf node functions as a storage and compute node. Leaves are responsible for storing slices of data in the MemSQL cluster.
To optimize performance, the MemSQL system automatically distributes data across leaf nodes into partitions. Each leaf is a MemSQL server consisting of several partitions. Each partition is just a database on that server.
Leaf States
Each leaf is in one of four states:
| State | Description |
|---|---|
Unknown |
In this state, a leaf is not part of the cluster. This is the state before you run ADD LEAF to introduce the leaf into the system. A leaf that is unknown will not show up in SHOW LEAVES . The REMOVE LEAF command will transition a leaf into the unknown state. |
Online |
This is the default, healthy state of a leaf. In the online state, the leaf is an active member of the distributed system and is either currently serving or ready to serve data to the aggregators. |
Offline |
A leaf enters the offline state if the master aggregator cannot reach it. The master aggregator heartbeats each leaf node by running the SELECT 1 query. The master aggregator continues to ping offline nodes. |
Detached |
A leaf transitions from offline to detached when it is once again reachable. You can reintroduce the leaf into the online state with the ATTACH LEAF command. This command will automatically try to reuse the data present on the leaf; this is especially important in redundancy-1. DETACH LEAF is the same as REMOVE LEAF except that after rebalancing away a leaf’s partitions, it transitions it to detached instead of unknown. |
The following diagram summarizes the leaf states and the transitions between them:
Leaf Commands
Starting a Leaf
A leaf node is started as a MemSQL node without additional parameters. Once started, you can run ADD LEAF on the Master Aggregator to add the node (as a leaf) to the cluster.
