异常背景
之前一篇博客介绍到由于MySQLredo日志的调整导致xtrabackup备份失败的文章,参考https://www.cnblogs.com/zhenxing/p/xtrabackup_mysql80.html,这次我们尝试用xtrabackup 8.0.14来备份MySQL 8.0.22再次触发异常BUG,具体原因依旧是MySQL对redo做了进一步调整,导致备份失败
环境信息
- ./xtrabackup8 --version
- ./xtrabackup8 version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
- MySQL 8.0.22
报错信息
xtrabackup8 version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
xtrabackup: cd to /data/mysql/data/6630/urman-full-363292028/
xtrabackup: This target seems to be not prepared yet.
Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(17547913)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 209715200 bytes for buffer pool (set by --use-memory parameter)
PUNCH HOLE support available
Mutexes and rw_locks use GCC atomic builtins
Uses event mutexes
GCC builtin __atomic_thread_fence() is used for memory barrier
Compressed tables use zlib 1.2.7
Number of pools: 1
Not using CPU crc32 instructions
Directories to scan './'
Scanning './'
Completed space ID check of 5 files.
Initializing buffer pool, total size = 256.000000M, instances = 1, chunk size =128.000000M
Completed initialization of buffer pool
If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
Starting to parse redo log at lsn = 17547791, whereas checkpoint_lsn = 17547913
Log scan progressed past the checkpoint LSN 17547791.
Database was not shutdown normally!
Starting crash recovery.
Doing recovery: scanned up to log sequence number 18072402
Log background threads are being started...
Applying a batch of 323 redo log records ...
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Apply batch completed!
Using undo tablespace './undo_001'.
Using undo tablespace './undo_002'.
Opened 2 existing undo tablespaces.
GTID recovery trx_no: 1817
Creating shared tablespace for temporary tables
Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
File './ibtmp1' size is now 12 MB.
Scanning temp tablespace dir:'./#innodb_temp/'
Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
8.0.21 started; log sequence number 18072402
Allocated tablespace ID 1 for sys/sys_config, old maximum was 0
xtrabackup8: Unknown error 3611
xtrabackup8: Unknown error 3611
xtrabackup8: Unknown error 3611
08:27:09 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
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 = 0 thread_stack 0x46000
xtrabackup8(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x230b55e]
xtrabackup8(handle_fatal_signal+0x2eb) [0x11b729b]
/lib64/libpthread.so.0(+0xf6d0) [0x7fd7318246d0]
xtrabackup8(dd::get_dd_client(THD*)+0x1) [0x16c8061]
xtrabackup8(dd_table_open_on_name(THD*, MDL_ticket**, char const*, bool, unsigned long, int*)+0x53a) [0x137306a]
xtrabackup8() [0xcc9f5e]
xtrabackup8() [0xccb060]
xtrabackup8(main+0xca9) [0xc8ad19]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fd72f697445]
xtrabackup8() [0xcb7bb7]
Please report a bug at https://jira.percona.com/projects/PXB
)
percona官方BUG说明链接
- https://jira.percona.com/browse/PXB-2293
- https://jira.percona.com/browse/PXB-2301
- https://jira.percona.com/browse/PXB-2315
- percona博客说明
关于xtrabackup及MySQL的是否匹配的注意事项
- xtrabackup优先选择最新版的,越新越好
- MySQL尽量选择次新版(考虑xtrabackup的更新速度可能不及时,导致最新版的MySQL出来时,xtrabackup没法快速兼容)
- 但这个需要注意的是MySQL8.0.24是一个一个过渡版本,当前最新为8.0.25,实际上8.0.24存在BUG导致8.0.25直接发布,在这种特殊的情况下,需要优先用8.0.25(可以理解为8.0.24这个版本生产环境不可用)