4 ms·
We have two ways of re-building a node under this setup. We can either re-build the node by simply wiping its disks, and letting it stream in data from other r
by jhgg 4y ago
We have two ways of re-building a node under this setup.
We can either re-build the node by simply wiping its disks, and letting it stream in data from other replicas, or we can re-build by simply re-syncing the pd-ssd to the nvme.
Node failure is a regular occurrence, it isn't a "bad" thing, and something we intend to fully automate. Node should be able to fail and recover without anyone noticing.
- TheGuyWhoCodes 4y agoThanks for the info that's exactly what I thought the recovery process should be. Node failure isn't bad until it's a cascading catastrophe :) But by bad I meant when a Node is based on local disks, that Cassandra and ScyllaDB usually recommends. Depending on the time between snapshots and the restore from snapshot process (if there are even snapshots...) can be problematic. Bootstrapping nodes from zero depending on the cluster size (Big data nodes while not recommended are pretty common) could take days in Cassandra because the streaming implements was (maybe still is?) very bad
- jhgg 4y agoScylladb is luckily much faster. We can rebuild a ~5TB node in a matter of hours.
- TheGuyWhoCodes 4y agoDoesn't streaming affect the node network? Isn't that an issue or do you have a dedicated NIC for intra node communications? or do you just limit the streaming bandwidth? Thanks.
- jhgg 4y agoNo dedicated NICs, the link speeds are fast enough to not really worry about this. It's also worth mentioning that in a cluster of N, to recover a node, it simply needs to stream 1/(N - 1) of the data from its neighboring nodes. So when you look at the cluster as a whole, and the strain on each node that is UP and serving traffic, it's insignificant.