MySQL Bugs: #42773: Frm mismatch after restore due to auto discovery.

Bug #42773	Frm mismatch after restore due to auto discovery.
Submitted:	11 Feb 2009 20:07	Modified:	26 Mar 2009 15:30
Reporter:	Joshua Gordon
Status:	No Feedback
Category:	Server: Cluster	Severity:	S2 (Serious)
Version:	mysql-5.1-telco-6.3 (20)	OS:	Other (FC9)
Assigned to:	Hartmut Holzgraefe	Target Version:

Description:
After shuting down and restoring my cluster I get the following error.
090211  9:59:26 [Note] NDB: mismatch in frm for panel.gatewayquestions, discovering...
090211  9:59:26 [Note] NDB Binlog: DISCOVER TABLE Event: REPL$panel/gatewayquestions
090211  9:59:26 [Note] NDB Binlog: logging ./panel/gatewayquestions (UPDATED,USE_WRITE)
This is due to the files already being in the mysql data directory. After the error the
frm does not match the data in memory this causes the following.
When running select count(*) from tablename;
You will get an accurate count.
When running select * from table name; 
You get an error Can't find record in tablename.

How to repeat:
This may work.
Create a database and a ndb table.
Put some data in the table.
Run a backup.
Alter the table and remove some rows.
Shutdown the cluster.
Bring up the nbd_mgmd
Bring then start the ndbd --initial.
Restore the previous backup. 
When this is completed go into the mysql client and runn the following statements. 
select count(*) from tablename;
select * from tablename;

Suggested fix:
Remove Auto discovery.

I'd like to know you have ndb-use-exact-count set to on or off?

Also when restoring a cluster backup using ndb_restore you should be using SINGLE USER
MODE with the ndb_restore connection being the only one to access the cluster during the
restore ...

My config.ini

Attachment: config.ini (application/octet-stream, text), 1.75 KiB.

My.cnf

Attachment: my.cnf (application/octet-stream, text), 1.36 KiB.

I have attached my config files to clear up any config questions. I have not set any value
for ndb_use_exact_count. 
Single user mode only allows you to restore one file at a time and with my data set that
would take 12 to 16 Hours. That is unacceptable.

Please re-verify on latest.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".