hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12975) Supportable SplitTransaction and RegionMergeTransaction interfaces
Date Mon, 16 Mar 2015 18:04:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363615#comment-14363615

Andrew Purtell commented on HBASE-12975:

bq. As for the current patch SplitTransactionImpl supports splitting only one region at a
time. If we want to split multiple regions do we need to have custom implementation?

A custom implementation is possible. What factory to use for instantiating transactions can
be changed in configuration. I don't think this would be "supportable" though. You couldn't
do this in a downstream project, for example and expect any level of source, binary, or semantic
compatibility, because any implementation would require use of any number of private interfaces
to make a split happen.  

bq. Can you explain bit more how we can add more regions to split transactionally?

Currently, regions are managed independently *except* when running a region merge transaction,
for obvious reasons. I would hesitate to extend the scope of this issue to also make major
changes to how split transactions work, so I don't think we should change SplitTransaction
to handle coordination of splits of multiple regions, but if you have a specific proposal
of course we should look at it.

What about allowing coprocessors or other internal users to create multiple SplitTransactions
and coordinate them? The interfaces here would need some more work, but the procedure might
go something like:

# Instantiate N SplitTransactions
# Run each SplitTransaction up to PONR. Can be done in parallel. If there's a failure, invoke
the rollback method on all and try again and/or do some other remediation. 
# Run each SplitTransaction past PONR. Can be done in parallel. If there's a failure, the
server must abort. 

The major difference between the above and current proposal is we allow an interface user
to drive transaction execution in coordinated pre- and post-PONR phases to allow clean up
without abort if there's a pre-PONR failure. We could actually continue to hide the pre- and
post-PONR distinction from the API by adding a helper class that you create with an array
of SplitTransaction, then call an {{execute}} method. It would do the above coordination.
We could call it {{SplitTransactions}} ? 

What do you think?

> Supportable SplitTransaction and RegionMergeTransaction interfaces
> ------------------------------------------------------------------
>                 Key: HBASE-12975
>                 URL: https://issues.apache.org/jira/browse/HBASE-12975
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Rajeshbabu Chintaguntla
>            Assignee: Andrew Purtell
>             Fix For: 2.0.0, 1.1.0
>         Attachments: HBASE-12975.patch, HBASE-12975.patch
> Making SplitTransaction, RegionMergeTransaction limited private is required to support
local indexing feature in Phoenix to ensure regions colocation. 
> We can ensure region split, regions merge in the coprocessors in few method calls without
touching internals like creating zk's, file layout changes or assignments.
> 1) stepsBeforePONR, stepsAfterPONR we can ensure split.
> 2) meta entries can pass through coprocessors to atomically update with the normal split/merge.
> 3) rollback on failure.

This message was sent by Atlassian JIRA

View raw message