| Bug #65429 | Assertion failure block->page.space == page_get_space_id(page_align(ptr)) | ||
|---|---|---|---|
| Submitted: | 26 May 2012 14:51 | Modified: | 23 Apr 2015 11:32 |
| Reporter: | Elena Stepanova | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
| Version: | 5.5, 5.6 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[26 May 2012 14:51]
Elena Stepanova
[26 May 2012 16:12]
Valeriy Kravchuk
Thank you for the bug report. Verified with 5.5.26 on Mac OS X using your test case: ... 120526 19:10:17 [Note] /Users/openxs/dbs/5.5/bin/mysqld: ready for connections. Version: '5.5.26-debug-log' socket: '/Users/openxs/dbs/5.5/mysql-test/var/tmp/mysqld.1.sock' port: 13000 Source distribution 120526 19:10:18 InnoDB: Error: InnoDB: MySQL is trying to use a table handle but the .ibd file for InnoDB: table test/t1 does not exist. InnoDB: Have you deleted the .ibd file from the database directory under InnoDB: the MySQL datadir, or have you used DISCARD TABLESPACE? InnoDB: Look from InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html InnoDB: how you can resolve the problem. 120526 19:10:18 InnoDB: Assertion failure in thread 4380418048 in file buf0buf.c line 2080 InnoDB: Failing assertion: block->page.space == page_get_space_id(page_align(ptr)) ...
[25 Jun 2012 1:33]
Stewart Smith
I think this should be marked as Not a Bug. Quoting from manual ( http://dev.mysql.com/doc/mysql-enterprise-backup/3.5/en/partial.restoring.single.html ): If you have a *clean* backup of an .ibd file, you can restore it to the MySQL installation from which it originated as follows: In this context, a clean.ibd file backup means: There are no uncommitted modifications by transactions in the .ibd file. There are no unmerged insert buffer entries in the .ibd file. Purge has removed all delete-marked index records from the .ibd file. mysqld has flushed all modified pages of the .ibd file from the buffer pool to the file. You can make such a clean backup .ibd file with the following method: Stop all activity from the mysqld server and commit all transactions. Wait until SHOW INNODB STATUS shows that there are no active transactions in the database, and the main thread status of InnoDB is Waiting for server activity. Then you can make a copy of the .ibd file. Another method for making a clean copy of an .ibd file is to use ibbackup: Use ibbackup to back up the InnoDB installation. Run ibbackup --apply-log to create a consistent version of the backup database. Start a second (dummy) mysqld server on the backup and let it clean up the .ibd files in the backup. Wait for the cleanup to end. Shut down the dummy mysqld server. Take a clean .ibd file from the backup.
[25 Jun 2012 2:35]
Elena Stepanova
I agree that the test case does not demonstrate good practice, so it would be totally fine if the import failed. However, I would expect that a non-debug server should be able to do better than abort on an attempt to import a wrongly created ibd backup, as it happens now (especially considering that the first method of taking a backup is error-prone, as on a real-world server something might always happen between running SHOW INNODB STATUS and copying the file, and the second method is cumbersome and rather expensive). Nevertheless, if you think it's fine for the server to shutdown in this situation, please feel free to close the report.
