pt-online-schema-change fails when table is empty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Fix Released
|
Medium
|
Daniel Nichter | ||
2.0 |
Won't Fix
|
Undecided
|
Unassigned | ||
2.1 |
Fix Released
|
Medium
|
Daniel Nichter |
Bug Description
When issuing
pt-online-
where the table does not contain a single row, pt-online-
Altering `database`
Creating new table...
Created new table database._table_new OK.
Altering new table...
Altered `database`
Creating triggers...
Created triggers OK.
Copying approximately 4686227 rows...
Dropping triggers...
Dropped triggers OK.
Dropping new table...
Dropped new table OK.
`database`.`table` was not altered.
Error copying rows from `database`.`table` to `database`
I think this is due to the fact that XtraDB stores an approximate number of rows per table somewhere but this information is not beeing updated live. I had this issue with a couple of tables, in all of them i deleted all rows prior to executing the above pt-online-
A temporary "fix" is to insert one row in those tables, running pt-online-
After doing this pt-online-
I'm using
mysqld Ver 5.1.59-rel13.0-log for debian-linux-gnu on x86_64 ((Percona Server (GPL), 13.0, Revision 325))
pt-online-
Related branches
- Daniel Nichter: Approve
-
Diff: 136 lines (+29/-11)3 files modifiedbin/pt-online-schema-change (+15/-2)
lib/NibbleIterator.pm (+5/-0)
t/lib/NibbleIterator.t (+9/-9)
tags: | added: crash empty-table pt-online-schema-change |
Changed in percona-toolkit: | |
milestone: | none → 2.1.3 |
status: | New → Triaged |
Changed in percona-toolkit: | |
importance: | Undecided → Medium |
Changed in percona-toolkit: | |
assignee: | nobody → Daniel Nichter (daniel-nichter) |
status: | Triaged → In Progress |
I tested with pt-osc 2.1.2 and mysql 5.1.63-rel13.4 Percona Server (GPL), 13.4, Revision 443, but couldn't reproduce it it. (tested with full table, and then truncated and tested with both, even with innodb_ stats_auto_ update = OFF).
However, from what I checked in the code, you should be able to alleviate this --nocheck-plan for those tables.