{"push_id":2491099345,"size":1,"distinct_size":1,"ref":"refs/heads/allocation#27427-1","head":"46fa6ed12557c9717b5f9ac8897819c373e0dd9c","before":"6b9e25a4573a2b76b3ec0780510d9185fef73a9a","commits":[{"sha":"46fa6ed12557c9717b5f9ac8897819c373e0dd9c","author":{"name":"Bukhtawar Khan","email":"d5127a6341d61b9919adc38ffeaa2d989c780cca@gmail.com"},"message":" 1.We are throttling source nodes at a shard level once the node the primary shard is on hits an outgoing recovery limit. This will prevent the shard from getting looped over all the major deciders\n 2.We are throttling target nodes at a node level since it’s safe to make a pre-emptive decision and promoting early termination of iteration once we are out of eligible target. To achieve this we are pre-computing before the iteration and re-computing eligible target nodes after every shard allocation to a target node. This is especially very helpful when the shards are migrating at max recovery at which time only fewer shards are relocated at every shard started event.\n 3.Introducing a new cluster_concurrent_recovery settings which can allow only a specific number of shard recoveries within a cluster.\n 4.Checking cluster_concurrent_rebalance early to figure out if the number of relocating shards have already breached this limit instead of checking this limit against every shard to be rebalanced","distinct":true,"url":"https://api.github.com/repos/Bukhtawar/elasticsearch/commits/46fa6ed12557c9717b5f9ac8897819c373e0dd9c"}]}
{"actor":{"display_login":"Bukhtawar"}}