WSREP reporting conflict state 7 after post commit

[Marco Tusa]

In an architecture having Cluster1 and Cluster2 Geographically distributed.
Having C1Node1 Master of C2Node1, and C2Node1 Master of C1Node (so master master config).

After a real conflict on C2Node1

Note] WSREP: cluster conflict due to high priority abort for threads:
140418 10:46:04 [Note] WSREP: Winning thread:
   THD: 21, mode: applier, state: executing, conflict: no conflict, seqno: 327797628
   SQL: (null)
140418 10:46:04 [Note] WSREP: Victim thread:
   THD: 4, mode: local, state: executing, conflict: cert failure, seqno: -1
   SQL: (null)
140418 10:46:04 [Note] WSREP: BF kill (1, seqno: 327797628), victim: (4) trx: 837775944
140418 10:46:04 [Note] WSREP: Aborting query: void
140418 10:46:04 [Note] WSREP: victim 837775944 in state 7
140418 10:46:04 [Warning] Slave SQL: Could not execute Write_rows event on table phl_joomla3.search_responses; Duplicate entry '1109427182' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 138968194, Error_code: 1062
140418 10:46:04 [Warning] WSREP: thd 4 seqno 327797637: conflict state 7 after post commit
140418 10:46:04 [Warning] WSREP: thd 4 seqno 327797640: conflict state 7 after post commit
140418 10:46:04 [Warning] Slave SQL: Could not execute Write_rows event on table phl_joomla3.search_responses; Duplicate entry '1109427188' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 138969383, Error_code: 1062

WSREP continue to report :
[Warning] WSREP: thd 4 seqno 335847121: conflict state 7 after post commit

For ever.

To stop the message Slave SQL thread must be stop/start.

Message comes from wsrep_hton.cc
line 470 -497
...
  if (thd->wsrep_conflict_state != NO_CONFLICT)
    {
      WSREP_WARN("thd %lu seqno %lld: conflict state %d after post commit",
                 thd->thread_id,
                 (long long)thd->wsrep_trx_seqno,
                 thd->wsrep_conflict_state);
    }
...

In short it seems that the status wsrep_conflict_state once set is not correctly change after resolution of the conflict.

I had a chat with Teemu and he asked me to open the bug report.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1000