1) Riak will make use of fallback vnodes, so in the event node C is down during the write, node D will start a fallback vnode to handle requests until it becomes available again. As soon as C becomes available, D will intitiate hinted handoff to bring the vnodes on node C up to date. The use of fallbacks is described here
2) If you are removing node C while it is still able to function and wish to run a smaller cluster, use cluster leave to cause Riak to reassign ownership and transfer the data before shutting down node C.
If you are removing node C to replace it new hardware, first join then new node, but use replace before plan or commit.
If node C has failed such that it's data is unrecoverable, you can use force-remove
or force-replace
to have new empty vnodes started to replace the lost ones, which will the be populated via AAE or read repair.
3) Yes, Riak uses sloppy quorums where a fallback vnode can be used to satisfy a read or write quorum. If you want to only consider primary vnodes, use pr
or pw
in the request instead of r
or w
. See Eventual Consistency for more detail.