[
https://issues.apache.org/jira/browse/PHOENIX-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989143#comment-16989143
]
Hadoop QA commented on PHOENIX-5604:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12987633/PHOENIX-5604-4.x-HBase-1.5.patch
against 4.x-HBase-1.5 branch at commit
08ed7027da64d47b8ed4ed43ac47d94983d14d41.
ATTACHMENT ID: 12987633
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3169//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3169//console
This message is automatically generated.
> Index rebuilds and read repairs should not skip WAL
> ---------------------------------------------------
>
> Key: PHOENIX-5604
> URL: https://issues.apache.org/jira/browse/PHOENIX-5604
> Project: Phoenix
> Issue Type: Bug
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
> Attachments: PHOENIX-5604-4.x-HBase-1.5.patch
>
>
> Currently both Index read repairs and IndexTool build/rebuilds in the new
> design continue to skip the WAL, following the same pattern the old Indexer
> used. However, there are key differences between the old and new logic that
> make this no longer the correct choice.
> First, recall that all HBase replication is based on tailing the WAL, and
> that any transaction that skips the WAL doesn't get replicated.
> In the old logic, the data table write (and WAL append) would be accompanied
> by an IndexedKeyValue which would contain enough information to reconstitute
> the index edit in the event of a failure before the index edit could be
> committed. So skipping the WAL during recovery was _potentially_ OK, because
> writing to the WAL would be redundant locally. (But that still seems to me
> wrong in a case with replication, since I don't believe IndexedKeyValues are
> replicated, since they use the "magic" METAFAMILY cf.)
> In the new logic, on a normal write, we write to the index first (which will
> go into a WAL), then the data table (into a potentially different RS's WAL),
> and lastly the verified flag flip into the Index, into the original index
> write's WAL. If something goes wrong with stage 2 or 3, read repair will fix
> it, but if the repair action – whether a put or delete – doesn't go into the
> WAL, a DR buddy of the index will be out of sync.
> This is even more important on an async initial build of an index, where if I
> understand right, there is no WAL append for the index write at all in the
> current UngroupedAggregateRegionObserver rebuild logic. The same would be the
> case of a rebuild of a new-style index in the event of non-Phoenix related
> corruption (such as HDFS or raw HBase level).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
