HBASE-29691: Change TableName.META_TABLE_NAME from being a global static #7558

Kota-SH · 2025-12-16T18:02:47Z

Jira: https://issues.apache.org/jira/browse/HBASE-29691

…tic: org.apache.hadoop.hbase

…tic: org.apache.hadoop.hbase.client

…tic: org.apache.hadoop.hbase.master

…tic: org.apache.hadoop.hbase.regionserver

…tic: rest

…tic: fix spotless

Apache-HBase · 2025-12-16T22:30:32Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 42s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 1s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+0 🆗	mvndep	0m 17s		Maven dependency ordering for branch
+1 💚	mvninstall	4m 14s		master passed
+1 💚	compile	13m 42s		master passed
+1 💚	checkstyle	5m 47s		master passed
+1 💚	spotbugs	10m 38s		master passed
+1 💚	spotless	1m 12s		branch has no errors when running spotless:check.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 13s		Maven dependency ordering for patch
+1 💚	mvninstall	4m 6s		the patch passed
+1 💚	compile	12m 49s		the patch passed
+1 💚	javac	12m 49s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
-0 ⚠️	checkstyle	0m 16s	/results-checkstyle-hbase-common.txt	hbase-common: The patch generated 3 new + 2 unchanged - 0 fixed = 5 total (was 2)
+1 💚	rubocop	0m 15s		No new issues.
+1 💚	spotbugs	12m 43s		the patch passed
+1 💚	hadoopcheck	12m 45s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	0m 51s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	2m 5s		The patch does not generate ASF License warnings.
		100m 7s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7558
JIRA Issue	HBASE-29691
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless rubocop
uname	Linux 7b9f17878fcd 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `3f4fdde`
Default Java	Eclipse Adoptium-17.0.11+9
Max. process+thread count	95 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-zookeeper hbase-balancer hbase-server hbase-mapreduce hbase-diagnostics hbase-testing-util hbase-thrift hbase-shell hbase-backup hbase-it hbase-rest U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3 rubocop=1.37.1
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Apache-HBase · 2025-12-17T01:41:33Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 13s		Docker mode activated.
-0 ⚠️	yetus	0m 3s		Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
			_ Prechecks _
			_ master Compile Tests _
+0 🆗	mvndep	0m 13s		Maven dependency ordering for branch
+1 💚	mvninstall	2m 51s		master passed
+1 💚	compile	3m 59s		master passed
+1 💚	javadoc	2m 52s		master passed
+1 💚	shadedjars	5m 14s		branch has no errors when building our shaded downstream artifacts.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 10s		Maven dependency ordering for patch
+1 💚	mvninstall	2m 29s		the patch passed
+1 💚	compile	3m 43s		the patch passed
+1 💚	javac	3m 43s		the patch passed
+1 💚	javadoc	2m 56s		the patch passed
+1 💚	shadedjars	4m 24s		patch has no errors when building our shaded downstream artifacts.
			_ Other Tests _
+1 💚	unit	1m 53s		hbase-common in the patch passed.
+1 💚	unit	0m 27s		hbase-hadoop-compat in the patch passed.
+1 💚	unit	1m 12s		hbase-client in the patch passed.
+1 💚	unit	0m 37s		hbase-zookeeper in the patch passed.
+1 💚	unit	7m 57s		hbase-balancer in the patch passed.
+1 💚	unit	195m 31s		hbase-server in the patch passed.
+1 💚	unit	15m 59s		hbase-mapreduce in the patch passed.
+1 💚	unit	1m 49s		hbase-diagnostics in the patch passed.
+1 💚	unit	1m 45s		hbase-testing-util in the patch passed.
+1 💚	unit	6m 7s		hbase-thrift in the patch passed.
+1 💚	unit	6m 47s		hbase-shell in the patch passed.
+1 💚	unit	12m 4s		hbase-backup in the patch passed.
+1 💚	unit	0m 39s		hbase-it in the patch passed.
+1 💚	unit	2m 49s		hbase-rest in the patch passed.
		291m 18s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR	#7558
JIRA Issue	HBASE-29691
Optional Tests	javac javadoc unit compile shadedjars
uname	Linux 46047f12d54f 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `3f4fdde`
Default Java	Eclipse Adoptium-17.0.11+9
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/testReport/
Max. process+thread count	4421 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-zookeeper hbase-balancer hbase-server hbase-mapreduce hbase-diagnostics hbase-testing-util hbase-thrift hbase-shell hbase-backup hbase-it hbase-rest U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/console
versions	git=2.34.1 maven=3.9.8
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Apache9

I do not think this is the correct way, at least you should not let clients config meta table name right? They should ask the meta table name from bootstrap node.

Theoretically, we can even support changing meta table name at runtime, clients and region servers can ask meta table name from master when they hit table not found exception when accessing meta.

And if we think this is a bit difficult to implement, and maybe there is no need to change meta table name after initialization, then maybe we can introduce a config to set meta table name when bootstraping a cluster, then we record this name in master local region or on HDFS directly. But anyway, clients and region servers still need to ask for the meta table name from master, not from configuration. But they just do not need to deal with meta table name change when running.

Thanks.

Apache9 · 2025-12-17T13:49:09Z

hbase-common/src/main/java/org/apache/hadoop/hbase/MetaTableName.java

+    if (instance == null) {
+      synchronized (MetaTableName.class) {
+        if (instance == null) {
+          instance = initializeHbaseMetaTableName(HBaseConfiguration.create());


I do not think this is a good practise, as this is still static, what if a client wants to connect different read replica clusters? And it will difficult to write UTs when you want to set up two clusters with different meta table names...

I do not think this is a good practise, as this is still static

I agree, this does not change the static referring.

what if a client wants to connect different read replica clusters?

Could clients use different configurations for each cluster being accessed?

wchevreuil · 2025-12-18T15:53:15Z

And if we think this is a bit difficult to implement, and maybe there is no need to change meta table name after initialization, then maybe we can introduce a config to set meta table name when bootstraping a cluster, then we record this name in master local region or on HDFS directly. But anyway, clients and region servers still need to ask for the meta table name from master, not from configuration. But they just do not need to deal with meta table name change when running.

Could be as simple as the hbase.id approach (a single file under the root dir containing the meta suffix generated during bootstrap)? Then all processes would load that file when initialising?

wchevreuil · 2025-12-18T15:20:09Z

hbase-common/src/main/java/org/apache/hadoop/hbase/MetaTableName.java

+  private static TableName initializeHbaseMetaTableName(Configuration conf) {
+    TableName metaTableName =
+      TableName.valueOf(NamespaceDescriptor.SYSTEM_NAMESPACE_NAME_STR, "meta");
+    LOG.info("Meta table suffix value: {}", metaTableName);
+    return metaTableName;


Where is the conf being used here? And the suffix?

wchevreuil · 2025-12-18T15:43:02Z

hbase-common/src/main/java/org/apache/hadoop/hbase/MetaTableName.java

+    if (instance == null) {
+      synchronized (MetaTableName.class) {
+        if (instance == null) {
+          instance = initializeHbaseMetaTableName(HBaseConfiguration.create());


I do not think this is a good practise, as this is still static

I agree, this does not change the static referring.

what if a client wants to connect different read replica clusters?

Could clients use different configurations for each cluster being accessed?

anmolnar · 2025-12-18T18:20:53Z

Shall we add meta table name to ConnectionRegistry?
ConnectionFactory will fetch it from active master or get it from ZooKeeper and set it in the Connection object where clients will find it easily.

ZooKeeper quorums will be distinct between replica clusters, so it could be a good place to store meta table name during the bootstrap process. We don't need to support changing it in runtime.

For instance, in cluster bootstrap process:

read configuration for suffix / replica id setting "replica1"

<property>
    <name>hbase.meta.table.suffix</name>
    <value>replica1</value>
 </property>

generate meta table name based on the above setting:
- if suffix is not set: "hbase:meta"
- if suffix is set: "hbase:meta_386330f"
store generated table name in ZooKeeper and retrieve it via ConnectionRegistry

wdyt?

Apache9 · 2025-12-19T01:50:33Z

Let's not introduce new persistent data on zookeeper, we could store it on HDFS on in the master local region. Maybe we should introduce a shell command like 'add_read_replica_cluster xxx' and execute it at the primary cluster, the primary cluster will generate the meta name suffix file or record for read replica clusters.

anmolnar · 2025-12-19T02:34:22Z

Let's not introduce new persistent data on zookeeper, we could store it on HDFS on in the master local region. Maybe we should introduce a shell command like 'add_read_replica_cluster xxx' and execute it at the primary cluster, the primary cluster will generate the meta name suffix file or record for read replica clusters.

HDFS won't be sufficient, because it's shared between the clusters. Could be in master local region, but that doesn't contradict with making it accessible via ConnectionRegistry. Is that correct?

Apache9 · 2025-12-19T03:29:47Z

Let's not introduce new persistent data on zookeeper, we could store it on HDFS on in the master local region. Maybe we should introduce a shell command like 'add_read_replica_cluster xxx' and execute it at the primary cluster, the primary cluster will generate the meta name suffix file or record for read replica clusters.

HDFS won't be sufficient, because it's shared between the clusters. Could be in master local region, but that doesn't contradict with making it accessible via ConnectionRegistry. Is that correct?

We coud use different file names for different read replica clusters?

anmolnar · 2025-12-19T17:09:27Z

Let's not introduce new persistent data on zookeeper, we could store it on HDFS on in the master local region. Maybe we should introduce a shell command like 'add_read_replica_cluster xxx' and execute it at the primary cluster, the primary cluster will generate the meta name suffix file or record for read replica clusters.

HDFS won't be sufficient, because it's shared between the clusters. Could be in master local region, but that doesn't contradict with making it accessible via ConnectionRegistry. Is that correct?

We coud use different file names for different read replica clusters?

So basically, we read from the config:

<property>
    <name>hbase.read.replica.id</name>
    <value>replica1</value>
</property>

and create a file on HDFS: hbase.replica1

meta_table_name=hbase:meta_3a63c0f

?

Apache9 · 2025-12-20T09:14:55Z

Let's not introduce new persistent data on zookeeper, we could store it on HDFS on in the master local region. Maybe we should introduce a shell command like 'add_read_replica_cluster xxx' and execute it at the primary cluster, the primary cluster will generate the meta name suffix file or record for read replica clusters.

HDFS won't be sufficient, because it's shared between the clusters. Could be in master local region, but that doesn't contradict with making it accessible via ConnectionRegistry. Is that correct?

We coud use different file names for different read replica clusters?

So basically, we read from the config:
<property>
    <name>hbase.read.replica.id</name>
    <value>replica1</value>
</property>
and create a file on HDFS: hbase.replica1
meta_table_name=hbase:meta_3a63c0f
?

Was thinking of this approach. But after considering, if we could use different master local region for different HBase read replicas, we could just store this value in master local region? In this way the primary cluster does not need to know the read replicas. Maybe this is better?

Kota-SH added 6 commits December 16, 2025 10:52

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

900f4f2

…tic: org.apache.hadoop.hbase

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

ee32818

…tic: org.apache.hadoop.hbase.client

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

59c879e

…tic: org.apache.hadoop.hbase.master

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

cc7b635

…tic: org.apache.hadoop.hbase.regionserver

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

cb14442

…tic: rest

HBASE-29691: Change TableName.META_TABLE_NAME from being a global sta…

3f4fdde

…tic: fix spotless

Kota-SH force-pushed the HBASE-29691 branch from ae3dcbd to 3f4fdde Compare December 16, 2025 18:15

This comment has been minimized.

Sign in to view

Apache9 requested changes Dec 17, 2025

View reviewed changes

wchevreuil reviewed Dec 18, 2025

View reviewed changes

HBASE-29691: Change TableName.META_TABLE_NAME from being a global static #7558

Are you sure you want to change the base?

HBASE-29691: Change TableName.META_TABLE_NAME from being a global static #7558

Conversation

Kota-SH commented Dec 16, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Apache-HBase commented Dec 16, 2025

Uh oh!

Apache-HBase commented Dec 17, 2025

Uh oh!

Apache9 left a comment

Choose a reason for hiding this comment

Uh oh!

Apache9 Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

wchevreuil Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

wchevreuil commented Dec 18, 2025

Uh oh!

wchevreuil Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

wchevreuil Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

anmolnar commented Dec 18, 2025

Uh oh!

Apache9 commented Dec 19, 2025

Uh oh!

anmolnar commented Dec 19, 2025

Uh oh!

Apache9 commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anmolnar commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Apache9 commented Dec 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Apache9 commented Dec 19, 2025 •

edited

Loading

anmolnar commented Dec 19, 2025 •

edited

Loading