Xtrabackup 8.0.14 備份MySQL 8.0.22異常

目錄

• ​​異常背景​​
• ​​環境資訊​​
• ​​報錯資訊​​
• ​​percona官方BUG說明連結​​
• ​​關于xtrabackup及MySQL的是否比對的注意事項​​

異常背景

之前一篇部落格介紹到由于MySQLredo日志的調整導緻xtrabackup備份失敗的文章,,這次我們嘗試用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部落格說明

• ​​https://www.percona.com/blog/2020/10/23/mysql-new-releases-and-percona-xtrabackup-incompatibilities/​​

關于xtrabackup及MySQL的是否比對的注意事項

1. xtrabackup優先選擇最新版的,越新越好
2. MySQL盡量選擇次新版(考慮xtrabackup的更新速度可能不及時,導緻最新版的MySQL出來時,xtrabackup沒法快速相容)

• 但這個需要注意的是MySQL8.0.24是一個一個過渡版本,目前最新為8.0.25,實際上8.0.24存在BUG導緻8.0.25直接釋出,在這種特殊的情況下,需要優先用8.0.25(可以了解為8.0.24這個版本生産環境不可用)