wsrep_recover position unexpectedly gets RBR error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC |
Fix Released
|
High
|
Raghavendra D Prabhu |
Bug Description
Scenario:
-- 3 node cluster, latest PXC, running sysbench on node1
-- killall -9 mysqld on node3, restart
node3 gets recovery position, does IST and promptly gets RBR error:
130516 9:36:25 [Note] Event Scheduler: Loaded 0 events
130516 9:36:25 [Note] WSREP: Signalling provider to continue.
130516 9:36:25 [Note] WSREP: SST received: ecec24ed-
130516 9:36:25 [Note] WSREP: Receiving IST: 259 writesets, seqnos 194044-194303
130516 9:36:25 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.30' socket: '/var/lib/
130516 9:36:25 [ERROR] Slave SQL: Could not execute Delete_rows event on table test.sbtest1; Can't find record in 'sbtest1', Error_code: 1032; handler error HA_ERR_
130516 9:36:25 [Warning] WSREP: RBR event 4 Delete_rows apply warning: 120, 194045
130516 9:36:25 [ERROR] WSREP: receiving IST failed, node restart required: Failed to apply app buffer: seqno: 194045, status: WSREP_FATAL
at galera/
at galera/
130516 9:36:25 [Note] WSREP: Closing send monitor...
130516 9:36:25 [Note] WSREP: Closed send monitor.
130516 9:36:25 [Note] WSREP: gcomm: terminating thread
130516 9:36:25 [Note] WSREP: gcomm: joining thread
130516 9:36:25 [Note] WSREP: gcomm: closing backend
130516 9:36:26 [Note] WSREP: view(view_
981d5954-
} joined {
} left {
} partitioned {
0807cf68-
eab9e1dc-
})
130516 9:36:26 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
130516 9:36:26 [Note] WSREP: view((empty))
130516 9:36:26 [Note] WSREP: gcomm: closed
130516 9:36:26 [Note] WSREP: Flow-control interval: [16, 16]
130516 9:36:26 [Note] WSREP: Received NON-PRIMARY.
130516 9:36:26 [Note] WSREP: Shifting JOINER -> OPEN (TO: 194339)
130516 9:36:26 [Note] WSREP: Received self-leave message.
130516 9:36:26 [Note] WSREP: Flow-control interval: [0, 0]
130516 9:36:26 [Note] WSREP: Received SELF-LEAVE. Closing connection.
130516 9:36:26 [Note] WSREP: Shifting OPEN -> CLOSED (TO: 194339)
130516 9:36:26 [Note] WSREP: RECV thread exiting 0: Success
130516 9:36:26 [Note] WSREP: recv_thread() joined.
130516 9:36:26 [Note] WSREP: Closing slave action queue.
130516 9:36:26 [Note] WSREP: /usr/sbin/mysqld: Terminated.
130516 09:36:26 mysqld_safe Number of processes running now: 0
130516 09:36:26 mysqld_safe WSREP: not restarting wsrep node automatically
Is this a regression in recovery? I can reproduce this in multiple environments
Changed in percona-xtradb-cluster: | |
milestone: | none → 5.5.31-24.8 |
Changed in percona-xtradb-cluster: | |
status: | In Progress → Fix Committed |
Changed in percona-xtradb-cluster: | |
status: | Fix Committed → Fix Released |
Jay,
1) what is innodb_doublewrite setting in your cluster?
2) this is an InnoDB-related thing, so it would be great if you could reproduce it with Codership's binaries.