The Basics
Witnesses
Sidechain Operator Nodes (SONs)
Bookie Oracle Suite (BOS)
Other Documentation
Backup Servers
Running a backup node on another server to prevent downtime
When running a node, it's important to minimize downtime. This can be difficult when you have to stop the node to perform upgrades to the software or to troubleshoot an issue. This is where having a backup server comes in handy.
This document will explain how to set up a backup server that runs in parallel to your main server. When necessary, you can quickly switch to your backup node so users will not experience any downtime. Then you can perform your maintenance and switch back once complete.
1. Creating a Backup Server
In this tutorial, it's assumed that you have a Witness node up and running according to the Witness node documentation. As such, you'll have your witness-id and public-private key-pair containing the signing key within the
config.ini file. As an example, you might have the following in the config:1
witness-id = "1.6.41"
2
private-key = ["PPY7ZBgUduxjAsk5zXLeZX8skTHAjqQAyu6NnoSDKHs2Utm5XsDLR","some-private-key"]
Copied!
1.1. Step 1: Install a Witness Node on a Second Server
Just like the first time you installed a witness node, you'll need to do it again on a separate server. You can follow the same instructions provided in the witness node documentation.
The important part of the second install is to generate another signing key, different from the first. To do this, you'll use the
suggest_brain_key command:1
suggest_brain_key
Copied!
Which will return something like this:
1
suggest_brain_key
2
{
3
"brain_priv_key": "SECOHM OBESELY REVERER YARD CAZA TYROSYL HATTING MYOTOMY FARDO WANGHEE ACOLYTE TOPKNOT DETENT THICK BOODIE TEMPRE",
4
"wif_priv_key": "5JCMoqthZ95S6NJ16fqMs18qZrkegWTW9xgAxBKG3LeseorGv9e",
5
"pub_key": "PPY8gjHZE13qLmSUmvMGR8mZWcD1ejLUkPhg4j9bNG6bRzWjZSUBM"
6
}
Copied!
And then you'll use the
wif_priv_key in the output above in the config.ini file on the second server, for example:1
witness-id = "1.6.41"
2
private-key = ["PPY8gjHZE13qLmSUmvMGR8mZWcD1ejLUkPhg4j9bNG6bRzWjZSUBM","5JCMoqthZ95S6NJ16fqMs18qZrkegWTW9xgAxBKG3LeseorGv9e-key"]
Copied!
At this point you'll see the following message on the second server if you were to run that node:
1
[block_production_loo ] Not producing block because I don't have the private key for
2
PPY7ZBgUduxjAsk5zXLeZX8skTHAjqQAyu6NnoSDKHs2Utm5XsDLR
Copied!
Since you haven't switched the nodes yet, that's what we expect.
1.2. Step 2: Making the Switch
To flip the node production, you'll run the
update_witness command in the cli_wallet:1
update_witness example-witness "https://example.com/peerplays-blockchain-witness-proposal" "PPY8gjHZE13qLmSUmvMGR8mZWcD1ejLUkPhg4j9bNG6bRzWjZSUBM" true
Copied!
Congrats! You updated your witness to use the new signing key!
🎉
Soon after you'll see this message on your first server:
1
[block_production_loo ] Not producing block because I don't have the private key for
2
PPY8gjHZE13qLmSUmvMGR8mZWcD1ejLUkPhg4j9bNG6bRzWjZSUBM
Copied!
Your second server will now be producing blocks. You just pulled a quick switch from server 1 to server 2 without missing any blocks. Now you can safely shut down server 1 and update the code. once the code is updated and the node is restarted, you can switch back signing blocks to server 1 using the
update_witness command again with the public-key for server 1.1
update_witness example-witness "https://example.com/peerplays-blockchain-witness-proposal" "PPY7ZBgUduxjAsk5zXLeZX8skTHAjqQAyu6NnoSDKHs2Utm5XsDLR" true
Copied!
It's always a good idea to maintain a backup witness server for block production, in case of downtime on one server or the need to update code without shutting down your production node. A back up server will also be useful in case of an attack on the network.
Last modified 1yr ago
Export as PDF
Copy link