How to remove a node from a GlusterFS trusted pool

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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)
  7. 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
  8. 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