異常背景
之前一篇博客介紹到由於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這個版本生產環境不可用)