[MDEV-12023] Assertion failure sym_node->table != NULL on startup Created: 2017-02-08 Updated: 2020-08-25 Resolved: 2018-10-30 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Storage Engine - XtraDB |
| Affects Version/s: | 10.0, 10.1, 10.2, 10.3 |
| Fix Version/s: | 10.0.37, 10.3.11, 10.1.37, 10.2.19 |
| Type: | Bug | Priority: | Major |
| Reporter: | Andrii Nikitin (Inactive) | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Attachments: |
1.sh.err
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
When I use .sh test from https://bugs.launchpad.net/percona-xtrabackup/+bug/1399471 and ignore_builtin_innodb
I couldn't reproduce the same with manual testing nor with 'identical' mtr tests (which i run with "-
Thus I am still filing this bug to let developer review if XtraDB patches from https://bugs.launchpad.net/percona-xtrabackup/+bug/1399471 should be applied to ha_innodb as well. |
| Comments |
| Comment by Vladislav Vaintroub [ 2017-09-12 ] | |||||||||||||||||||||||||||||||||||||||
|
anikitin "to let developer review if XtraDB patches from https://bugs.launchpad.net/percona-xtrabackup/+bug/1399471 should be applied to ha_innodb as well". we will not apply xtrabackup patches to innodb_plugin, this won't happen. The xtrabackup recovery will always be done with single version of innodb (i.e mariadb's version xtradb in 10.1, and marias version of innodb in 10..2+) marko, can you take a shot on what seems to be a recovery bug? | |||||||||||||||||||||||||||||||||||||||
| Comment by Andrii Nikitin (Inactive) [ 2017-09-12 ] | |||||||||||||||||||||||||||||||||||||||
|
I can't reproduce it anymore in 10.1 , so reassigning to myself and probably will just close after reviewing once again. | |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2017-09-12 ] | |||||||||||||||||||||||||||||||||||||||
|
wlad, for what it is worth, the InnoDB in MariaDB before 10.2.2 and MySQL before 5.7 treats temporary tables mostly like persistent tables. This is a strange failure that could affect also the MariaDB server prior to 10.2. In row_mysql_drop_temp_tables() there is this check for table!=NULL:
It seems to me that the sym_node->table that is NULL in pars_update_statement() is referring to a data dictionary table, not to the user table. The statement in the InnoDB internal SQL in row_drop_table_for_mysql() should be one of SYS_FOREIGN, SYS_FOREIGN_COLS, SYS_TABLESPACES, SYS_DATAFILES. The other dictionary tables (SYS_TABLES, SYS_COLUMNS, SYS_INDEXES, SYS_FIELDS) are hard-coded, so those tables can never be missing. I do not think that there have been any fixes in this area. I wonder how this could happen. I have two guesses:
| |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2017-09-13 ] | |||||||||||||||||||||||||||||||||||||||
|
I had a look at the Percona bug and patches today. Indeed, the reported problem occurred when preparing a backup of a 5.5 database, which would lack the SYS_TABLESPACES and SYS_DATAFILES tables. The fix would avoid the ‘dictionary table does not exist’ error by using a different InnoDB SQL concept. The fix is unnecessarily avoiding access to the hard-coded SYS_INDEXES table. Unlike Mariabackup, Percona XtraBackup aims to support multiple database versions. Mariabackup only supports the major server version that it was packaged with. Starting with Mariabackup 10.2, that is actually enforced by the redo log format identifier. Without this bug, Mariabackup 10.1 should work with 5.5 datafiles. It would seem to make some sense to port the fix to 10.1 (XtraDB and Mariabackup, not necessarily InnoDB). | |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2018-10-26 ] | |||||||||||||||||||||||||||||||||||||||
|
A similar crash is possible in InnoDB startup at least since MariaDB Server 10.0. Here is an error log excerpt:
| |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2018-10-29 ] | |||||||||||||||||||||||||||||||||||||||
|
Starting with | |||||||||||||||||||||||||||||||||||||||
| Comment by Thirunarayanan Balathandayuthapani [ 2018-10-29 ] | |||||||||||||||||||||||||||||||||||||||
|
Test case in 10.1:
The above test case should be executed in 10.1. Move the data directory to 10.2 and start the server with default configuration.
The problem is that In 10.1, there is no sys_virtual table. In 10.2, "dict_create_or_check_sys_virtual()" is called after "recv_recovery_rollback_active()". The following patch solves the issue:
| |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2018-10-30 ] | |||||||||||||||||||||||||||||||||||||||
|
The problem is that row_drop_table_for_mysql() assumes that all the InnoDB data dictionary tables exist. On upgrade, that may not be the case. The table SYS_VIRTUAL was introduced in MariaDB Server 10.2 (and MySQL 5.7), Also the tables SYS_FOREIGN, SYS_FOREIGN_COLS were not created in the very first published InnoDB version, but only starting with MySQL 3.23.44. Orphan tables would be dropped before CREATE TABLE IF NOT EXISTS on these dictionary tables is performed. Therefore, when dropping a table, we must allow any of these non-core dictionary tables to be missing. | |||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2018-10-30 ] | |||||||||||||||||||||||||||||||||||||||
|
I ported this also to bb-10.2-compatibility. |