[jira] [Resolved] (KUDU-2763) Confusing "log matching property violated" message on new tablets

["Adar Dembo (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adar Dembo resolved KUDU-2763.
------------------------------
       Resolution: Fixed
    Fix Version/s: 1.10.0

Fixed in commit 39a598741.

> Confusing "log matching property violated" message on new tablets
> -----------------------------------------------------------------
>
>                 Key: KUDU-2763
>                 URL: https://issues.apache.org/jira/browse/KUDU-2763
>             Project: Kudu
>          Issue Type: Bug
>          Components: consensus, supportability
>            Reporter: Todd Lipcon
>            Assignee: Mitch Barnett
>            Priority: Major
>              Labels: newbie
>             Fix For: 1.10.0
>
>
> I've seen several operators get confused by the following log message:
> {code}
> I0404 04:31:48.351042 27049 raft_consensus.cc:1053] T ec01a78d890847fa9a7e2c684caf89e3 P 50d64a444f1b409fa69c9566f3913a9c [term 1 FOLLOWER]: Refusing update from remote peer 48ca5ed87b034141a600a21b845a8ad3: Log matching property violated. Preceding OpId in replica: term: 0 index: 0. Preceding OpId from leader: term: 1 index: 1. (index mismatch)
> {code}
> This happens on every new tablet, since for whatever reason, the first leader sends its first message with "preceding opid" set to 1.1 instead of 0.0. We could special case this situation and not log it in the replica, but we could also try to get the initial leader to send with preceding_opid=0.0 and avoid an extra consensus round before a new tablet becomes writable. Likely just silencing the log is less risky, since the cost of the extra round is negligible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)