[ 
https://issues.apache.org/jira/browse/KUDU-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17799888#comment-17799888
 ] 

ASF subversion and git services commented on KUDU-3534:
-------------------------------------------------------

Commit 1f6f7e5bafb6a9f497ea92b62c1f268a2fe6c3c3 in kudu's branch 
refs/heads/master from Ashwani Raina
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=1f6f7e5ba ]

KUDU-3534 [compaction] Log timestamp of two matching DELETE REDO mutations.

This patch just adds an info message to log timestamp value in case
two REDO mutations of type DELETE are found to be stamped with same
time. This is an undesired condition that could possibly happen
due to corruption of mutation entries. The value will give us an
idea whether it is 0, garbled or close to some valid timestamp.

Change-Id: I508254a83046818b81db4577bf07265b46a13c9a
Reviewed-on: http://gerrit.cloudera.org:8080/20792
Reviewed-by: Abhishek Chennaka <[email protected]>
Tested-by: Abhishek Chennaka <[email protected]>
Reviewed-by: Wang Xixu <[email protected]>
Reviewed-by: Alexey Serbin <[email protected]>


> Corrupt timestamps crash the server
> -----------------------------------
>
>                 Key: KUDU-3534
>                 URL: https://issues.apache.org/jira/browse/KUDU-3534
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: Abhishek Chennaka
>            Priority: Minor
>
> Came across a situation where the tablet server was crashing with the below 
> log messages:
> {code:java}
> I1204 03:42:13.302340 124627 maintenance_manager.cc:382] P 
> 035c5ff8ec2f4f71878f96adb9632c3c: Scheduling 
> CompactRowSetsOp(886eddb2ccca466995e400c62c1b1197): perf score=0.561641
> ..
> F1204 03:42:20.046682 124484 compaction.cc:465] Check failed: 0 != ret (0 vs. 
> 0) {code}
> The reason behind is that there were two separate delete ops with the same 
> exact hybrid stamp which is not ideally possible. This was noticed across 
> multiple replicas in the same server so most likely it is a server specific 
> issue (probably disk related) while the same replicas in other servers did 
> not thrown an issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to