---
acl_categories:
- '@admin'
- '@slow'
- '@dangerous'
arguments:
- display_text: config-epoch
name: config-epoch
type: integer
arity: 3
categories:
- docs
- develop
- stack
- oss
- rs
- rc
- oss
- kubernetes
- clients
command_flags:
- admin
- stale
- no_async_loading
complexity: O(1)
description: Sets the configuration epoch for a new node.
group: cluster
hidden: false
linkTitle: CLUSTER SET-CONFIG-EPOCH
railroad_diagram: /images/railroad/cluster-set-config-epoch.svg
since: 3.0.0
summary: Sets the configuration epoch for a new node.
syntax_fmt: CLUSTER SET-CONFIG-EPOCH config-epoch
title: CLUSTER SET-CONFIG-EPOCH
---
This command sets a specific *config epoch* in a fresh node. It only works when:
1. The nodes table of the node is empty.
2. The node current *config epoch* is zero.
These prerequisites are needed since usually, manually altering the
configuration epoch of a node is unsafe, we want to be sure that the node with
the higher configuration epoch value (that is the last that failed over) wins
over other nodes in claiming the hash slots ownership.
However there is an exception to this rule, and it is when a new
cluster is created from scratch. Redis Cluster *config epoch collision
resolution* algorithm can deal with new nodes all configured with the
same configuration at startup, but this process is slow and should be
the exception, only to make sure that whatever happens, two more
nodes eventually always move away from the state of having the same
configuration epoch.
So, using `CLUSTER SET-CONFIG-EPOCH`, when a new cluster is created, we can
assign a different progressive configuration epoch to each node before
joining the cluster together.
## Redis Software and Redis Cloud compatibility
| Redis
Software | Redis
Cloud | Notes |
|:----------------------|:-----------------|:------|
| ❌ Standard
❌ Active-Active | ❌ Standard
❌ Active-Active | |