[
https://issues.apache.org/jira/browse/HBASE-13877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584407#comment-14584407
]
stack commented on HBASE-13877:
-------------------------------
@enis That part of the change that dumps out 2 or less is good for reasons you
say (else job fails).
I was just commenting that when the job finishes and dumps summary on console,
stuff is cut off. Here is example:
{code}
Found
CELL_WITH_MISSING_ROW=1917348
S\x99\xE1\xF9\x00\xD3\xEE\xEE\xC6\x8E\x87\xAA\x87\xFEX\xFF_in_h=1
T\x8Ec\xAB^\x89_O\xA3=\x8Asd'5~_in_hdfs://c2020.halxg.cloudera.=1
YB\xEC\xC4\xA3\x9C\xE4\x0FD\xB4`\xFFgs\x0C3_in_hdfs://c2020.hal=1
Y\x98\x8A\x855\x13\xD0i\x97\x1D\x84"G\xC7\x16m_in_hdfs://c2020.=1
\xE3\xEA\xB0n[\xDB\xE0GT_\x08wfIa)_in_hdfs://c2020.halxg.cloude=1
\xEA\x96o\x94\xF4\xD5k\x80[\x0D\xE6\xA1\xABe\x1C\xC6_in_hdfs://=1
\xF1H#%Vx/m\x8E\x7F\x93\x11\xB4\x7FX\xD5_in_hdfs://c2020.halxg.=1
\xF4\x89\xDE\x92\x95#\xC9\xC9K\xDD\x94z\x0F\x17\xBB\xA1_in_hdfs=1
{code}
Was wondering if you saw something else?
> Interrupt to flush from TableFlushProcedure causes dataloss in ITBLL
> --------------------------------------------------------------------
>
> Key: HBASE-13877
> URL: https://issues.apache.org/jira/browse/HBASE-13877
> Project: HBase
> Issue Type: Bug
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.1.1
>
> Attachments: hbase-13877_v1.patch, hbase-13877_v2-branch-1.1.patch,
> hbase-13877_v2-to-v4-branch-1.1.patch, hbase-13877_v3-branch-1.1.patch
>
>
> ITBLL with 1.25B rows failed for me (and Stack as reported in
> https://issues.apache.org/jira/browse/HBASE-13811?focusedCommentId=14577834&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14577834)
>
> HBASE-13811 and HBASE-13853 fixed an issue with WAL edit filtering.
> The root cause this time seems to be different. It is due to procedure based
> flush interrupting the flush request in case the procedure is cancelled from
> an exception elsewhere. This leaves the memstore snapshot intact without
> aborting the server. The next flush, then flushes the previous memstore with
> the current seqId (as opposed to seqId from the memstore snapshot). This
> creates an hfile with larger seqId than what its contents are. Previous
> behavior in 0.98 and 1.0 (I believe) is that after flush prepare and
> interruption / exception will cause RS abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
