Comment on page
Switching clients
You may want to switch clients if you are having issues with the one you are running or if it becomes the majority client. To switch the clients using slingnode.ethereum role you only need to update the "clients" variable and re-run the role.
- switching clients using the described method will incur downtime while your clients re-sync, refer to the considerations section for details
- the role does not delete previous client's data directories
- the role does not migrate validator keys
If you are running Geth and Lighthouse your "clients" variable looks as follows:
clients:
execution: geth
consensus: lighthouse
validator: lighthouse
You want to switch to Nethermind and Prysm you'd update your vars to as shown below and re-run the role.
clients:
execution: nethermind
consensus: prysm
validator: prysm
You can switch all or any of the layers using this method.
This section describes what to expect when switching specific layers.
The execution client will need to sync. The time it takes depends on many variables but in any case this will take days during which your node will not be able to perform Validator duties (if you run a Validator).
If you are switching back to a client that you used before and you did not delete the data directory, the client will pick up the existing database and sync from there. For example if you are testing clients you could sync all four of them and then switch among them with a minimal downtime (depending on how long the client was offline). Make sure there is a sufficient disk space.
The consensus client will need to sync. Consensus clients support checkpoint sync which lets them be up and running in minutes, therefore the downtime incurred should be minimal. Checkpoint sync is enabled by default when deploying clients using slingnode.ethereum role, refer to Checkpoint sync page for details.
In most cases it is desirable to delete the old data directory of a consensus client before switching back to it. This is because if a client finds an existing data directory it will disable the checkpoint sync and will start normal sync for the point where it left off. In most cases this will take longer to complete than the fresh sync from the checkpoint.
Validators don't have any state to sync, but they have keys and slashing protection DB to consider. Migrating validator keys and Slashing protection DB is outside of the scope of slingnode.ethereum role. Please refer to slingnode.ethereum_node_mgmt role for those tasks.
If you change the validator client the previous client will be stopped, new one deployed and started but the keys and slashing protection DB will not be migrated.
The role does not delete the existing data directories. This lets you keep the old data directory should you choose to switch back (assuming sufficient disk space). If you do not want to keep the old data directories you will need to delete them for example using slingnode.ethereum_node_mgmt role.
Following the example from the previous section, if you run Geth and Lighthouse your directory structure will look as follows:
blockchain/
├── blockchain_dc
│ ├── dc-blockchain-eth-consensus-lighthouse.yml
│ ├── dc-blockchain-eth-execution-geth.yml
│ └── dc-blockchain-eth-validator-lighthouse.yml
├── consensus
│ └── lighthouse
├── execution
│ └── geth
├── jwt
│ └── jwt.hex
├── scripts
│ └── prune_execution_client.py
└── validator
└── lighthouse
After updating the clients var to Nethermind and Prysm and re-running the role, the directory structure will be:
blockchain/
├── blockchain_dc
│ ├── dc-blockchain-eth-consensus-prysm.yml
│ ├── dc-blockchain-eth-execution-nethermind.yml
│ └── dc-blockchain-eth-validator-prysm.yml
├── consensus
│ ├── lighthouse
│ └── prysm
├── execution
│ ├── geth
│ └── nethermind
├── jwt
│ └── jwt.hex
├── scripts
│ └── prune_execution_client.py
└── validator
├── lighthouse
└── prysm
Last modified 5mo ago