[
https://issues.apache.org/jira/browse/HBASE-17290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218709#comment-16218709
]
Anoop Sam John commented on HBASE-17290:
----------------------------------------
Sorry for asking it too late.
When write marker cell in WAL is failed, do we succed the bulk load op still?
On the new CP, we use post commit hook of store file. So this will be called
for all files including the flushed ones right. So when this CP is in place,
how will we treat diff btw bulk loaded files and normal flushed/compaction
result files?
The CP seems to listen for the post commit hook and then add an entry into the
hfiles for replication Q. I wonder why we cannot do this in core code flow
itself. WHy we need an extra CP? This is not a sync HFile replication op. Just
adding an entry. Said that even the WAL write also can be avoided?
Really sorry for asking this late after its commit. Got to see this code while
doing the recent CP cleanups only.
> Potential loss of data for replication of bulk loaded hfiles
> ------------------------------------------------------------
>
> Key: HBASE-17290
> URL: https://issues.apache.org/jira/browse/HBASE-17290
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.3.0
> Reporter: Ted Yu
> Assignee: Ashish Singhi
> Labels: replication
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17290.branch-1.patch, HBASE-17290.patch,
> HBASE-17290.v1.patch
>
>
> Currently the support for replication of bulk loaded hfiles relies on bulk
> load marker written in the WAL.
> The move of bulk loaded hfile(s) (into region directory) may succeed but the
> write of bulk load marker may fail.
> This means that although bulk loaded hfile is being served in source cluster,
> the replication wouldn't happen.
> Normally operator is supposed to retry the bulk load. But relying on human
> retry is not robust solution.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
