[
https://issues.apache.org/jira/browse/PHOENIX-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255311#comment-17255311
]
Viraj Jasani commented on PHOENIX-6104:
---------------------------------------
Btw same test on 4.x is able to split SYSTEM.CATALOG 3 times (6 regions
overall). One of the sample log for confirmation:
{code:java}
org.apache.hadoop.hbase.regionserver.SplitRequest(136): Region split,
hbase:meta updated, and report to master.
Parent=SYSTEM.CATALOG,tenant1\x00SCHEMA3\x00,1609095523419.84e0f92d06bd71adb0e227d3b77b73f7.,
new regions:
SYSTEM.CATALOG,tenant1\x00SCHEMA3\x00,1609095539888.fadd8fa241e7a0d3a07ba0c14d33ef3e.,
SYSTEM.CATALOG,tenant2\x00SCHEMA4\x00,1609095539888.6ac72b09e62ee36a2cfe2e5b244a3dab..
Split took 4sec
{code}
So, HBase 1.x supports splitting small table but 2.x doesn't. Entire splitting
workflow is completely changed in 2.x compared to 1.x (from using ZK as
rendezvous in 1.x to using ProcV2 framework to better coordinate in 2.x).
Hence, if not allowing splitting small tables is a clear intention, it should
be present in early 2.x split workflow design or might have dedicated Jira.
Based on the code it looks intentional since even if we pass splitPoint, code
tries to get bestSplitPoint and has additional logic to check if split is
allowed.
Btw 2.x doesn't allow splitting is something that I came across for
TableSnapshotReadsMapReduceIT as well and that's why added many rows to table
to make split happen for sure.
> SplitSystemCatalogIT tests very unstable with Hbase 2.3
> -------------------------------------------------------
>
> Key: PHOENIX-6104
> URL: https://issues.apache.org/jira/browse/PHOENIX-6104
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.1.0
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
> Attachments: 6104-testouput.log
>
>
> The failure is in the test preparation code, where we split the system
> catalog table, and it seems to be a HBase issue, rather than a Phoenix one,
> but we need to track the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
