EdColeman commented on issue #3159: URL: https://github.com/apache/accumulo/issues/3159#issuecomment-1385517153
Some of this conversation was covered in #3157. The specific use case the initial change was to provide a guarantee that some number of tservers were up and available to handle tablet assignments on start-up. Assume that you are using something like pssh and it is working through a list of servers to start the tservers - it does not get very far through the list before the manager starts flooding the first few tservers that have checked in with the entire cluster assignments - and then that takes a long while to rebalance. The comments in this thread show the conflicting opinions on how this should be used: - wait forever until n are available (current behavior). - wait for t until n are available - fail if n is not reached if t is exceeded. - wait for t until n are available - if t reached, go with what you have. None of these are "incorrect" and depended on user expectations. The core issue is that if the manager is started first, then almost all tablets are assigned to the first few tservers that register. First root, then metadata, then everything else... So when the manager starts, as soon as it sees the first tserver register, the root and metadata table tablets get assigned there - then it starts assigning everything else - maybe a few tservers have come on line - but likely not nearly the number expected and not enough to handle the assignments quickly. If I set a small number, say 10% of total expected servers then my expectations on continuing are going to different than if I choose 99%. With 10% I have set a bar that accepts that rebalancing may occur, but there are enough tservers to handle those assignments. With 99% I am likely trying to minimize any rebalencing and even if I reach 98% after a reasonable amount of time then I accept proceeding. The original intent was more towards the 10% case - guarantee that there is a minimum number of tservers present. The issue raised in #3157 expected behavior more like the 99% case. Another factor may be the ability to recover / reset. If the timeout is infinite or fails and n is not reached, the assignments never start - you could change n in ZooKeeper, or change the property value and restart the master. If the assignments ignore n and start after t - then you basically need to accept the situation and wait. -- 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]
