526互联

xtrabackup 恢复报错：Assertion failure: log0files_finder.cc:322:format >= Log_format

发布时间 2023-07-10 16:51:12作者: 创造新世界

 

2023-07-10T15:33:46.614144+08:00 0 [Note] [MY-012204] [InnoDB] Scanning './'
2023-07-10T15:33:46.647712+08:00 0 [Note] [MY-012208] [InnoDB] Completed space ID check of 229 files.
2023-07-10T15:33:46.648265+08:00 0 [Note] [MY-012955] [InnoDB] Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M
2023-07-10T15:33:46.655470+08:00 0 [Note] [MY-012957] [InnoDB] Completed initialization of buffer pool
2023-07-10T15:33:46.794961+08:00 0 [Note] [MY-011951] [InnoDB] page_cleaner coordinator priority: -20
2023-07-10T15:33:46.818424+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
2023-07-10T15:33:46.841662+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
2023-07-10T15:33:46.865034+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
InnoDB: Assertion failure: log0files_finder.cc:322:format >= Log_format::VERSION_8_0_30
InnoDB: thread 139874471463616InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2023-07-10T07:33:46Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=
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 0x100000
xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x25de83d]
xtrabackup(print_fatal_signal(int)+0x393) [0x13402a3]
xtrabackup(handle_fatal_signal+0x95) [0x1340385]
/lib64/libpthread.so.0(+0xf630) [0x7f370fedf630]
/lib64/libc.so.6(gsignal+0x37) [0x7f370dacb387]
/lib64/libc.so.6(abort+0x148) [0x7f370dacca78]
xtrabackup(my_abort()+0xa) [0x25d800a]
xtrabackup(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0xf7) [0x1864677]
xtrabackup(log_files_find_and_analyze(bool, Encryption_metadata&, Log_files_dict&, Log_format&, std::string&, unsigned int&, unsigned int&)+0x1841) [0x16f6371]
xtrabackup(log_sys_init(bool, unsigned long, unsigned long&)+0x2407) [0x170d757]
xtrabackup(srv_start(bool, unsigned long)+0x1397) [0x180b467]
xtrabackup() [0xda592d]
xtrabackup(main+0x1823) [0xd52243]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f370dab7555]
xtrabackup() [0xd89f07]

Please report a bug at https://jira.percona.com/projects/PXB

环境是centos 7  ,percona-xtrabackup-80-8.0.32-25.1.el7.x86_64

用语句   xtrabackup --defaults-file=/data/mysql13619/conf/my.cnf --prepare --apply-log-only --target-dir=/data/backup/base/   恢复全备报上面的错，考虑可能是log-bin的问题，修改语句为 xtrabackup --defaults-file=/data/mysql13619/conf/my.cnf --prepare  --target-dir=/data/backup/base/       

之后正常恢复。全备的数据库是20CPU,240g内存的云服务器，一开始用一般的虚拟机，几核几G的来做恢复测试，会报错，后面是找了到哪10CPU,128G内存做的恢复测试。