+1 (binding) And I am +1 for 2.3.0 include this feature, too.
张铎(Duo Zhang) <[email protected]> 于2020年2月29日周六 上午10:51写道： > I think we still need two more binding votes here... > > 张铎(Duo Zhang) <[email protected]> 于2020年2月29日周六 上午10:43写道： > > > Attached the design doc in HBASE-23911. > > > > Bharath Vissapragada <[email protected]> 于2020年2月24日周一 下午2:37写道： > > > >> +1 (non-binding). > >> > >> I've gone through the doc and it generally made sense to me. Mind adding > >> the doc to dev-support/design-docs too? > >> > >> On Sat, Feb 22, 2020 at 5:32 AM Duo Zhang <[email protected]> wrote: > >> > >> > The issue aims to make rs group the first class citizen in HBase, > where > >> the > >> > feature can be enabled through a simple flag, not a complicated > >> > coprocessor, and also we can manage it through the Admin interface, > >> while > >> > in the old time the only public way is to through the shell command, > as > >> the > >> > coprocessor client is marked as IA.Private. > >> > > >> > This is a simple design doc > >> > > >> > <goog_2028452043> > >> > > >> > > >> > https://docs.google.com/document/d/1SuodZ_uDQQQVJyryRxqp033cgz2aQPJmjIREbbbmB3c/edit?usp=sharing > >> > > >> > The PR for all the changes > >> > > >> > https://github.com/apache/hbase/pull/1165 > >> > > >> > And let me copy the release note here > >> > > >> > Moved rs group feature into core. Use this flag to enable or disable > it. > >> > > >> > The coprocessor org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint > is > >> > deprected, but for compatible, if you want the pre 3.0.0 hbase > >> client/shell > >> > to communicate with the new hbase cluster, you still need to add this > >> > coprocessor to master. And if this coprocessor is specified, the above > >> flag > >> > will be set to true automatically to enable rs group feature. > >> > > >> > These methods are added to the Admin/AsyncAdmin interface for managing > >> rs > >> > groups. See the javadoc of these methods for more details. > >> > > >> > void addRSGroup(String groupName) throws IOException; > >> > RSGroupInfo getRSGroup(String groupName) throws IOException; > >> > RSGroupInfo getRSGroup(Address hostPort) throws IOException; > >> > RSGroupInfo getRSGroup(TableName tableName) throws IOException; > >> > List<RSGroupInfo> listRSGroups() throws IOException; > >> > List<TableName> listTablesInRSGroup(String groupName) throws > >> IOException; > >> > Pair<List<String>, List<TableName>> > >> > getConfiguredNamespacesAndTablesInRSGroup(String groupName) throws > >> > IOException; > >> > void removeRSGroup(String groupName) throws IOException; > >> > void removeServersFromRSGroup(Set<Address> servers) throws > >> IOException; > >> > void moveServersToRSGroup(Set<Address> servers, String targetGroup) > >> > throws IOException; > >> > void setRSGroup(Set<TableName> tables, String groupName) throws > >> > IOException; > >> > boolean balanceRSGroup(String groupName) throws IOException; > >> > > >> > The shell commands for rs group are not changed. > >> > > >> > The main difference on the implementation is that, now the rs group > for > >> a > >> > table is stored in TableDescriptor, instead of in RSGroupInfo, so the > >> > getTables method of RSGroupInfo has been deprecated. And if you use > the > >> > above Admin methods to get the RSGroupInfo, its getTables method will > >> > always return empty. Of course the behavior for the old > >> > RSGroupAdminEndpoint is not changed, we will fill the tables field of > >> the > >> > RSGroupInfo before returning, to make it compatible with old hbase > >> > client/shell. > >> > > >> > When upgrading, the migration between the RSGroupInfo and > >> TableDescriptor > >> > will be done automatically. It will take sometime, but it is fine to > >> > restart master in the middle, the migration will continue after > restart. > >> > > >> > The vote will open for at least 72 hours. > >> > > >> > Please vote > >> > > >> > [+1] Agree > >> > [-1] Disagree > >> > > >> > Thanks. > >> > > >> > > >
