hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Vissapragada <bhara...@apache.org>
Subject Re: [DISCUSS] About using masters as ConnectionRegistry endpoint
Date Mon, 16 Aug 2021 00:19:55 GMT
Thanks, Duo. I commented on the PR but want to respond here too to kick
start the discussion and in case anyone else has different viewpoints.

I agree that the original decision of inlining active masters needs to be
corrected going forward. I vote for the proposal to deprecate the master
based registry in 2.5.0 in favor of a "RegionServer" based registry and
remove it completely in 4.0.0.  IMO we should *not *expose any opt-in
configuration to allow masters as that violates the design principle that
we all agreed upon and instead only use region servers as the registry
hosting services.


On Fri, Aug 13, 2021 at 7:59 PM 张铎(Duo Zhang) <palomino219@gmail.com> wrote:

> In HBASE-18095, the community provided a new way to get the registry
> information of a cluster, without touching ZooKeeper. The decision at
> that time was to use masters(including active and backup masters) as
> the connection registry endpoint.
>
> Later, when discussing how to implement splittable meta, we planned to
> make use of this framework to hide the actual ROOT table
> implementation. But then we found out that the approach of using
> masters as connection registry, violates one of our tendencies that we
> do not want to inline masters, especially the active master in the
> normal read/write path.
>
> The several sub tasks of HBASE-26149 aims to solve this problem. We
> all agree that by default, we should not inline masters, but there are
> some conflicts on whether to still allow end users to configure that
> they want to use masters as registry endpoints, as it is a feature
> which has already been published in our releases.
>
> There are some discussions in the PR for HBASE-26172
> https://github.com/apache/hbase/pull/3566#discussion_r684494130
>
> Feel free to post your opinion here.
>
> Thanks.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message