[
https://issues.apache.org/jira/browse/KUDU-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118788#comment-17118788
]
Alexey Serbin commented on KUDU-2604:
-------------------------------------
[~granthenke], yes, I think the remaining functionality can be broken down into
smaller JIRA items. At the higher level, I see the following pieces:
* Define and assign tags to tablet servers.
* Update master's placement policies to take into account tags when
adding/distributing replicas of tablets.
* Add support for C++ and Java clients: clients can specify set of tags when
creating tables.
* The {{kudu cluster rebalance}} tool and the auto-rebalancer honors the tags
when rebalancing corresponding tables. The tools is also able to report on
tablet replicas which are placed in a non-conforming way w.r.t. tags specified
for tables (those con-conformant-placed replicas might appear during automatic
re-replication: this is something similar that we have with current placement
policies).
* The {{kudu cluster ksck}} CLI tool provides information on tags for tablet
servers.
We can create sub-tasks for this if we decide to implement this.
> Add label for tserver
> ---------------------
>
> Key: KUDU-2604
> URL: https://issues.apache.org/jira/browse/KUDU-2604
> Project: Kudu
> Issue Type: New Feature
> Reporter: Hong Shen
> Priority: Major
> Labels: location-awareness, rack-awareness
> Fix For: n/a
>
> Attachments: image-2018-10-15-21-52-21-426.png
>
>
> When the cluster is bigger and bigger, big table with a lot of tablets will
> be distributed in almost all the tservers, when client write batch to the big
> table, it may cache connections to lots of tservers, the scalability may
> constrained.
> If the tablets in one table or partition only in a part of tservers, client
> will only have to cache connections to the part's tservers. So we propose to
> add label to tservers, each tserver belongs to a unique label. Client
> specified label when create table or add partition, the tablets will only be
> created on the tservers in specified label, if not specified, defalut label
> will be used.
> It will also benefit for:
> 1 Tserver across data center.
> 2 Heterogeneous tserver, like different disk, cpu or memory.
> 3 Physical isolating, especially IO, isolate some tables with others.
> 4 Gated Launch, upgrade tservers one by one label.
> In our product cluster, we have encounter the above issues and need to be
> resolved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
