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

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?

anmolnar · 2026-01-09T17:25:37Z

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?

We can certainly do that, but in that case I'm not sure how to generate meta table names for the replica clusters. They have to be unique at the same storage location and with files we would able to scan existing files for conflicts. By storing it in master local region I'm not sure how to do it, unless we use UUIDs as suffixes.

Same issue arises with the directory name of Master local region of a replica cluster. Shall we use the configured replica name or the generated suffix?

Actually this might be the right way:

Generate suffix for replica: "3a63c0f"
Try to create master local region directory: "MasterData_3a63c0f"
If succeeds, use this suffix for meta table name: "meta_3a63c0f"
If not, go back to step 1.

Question: how would the replica cluster know about its suffix?

Apache9 · 2026-01-10T08:27:18Z

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?

We can certainly do that, but in that case I'm not sure how to generate meta table names for the replica clusters. They have to be unique at the same storage location and with files we would able to scan existing files for conflicts. By storing it in master local region I'm not sure how to do it, unless we use UUIDs as suffixes.

Same issue arises with the directory name of Master local region of a replica cluster. Shall we use the configured replica name or the generated suffix?

Actually this might be the right way:

Generate suffix for replica: "3a63c0f"

Try to create master local region directory: "MasterData_3a63c0f"

If succeeds, use this suffix for meta table name: "meta_3a63c0f"

If not, go back to step 1.

Question: how would the replica cluster know about its suffix?

Anyway you need something in the configuration to tell a cluster that you are a read replica cluster or not, so you can just add a configuration named replica_suffix?

anmolnar · 2026-01-13T14:17:20Z

Anyway you need something in the configuration to tell a cluster that you are a read replica cluster or not, so you can just add a configuration named replica_suffix?

That's where we started. It's already there:

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

I think we started the conversation about whether we should use this replica.id in the meta table and master region directory name or generate a random value for each replica?

Apache9 · 2026-01-13T15:22:40Z

Anyway you need something in the configuration to tell a cluster that you are a read replica cluster or not, so you can just add a configuration named replica_suffix?

That's where we started. It's already there:
<property>
    <name>hbase.read.replica.id</name>
    <value>replica1</value>
</property>
I think we started the conversation about whether we should use this replica.id in the meta table and master region directory name or generate a random value for each replica?

As long as the replica id must be unique, I think use it as master local region's suffix is enough? For meta table, I'm nature on whether to reuse this id too, or we could generate one and store it in master local region, seems the former one is enough but the latter is more flexible, and as said above, theoretically we could even change the meta table name.

Thanks.

…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

…tic: Add dynamic meta table name discovery via ConnectionRegistry

…tic: Rename references

…tic: Rename references 2

…tic: Add meta table name in master region

…tic: Format code part 1

…tic: Format code part 2

…tic: Format code part 3: spotless

…tic: Format code part 4

…tic: resolve conflicts

…tic: spotless

…tic: reformat

anmolnar

@Apache9

I don't think we're getting anywhere with this patch and I tend to stop wasting more efforts here. We might be able to find an easier approach for integration testing with multiple clusters.

What do you think about this new approach? Is it the same what was on your mind?

anmolnar · 2026-01-27T20:58:13Z

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

+  @Deprecated
+  public static TableName META_TABLE_NAME =


Is it still being used somewhere? Shouldn't we just remove it?

There no usages for this in the current patch. I have changed all the references to either use connection or hard coded "hbase:meta" (in just a couple of places but majorly in tests). I marked it Deprecated for backward compatibility.
We can still use this deprecated var in all those above mentioned references to make this patch smaller but needs some rework later and also here. We would need another PR later, maybe after read replica, to delete this from TableName and move this into TEST_UTILS.

anmolnar · 2026-01-27T21:09:57Z

hbase-server/src/main/java/org/apache/hadoop/hbase/HBaseServerBase.java

+    // For now, always return the default meta table name.
+    // Future implementations may support custom meta table names from configuration or storage.
+    return org.apache.hadoop.hbase.TableName
+      .valueOf(org.apache.hadoop.hbase.NamespaceDescriptor.SYSTEM_NAMESPACE_NAME_STR, "meta");


Why is it still hardcoded?
You're already initializing it in HMaster properly and just need to return it.

Missed updating this one. Will make this abstract and implement this method in HRegionServer as well.

As RegionServer does not have access to Master Region, I left this as default here and override the method in HRegionServer to use Connection. However during bootstrap, we would need meta table name for creating connection object, so only during bootstrap it falls back to default (here).

Further, when we implement the config for creating the meta table name suffix, we can add that calculation logic here and pass the name along to HMaster to store it in Master Region during bootstrap. Please let me know your thoughts.

hbase-client/src/main/java/org/apache/hadoop/hbase/client/ZKConnectionRegistry.java

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

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

hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/InitMetaProcedure.java

hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java

…tic: address comments 1

…tic: fix unit tests

…tic: fix unit tests 1

Apache-HBase · 2026-01-29T16:36:24Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 34s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 2s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+0 🆗	buf	0m 0s		buf was not available.
+0 🆗	buf	0m 0s		buf 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 12s		Maven dependency ordering for branch
+1 💚	mvninstall	2m 54s		master passed
+1 💚	compile	10m 26s		master passed
+1 💚	checkstyle	4m 37s		master passed
+1 💚	spotbugs	10m 7s		master passed
+1 💚	spotless	0m 43s		branch has no errors when running spotless:check.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 12s		Maven dependency ordering for patch
+1 💚	mvninstall	2m 52s		the patch passed
+1 💚	compile	10m 20s		the patch passed
+1 💚	cc	10m 20s		the patch passed
-0 ⚠️	javac	0m 48s	/results-compile-javac-hbase-client.txt	hbase-client generated 1 new + 127 unchanged - 0 fixed = 128 total (was 127)
-0 ⚠️	javac	3m 16s	/results-compile-javac-hbase-server.txt	hbase-server generated 1 new + 192 unchanged - 1 fixed = 193 total (was 193)
+1 💚	blanks	0m 1s		The patch has no blanks issues.
-0 ⚠️	checkstyle	0m 15s	/results-checkstyle-hbase-common.txt	hbase-common: The patch generated 3 new + 2 unchanged - 0 fixed = 5 total (was 2)
+1 💚	rubocop	0m 3s		No new issues.
+1 💚	spotbugs	11m 49s		the patch passed
+1 💚	hadoopcheck	11m 2s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	hbaseprotoc	4m 45s		the patch passed
+1 💚	spotless	0m 44s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	2m 11s		The patch does not generate ASF License warnings.
		88m 37s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/10/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 cc buflint bufcompat hbaseprotoc rubocop
uname	Linux a9e80cb6a1a8 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 / `fe30eec`
Default Java	Eclipse Adoptium-17.0.11+9
Max. process+thread count	86 (vs. ulimit of 30000)
modules	C: hbase-protocol-shaded 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/10/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.

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

Kota-SH force-pushed the HBASE-29691 branch from 3f4fdde to 2319f52 Compare January 22, 2026 15:46

This comment has been minimized.

Sign in to view

Kota-SH added 7 commits January 27, 2026 10:59

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

107a8aa

…tic: org.apache.hadoop.hbase

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

7a39e71

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

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

c0cec14

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

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

91f3fb7

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

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

d7806f6

…tic: rest

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

cbcf57b

…tic: fix spotless

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

e41984b

…tic: Add dynamic meta table name discovery via ConnectionRegistry

Kota-SH added 7 commits January 27, 2026 11:01

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

be38a8c

…tic: Rename references

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

256ab2f

…tic: Rename references 2

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

2f04670

…tic: Add meta table name in master region

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

7a474ec

…tic: Format code part 1

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

5a6c4f0

…tic: Format code part 2

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

14fa2bf

…tic: Format code part 3: spotless

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

2f7c86e

…tic: Format code part 4

Kota-SH force-pushed the HBASE-29691 branch from b37a150 to 099dbc4 Compare January 27, 2026 16:24

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

7fd0759

…tic: resolve conflicts

Kota-SH force-pushed the HBASE-29691 branch from 099dbc4 to 7fd0759 Compare January 27, 2026 16:30

This comment has been minimized.

Sign in to view

Kota-SH added 2 commits January 27, 2026 13:05

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

d14945b

…tic: spotless

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

0974dd4

…tic: reformat

This comment has been minimized.

Sign in to view

anmolnar reviewed Jan 27, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

wchevreuil reviewed Jan 28, 2026

View reviewed changes

hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java Outdated Show resolved Hide resolved

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

7916626

…tic: address comments 1

Kota-SH requested review from Apache9, anmolnar and wchevreuil January 29, 2026 00:01

This comment has been minimized.

Sign in to view

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

c0a96ff

…tic: fix unit tests

This comment has been minimized.

Sign in to view

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

fe30eec

…tic: fix unit tests 1

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.

This comment has been minimized.

This comment has been minimized.

Apache9 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wchevreuil commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

anmolnar commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Apache9 commented Jan 10, 2026

Uh oh!

anmolnar commented Jan 13, 2026

Uh oh!

Apache9 commented Jan 13, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

anmolnar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Apache-HBase commented Jan 29, 2026

Uh oh!

Reviewers

Assignees

Apache9 commented Dec 19, 2025 •

edited

Loading

anmolnar commented Dec 19, 2025 •

edited

Loading

anmolnar commented Jan 9, 2026 •

edited

Loading