Loss of records with LOAD DATA INFILE in 5.6 with autocommit=0 + wsrep-load-data-splitting=ON | Crashes with UNIV_DEBUG
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL patches by Codership | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Low
|
Seppo Jaakola | |||
5.6 |
Fix Released
|
Low
|
Seppo Jaakola | |||
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Undecided
|
Unassigned | |||
5.6 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
All,
I had the following issue at customer site.
We were using MySQL 5.6 PXC (but that apply also to other distributions)
See below for full variable report.
We have exported the data out from the original server and then try to import it in the MySQL/Galera cluster (PXC implementation) using LOAD INTO.
What happened is that the data seems to load fine, and that the "WSREP: forced trx split for LOAD" works fine, but unfortunately this is not true.
Here and there we start to get "[Warning] MySQL is closing a connection that has an active InnoDB transaction. 4007 row modifications will roll back."
Performing a quick comparison between source and destination, I identify that we were loosing records in the import process.
Checking the warning I found that it was coming from:
ha_innodb.cc line 4395
/*****
Frees a possible InnoDB trx object associated with the current THD.
@return 0 or error number */
static
int
innobase_
...
<snip>
if (trx_is_
sql_print_
"MySQL is closing a connection that has an active "
"InnoDB transaction. "TRX_ID_FMT" row modifications "
"will roll back.",
trx->undo_no);
}
}
innobase_
trx_free_
DBUG_RETURN(0);
}
<snip>
In short this function is call to clean up pending Innodb operation.
It also perform the roll back of the undo segment as for the undo_no.
Given that it was clear why we were loosing records on the way.
Next step was to identify WHY.
I was able to reproduce the same behaviour on PXC and also on MySQL/Galera (codership distribution), I have prepare a small package with a perl file and 2 files of data to test (see attachments).
Anyhow, what I identify is that issue is present on the following condition:
autocommit = 0;
wsrep_
If I push the autocomit=1; the load will complete successfully and all the records will be present.
Same if I disable wsrep_load_
So the issue seems related to how the split is managed inside the WSREP process, and probably to a missed call to innobase_commit in the function.
I tested it on 5.6 but not on 5.5.
summary: |
- Loss of records with LOAD INTO using trx split in 5.6 + Loss of records with LOAD DATA INFILE in 5.6 with autocommit=0 + wsrep- + load-data-splitting=ON | Crashes with UNIV_DEBUG |
Changed in codership-mysql: | |
assignee: | nobody → Seppo Jaakola (seppo-jaakola) |
status: | New → In Progress |
Changed in codership-mysql: | |
importance: | Undecided → Low |
milestone: | none → 5.6.16-25.3 |
Just tested on 5.5 no issue.
this problem is present only in 5.6