# Managing replication nodes

<!-- example managing replication nodes 1 -->
The `ALTER CLUSTER <cluster_name> UPDATE nodes`  statement updates the node lists on each node within the specified cluster to include all active nodes in the cluster. For more information on node lists, see [Joining a cluster](../../Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md).


<!-- intro -->
##### SQL:

<!-- request SQL -->

```sql
ALTER CLUSTER posts UPDATE nodes
```

<!-- request JSON -->

```json
POST /cli -d "
ALTER CLUSTER posts UPDATE nodes
"
```

<!-- request PHP -->

```php
$params = [
  'cluster' => 'posts',
  'body' => [
     'operation' => 'update',

  ]
];
$response = $client->cluster()->alter($params);
```
<!-- intro -->
##### Python:

<!-- request Python -->

```python
utilsApi.sql('ALTER CLUSTER posts UPDATE nodes')
```

<!-- response Python -->
```python
{u'error': u'', u'total': 0, u'warning': u''}
```

<!-- intro -->
##### Python-asyncio:

<!-- request Python-asyncio -->

```python
await utilsApi.sql('ALTER CLUSTER posts UPDATE nodes')
```

<!-- response Python-asyncio -->
```python
{u'error': u'', u'total': 0, u'warning': u''}
```

<!-- intro -->
##### Javascript:

<!-- request javascript -->

```javascript
res = await utilsApi.sql('ALTER CLUSTER posts UPDATE nodes');
```

<!-- response javascript -->
```javascript
{"total":0,"error":"","warning":""}
```

<!-- intro -->
##### java:

<!-- request Java -->

```java
utilsApi.sql("ALTER CLUSTER posts UPDATE nodes");
```

<!-- intro -->
##### C#:

<!-- request C# -->

```clike
utilsApi.Sql("ALTER CLUSTER posts UPDATE nodes");
```

<!-- intro -->
##### Rust:

<!-- request Rust -->

```rust
utils_api.sql("ALTER CLUSTER posts UPDATE nodes", Some(true)).await;
```

<!-- end -->

If [authentication and authorization](../../Security/Authentication_and_authorization.md) is enabled, `ALTER CLUSTER ... UPDATE nodes`, `ALTER CLUSTER ... ADD`, and `ALTER CLUSTER ... DROP` use the stored cluster user. To change the stored cluster user, grant `replication` permission to the new user and run:

```sql
ALTER CLUSTER posts UPDATE user 'repl_user'
```

The new stored user must be provisioned with matching authentication data on the nodes that will participate in later cluster operations. Those operations fail if the stored user is missing, has different auth data, or loses `replication` permission.

For instance, when the cluster was initially established, the list of nodes used to rejoin the cluster was `10.10.0.1:9312,10.10.1.1:9312`. Since then, other nodes joined the cluster and now the active nodes are `10.10.0.1:9312,10.10.1.1:9312,10.15.0.1:9312,10.15.0.3:9312`.However, the list of nodes used to rejoin the cluster has not been updated.

To rectify this, you can run the `ALTER CLUSTER ... UPDATE nodes` statement to copy the list of active nodes to the list of nodes used to rejoin the cluster. After this, the list of nodes used to rejoin the cluster will include all the active nodes in the cluster.

Both lists of nodes can be viewed using the [Cluster status](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) statement (`cluster_post_nodes_set` and `cluster_post_nodes_view`).

## Removing node from cluster

To remove a node from the replication cluster, follow these steps:
1. Stop the node
2. Remove the information about the cluster from  `<data_dir>/manticore.json` (usually `/var/lib/manticore/manticore.json`) on the node that has been stopped.
3. Run `ALTER CLUSTER cluster_name UPDATE nodes` on any other node.

After these steps, the other nodes will forget about the detached node and the detached node will forget about the cluster. This action will not impact the tables in the cluster or on the detached node.

## EXIT CLUSTER

`EXIT CLUSTER <cluster_name>` is the online equivalent of the manual detach flow above. It removes the local node from the replication cluster, keeps the local tables intact as regular local tables, saves the local config, and then asks the surviving peers to refresh their persisted node lists using the existing `ALTER CLUSTER ... UPDATE nodes` machinery.

```sql
EXIT CLUSTER posts
```

Use `EXIT CLUSTER` when you want to detach only the current node. Use `DELETE CLUSTER` when you want to remove the cluster from every node.

`EXIT CLUSTER` is only allowed for a healthy local node in a primary cluster. If the command returns a warning, the local detach already succeeded, but some follow-up may still be required. In that case run `ALTER CLUSTER <cluster_name> UPDATE nodes` on any surviving node to finish refreshing the remaining cluster metadata.

If the surviving side becomes a clean one-node cluster after `EXIT CLUSTER`, it remains a replication cluster. After a clean shutdown, that surviving node can be started normally and should return as `primary` / `synced`; you do not need `--new-cluster` for this self-only case.
<!-- proofread -->
