My mysql version is 8.0.11, xtrabackup version is the latest version, I am using the backup to restore the cfg and ibd files to import the tablespace, my mysql is down directly, I compared the cfg generated by the export command of xtrabackup, and the cfg generated by mysql flush tables is inconsistent, the cfg file generated by xtrabackup does not have DI, DE and other descriptions, This is a version incompatible bug.,Can anyone help me?,I’m anxious.
Hi @javaPope
Would you consider sharing more details? What command do you use? What’s the source version of the ibd?
Thanks,
K
I placed MySQL and xtrabackup in two separate containers, and then performed a full backup using xtrabackup --backup --target-dir=/home/data. Subsequently, I generated the cfg file and ibd file by running xtrabackup --prepare --export --target-dir=/home/data.
After that, I simulated an accidental deletion by executing drop table fund; in the MySQL database named db. Then, I recreated the fund table using the previously saved table creation statement. Following that, I executed alter table fund discard tablespace; to discard the tablespace.
Afterwards, I copied the exported ibd and cfg files to the specified data directory and changed the ownership of the files to the mysql user and group. However, when I tried to execute alter table fund import tablespace, my MySQL container crashed directly.
There are mysql error log:
06:04:04 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=4
max_threads=151
thread_count=2
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 67841 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f7808014290
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 7f78647a0d80 thread_stack 0x46000
/usr/local/mysql/bin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x2e) [0x19fcc8e]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x413) [0xccc863]
/lib64/libpthread.so.0(+0xf630) [0x7f787a0de630]
/lib64/libc.so.6(_IO_vfprintf+0x4a79) [0x7f7878487079]
/lib64/libc.so.6(vasprintf+0xa3) [0x7f78784b1de3]
/usr/local/mysql/bin/mysqld(ib_senderrf(THD*, ib_log_level_t, unsigned int, …)+0xbe) [0x1b4cbce]
/usr/local/mysql/bin/mysqld(ib_errf(THD*, ib_log_level_t, unsigned int, char const*, …)+0xcc) [0x1b4cd9c]
/usr/local/mysql/bin/mysqld(row_import_for_mysql(dict_table_t*, dd::Table*, row_prebuilt_t*)+0xd42) [0x1c562e2]
/usr/local/mysql/bin/mysqld(ha_innobase::discard_or_import_tablespace(bool, dd::Table*)+0x442) [0x1b694d2]
/usr/local/mysql/bin/mysqld(Sql_cmd_discard_import_tablespace::mysql_discard_or_import_tablespace(THD*, TABLE_LIST*)+0x1b9) [0xc376a9]
/usr/local/mysql/bin/mysqld(mysql_execute_command(THD*, bool)+0x186f) [0xbcbf2f]
/usr/local/mysql/bin/mysqld(mysql_parse(THD*, Parser_state*)+0x30f) [0xbd040f]
/usr/local/mysql/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x26ca) [0xbd2d3a]
/usr/local/mysql/bin/mysqld(do_command(THD*)+0x179) [0xbd3be9]
/usr/local/mysql/bin/mysqld() [0xcbfd80]
/usr/local/mysql/bin/mysqld() [0x1aa5f5f]
/lib64/libpthread.so.0(+0x7ea5) [0x7f787a0d6ea5]
/lib64/libc.so.6(clone+0x6d) [0x7f78785388dd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f7808cb1558): is an invalid pointer
Connection ID (thread ID): 13
Status: NOT_KILLED
this is xtrabackup info:
[MY-011825] [Xtrabackup] recognized server arguments: --datadir=/usr/local/mysql/data --log_bin=/usr/local/mysql/data/mysql-bin --tmpdir=/usr/local/mysql --innodb_file_per_table=1
xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 6beb4b49)
this is mysql info:
mysql Ver 8.0.11 for linux-glibc2.12 on x86_64 (MySQL Community Server - GPL)
You mean following is the sequence of events:
- you have xbackup of the first container
- prepared with “–export”
- used the same exported files to import
- alter table import tablespace
- crash
Due to the relatively small amount of data in the fund table, when I directly import the .ibd file exported by xtrabackup using the import tablespace command, it succeeds. However, if I attempt to import the tablespace using both the .cfg and .ibd files, it fails.
Yes, so I’m quite helpless now. I’m not sure if the latest version of xtrabackup is compatible with MySQL 8.0.11.
I’m quoting from the documentation:
Due to changes in MySQL 8.0.20 released by Oracle at the end of April 2020, Percona XtraBackup 8.0, up to version 8.0.11, is not compatible with MySQL version 8.0.20 or higher
But my MySQL version is 8.0.11, and the xtrabackup version is 8.0.35. xtrabackup should be compatible with MySQL 8.0 versions downwards, right?
Do you mean that XtraBackuo 8.0.35 is not compitable with Mysql 8.0.11?
What I know is there are “changes” at 8.0.20. I have never used xtrabackup >8.0.20 for mysql <8.0.20. What you’re asking me right now will need me to test (I can get back to you later on this). From documentation, if I have to speculate, reverse compatibility crossing 8.0.20 might not be supported.
Thanks,
K
Sir, how is your testing going? Is the latest version of xtrabackup compatible with MySQL 8.0.11?