[
https://issues.apache.org/jira/browse/HBASE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641087#comment-13641087
]
Enis Soztutar commented on HBASE-2231:
--------------------------------------
bq. Are these full paths in above or partials? Hopefully the latter (in case
hbase.rootdir gets moved).
Good point, I think they are absolute paths for now. I'll change that.
bq. Do we need this class, CompactionDescriptor?
I don't know, you tell me :) It was in the v4 patch, so I kept it. Let me get
rid of it, we can just use the PB object directly as you said.
bq. Is there enough to ensure that this is a compaction edit?
If METAFAMILY we call getCompaction() which does check the row, cf, and column.
If not just returns null. I was thinking of adding a new Type in KeyValue, smt
like Marker, so that we do not hack around METAFAMILY. wdyt, I can do a follow
up issue.
bq. createFlush Is this used?
It is not used after HBASE-7329. I should remove it. One thing we discussed
offline with Sergey was that, if WAL disabled or deferred, a RS that lost the
region, might still try to do a flush on entries that did not go into WAL. In
these case, we might be writing a file to the region after the we lost the
control of the region, but it should be fine since either:
(1) the entries in the flushed file went into WAL already, so we would just be
adding a redundant file to the region.
(2) the entries did not go into WAL, but will be flushed into the region. They
will or will not be immediately seen by the region, because the region might be
already open. They will be seen by subsequent region opens.
Both cases should be fine as far as i can tell though, because for (1), we rely
on idempotent edits, for (2) since wal is deferred/skipped these cases would be
semantically acceptable.
> Compaction events should be written to HLog
> -------------------------------------------
>
> Key: HBASE-2231
> URL: https://issues.apache.org/jira/browse/HBASE-2231
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Todd Lipcon
> Assignee: stack
> Priority: Blocker
> Labels: moved_from_0_20_5
> Fix For: 0.95.1
>
> Attachments: 2231-testcase-0.94.txt, 2231-testcase_v2.txt,
> 2231-testcase_v3.txt, 2231v2.txt, 2231v3.txt, 2231v4.txt,
> hbase-2231-testcase.txt, hbase-2231.txt, hbase-2231_v5.patch
>
>
> The sequence for a compaction should look like this:
> # Compact region to "new" files
> # Write a "Compacted Region" entry to the HLog
> # Delete "old" files
> This deals with a case where the RS has paused between step 1 and 2 and the
> regions have since been reassigned.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
