[
https://issues.apache.org/jira/browse/HBASE-14623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206772#comment-15206772
]
stack commented on HBASE-14623:
-------------------------------
Please post evidence assignment is faster rather than suppositions.
bq. Currently with distributed log splitting, not only would log splitting for
system table (such as hbase:namespace) have to finish, but also log splitting
for user tables has to complete before tables are assigned. In this regard,
there is no slow down in assignment.
You have introduced an extra step -- the split of each of the new system table
logs -- and yet it is costless?
bq. That's right.
So, one means for handling hbase:meta -- a system table -- and then a
copy/paste to do other system tables (log rolling, etc.)? Why are they not
unified?
bq. No. That is not the case. Keeping .meta WAL is mostly for backward
compatibility.
This is reasonable.
Yeah, needs tests and evidence and cluster testing. This should be on by
default or not included at all. Unify the hbase:meta and system table handling
ratehr than have same code repeated. It is a PITA doing cleanup after the
fact... of finding bugs in one implementation and not realizing the second
exists (with same bug).
> Implement dedicated WAL for system tables
> -----------------------------------------
>
> Key: HBASE-14623
> URL: https://issues.apache.org/jira/browse/HBASE-14623
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: Ted Yu
> Assignee: Ted Yu
> Labels: wal
> Fix For: 2.0.0
>
> Attachments: 14623-v1.txt, 14623-v2.txt, 14623-v2.txt, 14623-v2.txt,
> 14623-v2.txt, 14623-v3.txt, 14623-v4.txt
>
>
> As Stephen suggested in parent JIRA, dedicating separate WAL for system
> tables (other than hbase:meta) should be done in new JIRA.
> This task is to fulfill the system WAL separation.
> Below is summary of discussion:
> For system table to have its own WAL, we would recover system table faster
> (fast log split, fast log replay). It would probably benefit
> AssignmentManager on system table region assignment. At this time, the new
> AssignmentManager is not planned to change WAL. So the existence of this JIRA
> is good for overall system, not specific to AssignmentManager.
> There are 3 strategies for implementing system table WAL:
> 1. one WAL for all non-meta system tables
> 2. one WAL for each non-meta system table
> 3. one WAL for each region of non-meta system table
> Currently most system tables are one region table (only ACL table may become
> big). Choices 2 and 3 basically are the same.
> From implementation point of view, choices 2 and 3 are cleaner than choice 1
> (as we have already had 1 WAL for META table and we can reuse the logic).
> With choice 2 or 3, assignment manager performance should not be impacted and
> it would be easier for assignment manager to assign system table region (eg.
> without waiting for user table log split to complete for assigning system
> table region).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
