A GlusterFS peer should leave the trusted pool only after its bricks and clients have already moved away from that server. Detaching the peer too early can leave volume definitions pointing at retired storage, and clients mounted through that node may miss later cluster configuration changes.
The trusted pool is managed by glusterd and shown through peer status and pool list. The peer detach command removes one server from the pool membership seen by the remaining nodes; it does not migrate data, remove bricks, delete volumes, or clean files from the retired host.
Run the detach from a different node that will stay in the pool, and use the same hostname or address shown by peer status. Reserve force for a permanently unreachable peer after volume definitions no longer reference that node, because forced detach skips the normal connected-peer checks.
Steps to remove a node from a GlusterFS trusted pool:
- List the current peers from a node that will remain in the pool.
$ sudo gluster peer status Number of Peers: 2 Hostname: node2.storage.example.net Uuid: 7e0b3b68-5c4e-40c3-902f-9e1d7cf07f2c State: Peer in Cluster (Connected) Hostname: node3.storage.example.net Uuid: e52ddf89-f4f1-46f8-bde6-5d53dced173a State: Peer in Cluster (Connected)
Use the hostname exactly as shown. Do not switch between short names, fully qualified names, and IP addresses during the same removal.
- List the full trusted pool and confirm the command is running on a server that will stay in the cluster.
$ sudo gluster pool list UUID Hostname State bca7490b-64c2-46d1-ae9a-4577cc03625f localhost Connected 7e0b3b68-5c4e-40c3-902f-9e1d7cf07f2c node2.storage.example.net Connected e52ddf89-f4f1-46f8-bde6-5d53dced173a node3.storage.example.net Connected
localhost is the node where the command is running. Detach node3.storage.example.net from node1 or node2, not from the retiring node itself.
- Review volume definitions and confirm the retiring node is not listed as a brick host.
$ sudo gluster volume info volume1 Volume Name: volume1 Type: Replicate Volume ID: 1f657d53-9d69-4bbb-9c2d-b9a8e31b58c7 Status: Started Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: node1.storage.example.net:/srv/gluster/brick1 Brick2: node2.storage.example.net:/srv/gluster/brick1
If the retiring node appears in any Brick line, remove or replace that brick before detaching the peer.
- Check volume status and wait until no volume task is active.
$ sudo gluster volume status volume1 Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick node1.storage.example.net:/srv/gluster/brick1 49152 0 Y 1831 Brick node2.storage.example.net:/srv/gluster/brick1 49153 0 Y 1794 Self-heal Daemon on node1.storage.example.net N/A N/A Y 1902 Self-heal Daemon on node2.storage.example.net N/A N/A Y 1875 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks
Wait for remove-brick, replace-brick, rebalance, heal, or snapshot tasks to finish before changing pool membership.
Related: How to check GlusterFS volume status
- Detach the retiring peer from a remaining pool member.
$ sudo gluster peer detach node3.storage.example.net peer detach: success
If a client-remount prompt appears, confirm it only after clients using the retiring peer are mounted through another active peer. Use force only when the peer is permanently unreachable and no volume lists its bricks.
- Verify that the detached node no longer appears in peer status.
$ sudo gluster peer status Number of Peers: 1 Hostname: node2.storage.example.net Uuid: 7e0b3b68-5c4e-40c3-902f-9e1d7cf07f2c State: Peer in Cluster (Connected)
- List the pool again and confirm only the remaining nodes are connected.
$ sudo gluster pool list UUID Hostname State bca7490b-64c2-46d1-ae9a-4577cc03625f localhost Connected 7e0b3b68-5c4e-40c3-902f-9e1d7cf07f2c node2.storage.example.net Connected
- Check the remaining volume bricks after the pool change.
$ sudo gluster volume status volume1 Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick node1.storage.example.net:/srv/gluster/brick1 49152 0 Y 1831 Brick node2.storage.example.net:/srv/gluster/brick1 49153 0 Y 1794 Self-heal Daemon on node1.storage.example.net N/A N/A Y 1902 Self-heal Daemon on node2.storage.example.net N/A N/A Y 1875 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
