As the network block height continues to increase, the time to sync a new node continues to increase as well. We can provide jumpstart files to reduce the time required to fully sync, and Hydra and be used to handle the generate and application of these.
Setup
To generate a jumpstart file for a network, you need to have the SSH Key used in the provisioning of the network. Additionally, you will need to have the network bootstrapping information locally in your ${HYDRA_WORKDIR}/network.json file.
If you don't have the network bootstrap information, you can populate that from the S3 bucket via a new command.
Once you have the bootstrap information local, you can continue with the generation of the jumpstart file. This requires a network to have more than 1 provisioned node; since this process stops one of the running nodes we don't want to stop the node that is also acting as the network's single Oracle.
Upload that tarfile to the S3 bucket at jumpstart/<network>/<date>_<blockheight>_<network>.tar.gz
And create or update a metadata file jumpstart/<network>/jumps.json with the available jumpstart files for a network. The latest will always be updated to the most recent jumpstart tarfile, and a new entry for the specific blockheight will be added as well:
By default Hydra will now attempt to find and apply a jumpstart file automatically when joining a network. If no jumpstarts are found, then the joining continues as before and does a full sync from scratch. This behavior can be modified or disabled via arguments to join-network:
# Disable jumpstart
hydra client join-network --name shipchain-testnet-beta --jumpstart none
# This is the default behavior to use the latest jumpstart
hydra client join-network --name shipchain-testnet-beta --jumpstart latest
# Use a specific jumpstart file (must be defined in jumps.json)
hydra client join-network --name shipchain-testnet-beta --jumpstart 1407148
Additionally, if your node encounters corruption you may need to re-sync. You can apply jumpstart files on top of an existing node to sync from a known good point to prevent a full re-sync from scratch. This does not overwrite the node's private keys. However, we still recommend backing them up prior to this action.
As the network block height continues to increase, the time to sync a new node continues to increase as well. We can provide jumpstart files to reduce the time required to fully sync, and Hydra and be used to handle the generate and application of these.
Setup
To generate a jumpstart file for a network, you need to have the SSH Key used in the provisioning of the network. Additionally, you will need to have the network bootstrapping information locally in your
${HYDRA_WORKDIR}/network.jsonfile.If you don't have the network bootstrap information, you can populate that from the S3 bucket via a new command.
Generation
Once you have the bootstrap information local, you can continue with the generation of the jumpstart file. This requires a network to have more than 1 provisioned node; since this process stops one of the running nodes we don't want to stop the node that is also acting as the network's single Oracle.
This will ssh to the last bootstrapped node, create a remote tarfile containing the following contents:
Upload that tarfile to the S3 bucket at
jumpstart/<network>/<date>_<blockheight>_<network>.tar.gzAnd create or update a metadata file
jumpstart/<network>/jumps.jsonwith the available jumpstart files for a network. Thelatestwill always be updated to the most recent jumpstart tarfile, and a new entry for the specific blockheight will be added as well:Client Use
By default Hydra will now attempt to find and apply a jumpstart file automatically when joining a network. If no jumpstarts are found, then the joining continues as before and does a full sync from scratch. This behavior can be modified or disabled via arguments to join-network:
Additionally, if your node encounters corruption you may need to re-sync. You can apply jumpstart files on top of an existing node to sync from a known good point to prevent a full re-sync from scratch. This does not overwrite the node's private keys. However, we still recommend backing them up prior to this action.