[
https://issues.apache.org/jira/browse/KUDU-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838884#comment-16838884
]
Alexey Serbin commented on KUDU-2823:
-------------------------------------
{quote}
Right now we will add new range every day for a fact table which has range+hash
partitions, and then rebalance it as soon as possible.
{quote}
As [~granthenke] mentioned, it would be nice to understand what's wrong with
current policies so there is a need to rebalance after adding new
partitions/tablets. What version of Kudu exhibits the behavior that requires
running rebalancer after adding a series of new tablets even if all tablet
servers are online and functional? And what kind of imbalance is that?
A Kudu cluster might become unbalanced after adding new tablet servers or after
a long period of when some tablet servers were not available, and corresponding
tablet replicas have been migrated to other tablet servers. However, current
placement policy are supposed to place new replicas evenly enough already.
> Rebalance range partition
> -------------------------
>
> Key: KUDU-2823
> URL: https://issues.apache.org/jira/browse/KUDU-2823
> Project: Kudu
> Issue Type: Improvement
> Reporter: HeLifu
> Assignee: Xu Yao
> Priority: Major
>
> Right now we will add new range every day for a fact table which has
> range+hash partitions, and then rebalance it as soon as possible. It seems
> that not only the new added tablets of this table but also the historical
> tablets will be rebalanced. But the historical tablets already have data, so
> they are heavy to move and it will increase the disk and network suddenly.
> So, I think it will be good to rebalance the new added range partitions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
