EdColeman commented on issue #3157:
URL: https://github.com/apache/accumulo/issues/3157#issuecomment-1376119298

   The behavior may be desired or maybe not and is user dependent.  The initial 
use case for the min tservers was to protect against starting the master before 
at least X tservers were online.  What would happen is the manager processes 
would be started and then the tservers - and as soon as the manager saw one (or 
a few tservers) the metadata tables would be assigned and then it was off to 
the races, where almost everything would be assigned to a few tservers and then 
a lengthy delay with migrations and reassignments.  The tserver min count was 
to ensure the X servers would be available before the manager would proceed.  
Maybe that's 25%, 50%, 99.999% of your servers? 
   
   The whole thing can be avoided and handled external to Accumulo.  If the 
start-up sequence is ZooKeeper, Hadoop, tservers and then the manager 
processes.  The tservers will register with ZooKeeper and wait.  Users can then 
choose to validate that things are okay before proceeding.  And that "okay"  is 
up to the user.  Maybe you have strict requirements that with some kind of 
custom balancer that some nodes are more important that others where some 
things are pinned to servers with specific capabilities (say the metadata 
tables)  - then, maybe you'd want to make sure they were online and registered 
before that manager starts, and the actual count is less important.
   
   Others, could decide that if I can't get to 25% I do not want to proceed - I 
don't care how long that is, without at least 25% I never want to start.  For 
others, it could be wait for 99.999%, but if I don't get that, well if we wait 
30 minutes, I guess that what we have is as good enough, and all we can do for 
right now.
   
   So, the count was basically a simplistic trigger-guard for a particular 
foot-gun. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to