[
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
(v6.3.4#6332)
