1

Taking the question a step back.

I'm looking to build payment using bitcoin myself. The whole point of bitcoin is decentralisation and sovereignty.

Basically I need High Availability set up for bitcoin full node myself with no single point of failure. So that my website can reliably transact and receive payments.

== Original Text ==
Any one know or tried running bitcoin core server with the data stored on a NAS and a load balancer in front of it?

I'm basically looking for some kind of high availability set up (on aws with autoscaling group / EFS / ELB)

  • would you mind sharing the purpose of this setup and what are the requirements? – renlord Oct 20 '17 at 10:58
  • Why do you want to have multiple Bitcoin Core nodes behind a load balancer? – Andrew Chow Oct 20 '17 at 15:44
  • I am interested in building payment service for my site. I will need to make sure that the payment service doesn't have a single point of failure. @renlord – Sleeper Smith Oct 22 '17 at 2:38
  • @SleeperSmith Can you make your question more specific for what you want to do, not what you think is the solution for what you want to do? We want to avoid the XY problem here. – Andrew Chow Oct 22 '17 at 2:52
  • @AndrewChow done. – Sleeper Smith Oct 27 '17 at 9:50
2

This won't work. Multiple instances of Bitcoin Core cannot use the same datadir. Furthermore, LevelDB does not usually work well with network storage so you probably can't even get the datadir to actually be stored on a NAS and still have Bitcoin Core work properly.

You could have multiple Bitcoin Core instances running behind a load balancer, but it probably won't be as useful as you think it will be.

  • Yeah that's what I'm not keen on, multiple load balancer that doesn't provide consistent response between them. – Sleeper Smith Oct 22 '17 at 2:40
0

You can use haproxy or nginx to balance between the REST and RPC interfaces, but this doesn't work if you need to use any of the wallet functions, and there's no guarantee that any of the information at the tip of the chain will be consistent. Many mining pools use setups like this, but they don't need to have any assurance that the information between the nodes is identical, where you would have this requirement if you were running a service (flopping between confirmations for example would be harmful).

If your service is heavily bottlenecking on a node there's probably going to be other problems, the APIs will become unresponsive when updating the tip of the chain for example. Attempt to design services which are resistant to this sort of instability, rather than trying to expand horizontally with multiple nodes as that will greatly add to your complexity without much improvement of scalability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.