The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-16. For the latest, interactive version please visit https://mariadb.com/kb/.

Failed to not validate first page of the file mysql/innodb_table_stats, error 42

Hi, Would it be possible to get some help?

# mariabackup --backup --user=root --password={password} --target-dir={backup_folder_path}
[00] 2020-11-30 09:42:23 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set
[00] 2020-11-30 09:42:23 Using server version 10.3.27-MariaDB-log
mariabackup based on MariaDB server 10.3.27-MariaDB Linux (x86_64)
[00] 2020-11-30 09:42:23 uses posix_fadvise().
[00] 2020-11-30 09:42:23 cd to /var/lib/mysql/
[00] 2020-11-30 09:42:23 open files limit requested 1024, set to 1024
[00] 2020-11-30 09:42:23 mariabackup: using the following InnoDB configuration:
[00] 2020-11-30 09:42:23 innodb_data_home_dir =
[00] 2020-11-30 09:42:23 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2020-11-30 09:42:23 innodb_log_group_home_dir = ./
[00] 2020-11-30 09:42:23 InnoDB: Using Linux native AIO
2020-11-30  9:42:23 0 [Note] InnoDB: Number of pools: 1
[00] 2020-11-30 09:42:23 mariabackup: Generating a list of tablespaces
2020-11-30  9:42:23 0 [Warning] InnoDB: Allocated tablespace ID 1 for {table_name}, old maximum was 0
2020-11-30  9:42:23 0 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace {table_name} at filepath: ./{table_name}.ibd uses space ID: 1. Cannot open filepath: ./mysql/innodb_table_stats.ibd which uses the same space ID.
[00] FATAL ERROR: 2020-11-30 09:42:23 Failed to not validate first page of the file mysql/innodb_table_stats, error 42

What should I do? Thanks for help.

Answer Answered by Daniel Black in this comment.

Have you done anything manually with the ibd or ibdata1 files? Like replacing them from another instance? This isn't supported and cannot be fixed. Was this a forced install over an previous instance?

How did your mariadb instance end up in this state? It seems like there's a significant back story and the mismatch between idb and ibdata1 seems to be a result of manual intervention. If you have the files from a previous consistent state then that might be recoverable.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.