Comment 6 for bug 1180802

"

Except that in (c) you can also have a situation when 194045 trx also made it into InnoDB. And this is more likely, since a missing trx may be not noticed in a while (not 100% sure about sysbench, but its transactions seem pretty independent), whereas a duplicate trx would be hit immediately with certainty. So I'd speculate that here 145045 seqno didn't make it into InnoDB but the transaction did.

"

But, in the case where seqno didn't make into logs but
transaction did, won't it fail with 1062 than with 1032?

"
As for the question, I'm not the one to answer. But I will ;). I don't think there is any "interaction", at least by design. I think a more important question is how InnoDB tablespace is recovered. Does it honour the logs and is it rolled back properly?"
"

I will have a look at the wsrep_recover code, but it should be
fine (since InnoDB recovery is idempotent).

"
Seems like we fail on 281001 again here. If I hack the grastate to start at 281002, it does indeed restart right.
"

Is it always off by 1? If so, then it looks like a bug in
calculation of log co-ordinates.

Also, does/can wsrep_recovery advance the log by one? If yes,
then that may need to be considered.

Also, I have been looking at trx_prepare_off_kernel in view of
another bug - https://bugs.launchpad.net/percona-server/+bug/1092593

+ trx_sys_update_mysql_binlog_offset(
126 + sys_header,
127 + trx->mysql_relay_log_file_name,
128 + trx->mysql_relay_log_pos,
129 + TRX_SYS_MYSQL_RELAY_LOG_INFO, &mtr);
130 +
131 + trx_sys_update_mysql_binlog_offset(
132 + sys_header,
133 + trx->mysql_master_log_file_name,
134 + trx->mysql_master_log_pos,
135 + TRX_SYS_MYSQL_MASTER_LOG_INFO, &mtr);
136 +

This may needed for TRX_SYS_WSREP_XID_INFO as well.