[
https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257919#comment-16257919
]
Josh Elser commented on HBASE-17852:
------------------------------------
bq. This is going to confuse. 'system' tables have a particular meaning in
hbase.
Should be easy enough to rename with your IDE of choice, right Vlad? Avoiding
overloading terminology is always a good idea. "BackupMetadata" and
"BackupBulkLoadFiles"? (just pitching ideas)
bq. The snapshot/restore of a whole system table strikes me as a bunch of
moving parts. I have to ask why we got such an extreme? 2PC is tough-enough w/o
offlining/restore of whole meta table. During restore, all clients are frozen
out or something so they can't pollute the restored version? Restore is not
atomic, right? We couldn't have something like a row-per-backup with a success
tag if all went well (I've not been following closely – pardon all the
questions).
Stack, are you essentially asking why this isn't implemented on top of ProcV2?
I'm trying to read between the lines but am not sure if I'm inventing something
that isn't there. There are definitely areas of the code in which the
acknowledgement has already been made about a better implementation can be
done. For example, clients _are_ "frozen out" right now from concurrent
operations (a nod that backups, merges, and restores could be done
concurrently). I think at this point, it would be more productive if we can say
more "there is something implicitly broken with this approach" instead of
"there is a more elegant implementation to be had". I don't think anyone is
arguing against that.
Yes, rolling back the entire backup "system" table is overkill (for what may
sometimes be deleting a single row/column -- the ACTIVE_SNAPSHOT as mentioned
in the parent) and would take much longer that it could necessarily need to.
bq. You suggest I review code. I have been reviewing code. Thats how we got
here.
And thank you for that. I know your intentions are good. We're all ultimately
working towards a common goal here.
bq. Sure, you can start from very beginning, Stack. Go ahead.
This isn't helpful and, likely, directly harmful :\
> Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental
> backup)
> ------------------------------------------------------------------------------------
>
> Key: HBASE-17852
> URL: https://issues.apache.org/jira/browse/HBASE-17852
> Project: HBase
> Issue Type: Sub-task
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch,
> HBASE-17852-v3.patch, HBASE-17852-v4.patch, HBASE-17852-v5.patch,
> HBASE-17852-v6.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
