The user is having an issue where he has a master node, he is trying to point a second node to it via the reserved command; however, the secondary node continues to disconnect.
Original message link Discord
For trouble shooting, we made sure he had the latest snapshot (June 13th), his master node is synced and working correctly, his commands appear to be correct. the second node is set to port 30334, WS port 9945.
there’s the node start up logs. you can see it finds my master node at port 30333
- [5:27 AM]
./subspace-node-windows-x86_64-gemini-1b-2022-jun-10.exe --chain gemini-1 --execution wasm --pruning 1024 --keep-blocks 1024 --port 30334 --validator --name LifeSlave1 --base-path W:\clone1\ --ws-port 9945 --rpc-port 1999 --in-peers 10 --out-peers 10 --max-parallel-downloads 3 --reserved-nodes /ip4/184.108.40.206/tcp/30333/p2p/12D3KooWJ2x17xJEUaKi6MgN86hSR5et9i2dccm6L64jwL4UAyVw --reserved-only
- [5:27 AM]
@ALPHANOMICON try having the user also specify the reserved node on the other side.
Node A - reserved parameter for Node B
Node B - reserved parameter for Node A
This is not very well documented but apparently this is required for the parameter to work correctly as mentioned in a comment by a Substrate dev here Connections are dropped, even if peers are added to reserved nodes. · Issue #10836 · paritytech/substrate · GitHub
Looking to find more accurate documentation on this topic.
I’m the user It’s already set up this way. Node A, the archival node has Node B in its reserved-nodes argument. Node B has Node A in its reserved node argument AND reserved only.
I should have mentioned too - thisarrangement was working, albeit with a slow sync, with the Jun 10 executables. Sometime around Jun 12, it only got up to 23,000 blocks and the disconnects began appearing or the Idle (0 peers). I switched to Jun 13 executables and the situation was the same.
Reports of another user with this issue.
update on my end / info for troubleshooting
when i make one simple change - setting my archival node to --reserved only as well so that my master node and my secondary node are only pointing to each other and master is not looking to sync with the outside world - it works!
They find each other instantly, no disconnects and the secondary node syncs as expected.
So I dont know what this really means other than my master node won’t simultaneously sync with the blockchain AND feed the secondary node. It can only do one or the other.
see if adding the
--out-peers 100 command will help this issue, should allow more peer connections to sync the node
i tried that early on in the process, it didn’t do anything except massively increase my bandwidth for the same zero progress.
my secondary node is all synced now. After 12ish hours of my main node pointed at the slave node only, no external connections, the slave synced all the way. I’ve actually made the slave my primary node now as its got the much bigger plot size anyways.
And you guessed it - the ‘new slave’ which was the ‘old master’ has the same problem. I set the arguments on it new port, new ws-port, keeping the “reserved node” and “reserved only” part of the command in there.
IDLE (0 peers) won’t connect to my external facing node at all.
Are there any other settings that need to be set besides:
Node: new port and new ws port, reserved node address to archival and reserved only
Farmer: node-rpc-url pointed at new ws-port
How much are you plotting with your farmers in this setup?
my main archival node/farmer is 100GB. The secondary node/farmer plot size was 1.5TB. The issue appears to be unrelated to size though. I tried a 10GB plot size for the secondary and it was still refusing to connect.
The only way that I got a second node to sync up was to have the archival node point completely at it. Once the secondary node gets to the top of the chain, the archival node could only then ‘look’ to the outside world again and the relationship between the two nodes acts as expected: Archival node syncing with the chain externally and feeding the secondary node. Secondary node only connects to archival.
Both are able to maintain sync in this arrangement so long as they exist on SSD / NVME hardware.