Description:
When restoring backup data into a table where only the primary key definition has changed ndb_restore fails with:
Permanent: 4234: Illegal to call setValue in this state
Segmentation fault (core dumped)
Stack backtrace for the crash is
#0 0x00000000004a048c in NdbError::operator ndberror_struct (this=0x28) at ../../../../storage/ndb/include/ndbapi/NdbError.hpp:240
#1 0x00000000004a02a1 in update (_err=@0x28) at Ndberr.cpp:31
#2 0x00000000004a038d in NdbTransaction::getNdbError (this=0x0) at Ndberr.cpp:61
#3 0x000000000047db8d in BackupRestore::tuple_a (this=0x17788eb0, cb=0x177eae58) at restore/consumer_restore.cpp:1713
#4 0x0000000000478445 in BackupRestore::tuple (this=0x17788eb0, tup=@0x7fff69ce2a68, fragmentId=0) at restore/consumer_restore.cpp:1561
#5 0x0000000000474287 in main (argc=1, argv=0x17788d68) at restore/restore_main.cpp:1323
How to repeat:
* Create a table as
CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`j` int(11) NOT NULL DEFAULT '0',
`msg` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=ndbcluster;
and fill in a few rows.
* start cluster backup
* set up fresh cluster
* now create the table as above, but with
PRIMARY KEY (`id`, `j`)
* restore the backup data with
ndb_restore -r --skip-table-check ...
Suggested fix:
1) do not crash, exit with error code gracefully
2) shouldn't such PK changes be ok as long as there are no PK duplicates?
Replication from the old to new table structure is possible without problems ...
Description: When restoring backup data into a table where only the primary key definition has changed ndb_restore fails with: Permanent: 4234: Illegal to call setValue in this state Segmentation fault (core dumped) Stack backtrace for the crash is #0 0x00000000004a048c in NdbError::operator ndberror_struct (this=0x28) at ../../../../storage/ndb/include/ndbapi/NdbError.hpp:240 #1 0x00000000004a02a1 in update (_err=@0x28) at Ndberr.cpp:31 #2 0x00000000004a038d in NdbTransaction::getNdbError (this=0x0) at Ndberr.cpp:61 #3 0x000000000047db8d in BackupRestore::tuple_a (this=0x17788eb0, cb=0x177eae58) at restore/consumer_restore.cpp:1713 #4 0x0000000000478445 in BackupRestore::tuple (this=0x17788eb0, tup=@0x7fff69ce2a68, fragmentId=0) at restore/consumer_restore.cpp:1561 #5 0x0000000000474287 in main (argc=1, argv=0x17788d68) at restore/restore_main.cpp:1323 How to repeat: * Create a table as CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `j` int(11) NOT NULL DEFAULT '0', `msg` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=ndbcluster; and fill in a few rows. * start cluster backup * set up fresh cluster * now create the table as above, but with PRIMARY KEY (`id`, `j`) * restore the backup data with ndb_restore -r --skip-table-check ... Suggested fix: 1) do not crash, exit with error code gracefully 2) shouldn't such PK changes be ok as long as there are no PK duplicates? Replication from the old to new table structure is possible without problems ...