You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After Openstack MariaDB got corrupted, I tried with these script to recover the still existing ibd Files with a sqldump from a fresh Openstack Kolla-Ansible Deploy
when upgrading a kolla-ansible powered OpenStack Environment from a single node mariadb to a Galera Cluster, the database gots somehow corrupted (I'm no database expert). All nodes were corrupted or not even running. (Yes, there wasn't a backup) This led finally to the challenge, to recover the database from the still existing ibd-Files
modern MySQL/MariaDB distributions with InnoDB does allow import of Tables from ibd-Files. It's recommended to also import the associated cfg-File of each table which doesn't exist in my case
without these cfg-Files an error will be raised Internal error: Drop all secondary indexes before importing table <tablename> when .cfg file is missing and this leads to my approach to seperate the primary index statements from the secondary indexes and add them after the Tablespace gets imported successfully
Approach
Create SQL Dump of a working fresh opensstack mariadb and store it for later:
mysqldump -A --compact -f -u root -p > sql_dump.sql
Import the environment of a fresh openstack mariadb (in my case Xena) into a location like /var/lib/mysql
Remove all created openstack relevant stuff in the database:
When creating the "clean" CREATE TABLE syntax (the "create" Python command) you must leave the PRIMARY KEY declaration in the output file if there's an AUTO_INCREMENT column, otherwise the reimport of the IBD file won't work (*);
To fix the Expected FSP_SPACE_FLAGS=0x15 you must use the same MySql version of the server from which the IBD files come from.
Thanks a lot for your code!
(*) I tried using a source server MySql is 10.1.45, and a destination server version 11.8.3. I first tried reimporting IBD data on the new instance where full CREATE TABLE syntax was used (with KEYS/INDEXes). When reimporting the IBD file on the 11.8.3 server, it gave me a clear error message saying to remove the KEY/INDEXes from the table. This same operation done on another clean 10.1.45 instance, instead, would simply crash MySql.
I have two quick notes to get past your error,
Thanks a lot for your code!
(*) I tried using a source server MySql is 10.1.45, and a destination server version 11.8.3. I first tried reimporting IBD data on the new instance where full CREATE TABLE syntax was used (with KEYS/INDEXes). When reimporting the IBD file on the 11.8.3 server, it gave me a clear error message saying to remove the KEY/INDEXes from the table. This same operation done on another clean 10.1.45 instance, instead, would simply crash MySql.