[GitHub] nickva commented on issue #1338: Configuring node "flavors" in a cluster

[GitBox <gi...@apache.org>]

nickva commented on issue #1338: Configuring node "flavors" in a cluster
URL: https://github.com/apache/couchdb/issues/1338#issuecomment-393693038
 
 
   I like the idea. It could allow for interesting configurations. Here are some thoughts I had:
   
   1. `replicator` - This would work trivially for _replicator jobs because they are not tied a particular replicator document and placement is based on hashing source, target and a few other parameters. There just getting the replicator node set would be good enough. However things become more complicated for replications backed by a replicator db. Currently ownership (placement) of a replication job is determined by where the replicator doc shards live, such that state updates (completed, failed etc) happen as local doc writes. If some nodes can accept document writes but not be replicator nodes, would mean that some replications would never be able to run. We could fix it in a couple of ways:
   
     - Allow non-local doc IO. So let replicator doc updates / reads happen remotely and distribute replication jobs based on a replication ID instead of document ID. Then only the replicator nodes would run replications. But with remove doc IO this would introduce new failure modes.
   
    - `_replicator` db shards placement is customized such that _replicator docs end up only on replicator nodes. This might work but not sure what would happen when replicator node set changes (a node stops being a replicator node). Then might need to do auto-migration of replicator shards
   
   2. `coordinator` vs `storage`. This would be great to have. Maybe the coordinator ones could have more CPU but less memory or other such hardware customizations. 
   
   It is also interesting to think about what happens during membership changes. That is in the period of time during and immediately after a node changes its membership. A bit like the case with a replicator above. But say if a node becomes a storage node, then stops being a storage node. Does all data it stored auto-migrate to other storage nodes and what happens during that transition. That would be great to have, and it would open the door to auto-resharding (but that's for a different discussion).

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services