You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Charles Connell (Jira)" <ji...@apache.org> on 2025/05/15 14:20:00 UTC
[jira] [Updated] (HBASE-29315) ModifyTableProcedure should hold exclusive table lock for duration of procedure
[ https://issues.apache.org/jira/browse/HBASE-29315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charles Connell updated HBASE-29315:
------------------------------------
Description:
When adding new replicas, ModifyTableProcedure roughly does the following:
# Edits the table descriptor
# Closes and opens all existing regions
# Creates replication peer to support the new replica regions
# Opens new replica regions
When closing a region in step 2, the act of closing it can trigger a split. When the HMaster runs the SplitTableRegionProcedure, it roughly does:
# Close the region to be split
# Split the store files
# Open the new daughter regions (including replicas)
When a split is done as part of a ModifyTableProcedure that adds replicas, we get the following combination of behavior:
# Edit the table descriptor
# Close and open all existing regions, adding a
SplitTableRegionProcedure to the HMaster's queue
# To begin the SplitTableRegionProcedure, close region to be split
# Split store files
# Open the new daughter regions, including replicas, completing the
SplitTableRegionProcedure
# Create replication peer to support the new replica regions
# Open new replica regions, even though some were already opened in step 5. Double-opening doesn't work, and the open procedures get stuck.
There are a few ways to correct this problem, but perhaps the most intuitive way is to use the existing lock mechanisms in the procedure system. The ModifyTableProcedure can lock the table from beginning to end, allowing only itself and its child procedures to modify the table.
Discussed over [email|https://lists.apache.org/thread/0x4pxr5jt8cwprq6xhxr6d5g3lctlhhc].
was:
When adding new replicas, ModifyTableProcedure roughly does the following:
# Edits the table descriptor
# Closes and opens all existing regions
# Creates replication peer to support the new replica regions
# Opens new replica regions
When closing a region in step 2, the act of closing it can trigger a split. When the HMaster runs the SplitTableRegionProcedure, it roughly does:
# Close the region to be split
# Split the store files
# Open the new daughter regions (including replicas)
When a split is done as part of a ModifyTableProcedure that adds replicas, we get the following combination of behavior:
# Edit the table descriptor
# Close and open all existing regions, adding a
SplitTableRegionProcedure to the HMaster's queue
# To begin the SplitTableRegionProcedure, close region to be split
# Split store files
# Open the new daughter regions, including replicas, completing the
SplitTableRegionProcedure
# Create replication peer to support the new replica regions
# Open new replica regions, even though some were already opened in step 5. Double-opening doesn't work, and the open procedures get stuck.
There are a few ways to correct this problem, but perhaps the most intuitive is to use the existing lock mechanisms in the procedure system. The ModifyTableProcedure can lock the table from beginning to end, allowing only itself and its child procedures to modify the table.
Discussed over [email|https://lists.apache.org/thread/0x4pxr5jt8cwprq6xhxr6d5g3lctlhhc].
> ModifyTableProcedure should hold exclusive table lock for duration of procedure
> -------------------------------------------------------------------------------
>
> Key: HBASE-29315
> URL: https://issues.apache.org/jira/browse/HBASE-29315
> Project: HBase
> Issue Type: Bug
> Components: proc-v2
> Reporter: Charles Connell
> Assignee: Charles Connell
> Priority: Minor
>
> When adding new replicas, ModifyTableProcedure roughly does the following:
> # Edits the table descriptor
> # Closes and opens all existing regions
> # Creates replication peer to support the new replica regions
> # Opens new replica regions
> When closing a region in step 2, the act of closing it can trigger a split. When the HMaster runs the SplitTableRegionProcedure, it roughly does:
> # Close the region to be split
> # Split the store files
> # Open the new daughter regions (including replicas)
> When a split is done as part of a ModifyTableProcedure that adds replicas, we get the following combination of behavior:
> # Edit the table descriptor
> # Close and open all existing regions, adding a
> SplitTableRegionProcedure to the HMaster's queue
> # To begin the SplitTableRegionProcedure, close region to be split
> # Split store files
> # Open the new daughter regions, including replicas, completing the
> SplitTableRegionProcedure
> # Create replication peer to support the new replica regions
> # Open new replica regions, even though some were already opened in step 5. Double-opening doesn't work, and the open procedures get stuck.
> There are a few ways to correct this problem, but perhaps the most intuitive way is to use the existing lock mechanisms in the procedure system. The ModifyTableProcedure can lock the table from beginning to end, allowing only itself and its child procedures to modify the table.
> Discussed over [email|https://lists.apache.org/thread/0x4pxr5jt8cwprq6xhxr6d5g3lctlhhc].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)