We can no longer perform backups with xtrabackup. SST replication is also broken.
The error message from xtrabackup is:
025-11-19T10:39:22.303761+01:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --server-id=10 --datadir=/var/lib/mysql/data --log_bin=/var/lib/mysql/binlog/binlog --datadir=/var/lib/mysql/data
2025-11-19T10:39:22.303882+01:00 0 [Note] [MY-011825] [Xtrabackup] recognized client arguments: --socket=/var/run/mysqld/mysqld.sock --user=xtrabackup --password=* --backup=1 --compress --extra-lsndir=/var/xtrabackup/lsn --estimate-memory=1 --target-dir=/var/xtrabackup/full_temp
/usr/bin/xtrabackup version 8.0.35-31 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 55ec21d7)
251119 10:39:22 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/run/mysqld/mysqld.sock' as 'xtrabackup' (using password: YES).
251119 10:39:22 version_check Connected to MySQL server
251119 10:39:22 version_check Executing a version check against the server...
251119 10:39:22 version_check Done.
2025-11-19T10:39:22.357380+01:00 0 [Note] [MY-011825] [Xtrabackup] Connecting to MySQL server host: localhost, user: xtrabackup, password: set, port: not set, socket: /var/run/mysqld/mysqld.sock
2025-11-19T10:39:22.363390+01:00 0 [Note] [MY-011825] [Xtrabackup] Using server version 8.0.43-34.1
2025-11-19T10:39:22.365424+01:00 0 [Note] [MY-011825] [Xtrabackup] Executing LOCK TABLES FOR BACKUP ...
2025-11-19T10:39:22.367178+01:00 0 [Note] [MY-011825] [Xtrabackup] uses posix_fadvise().
2025-11-19T10:39:22.367202+01:00 0 [Note] [MY-011825] [Xtrabackup] cd to /var/lib/mysql/data
2025-11-19T10:39:22.367217+01:00 0 [Note] [MY-011825] [Xtrabackup] open files limit requested 0, set to 1024
2025-11-19T10:39:22.377525+01:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration:
2025-11-19T10:39:22.377539+01:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = .
2025-11-19T10:39:22.377547+01:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:12M:autoextend
2025-11-19T10:39:22.377579+01:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = ./
2025-11-19T10:39:22.377587+01:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 2
2025-11-19T10:39:22.377601+01:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 50331648
2025-11-19T10:39:22.379165+01:00 0 [Note] [MY-011825] [Xtrabackup] inititialize_service_handles suceeded
2025-11-19T10:39:22.418343+01:00 0 [Note] [MY-011825] [Xtrabackup] Connecting to MySQL server host: localhost, user: xtrabackup, password: set, port: not set, socket: /var/run/mysqld/mysqld.sock
2025-11-19T10:39:22.423779+01:00 0 [Note] [MY-011825] [Xtrabackup] Redo Log Archiving is not set up.
2025-11-19T10:39:22.523448+01:00 0 [Note] [MY-011825] [Xtrabackup] Starting to parse redo log at lsn = 2801837839805
2025-11-19T10:39:22.524420+01:00 0 [Note] [MY-012564] [InnoDB] Recovery parsing buffer extended to 4194304.
2025-11-19T10:39:22.525358+01:00 0 [Note] [MY-012564] [InnoDB] Recovery parsing buffer extended to 8388608.
InnoDB: Assertion failure: fil0fil.cc:10743:page_id.space() != TRX_SYS_SPACE
InnoDB: thread 140099975677632InnoDB: 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.
2025-11-19T09:39:24Z 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
/usr/bin/xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x55eb3cdea26d]
/usr/bin/xtrabackup(print_fatal_signal(int)+0x397) [0x55eb3bb1d657]
/usr/bin/xtrabackup(handle_fatal_signal+0x95) [0x55eb3bb1d705]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c050) [0x7f6b90a5a050]
/lib/x86_64-linux-gnu/libc.so.6(+0x8aeec) [0x7f6b90aa8eec]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x12) [0x7f6b90a59fb2]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xd3) [0x7f6b90a44472]
/usr/bin/xtrabackup(my_abort()+0xa) [0x55eb3cde3aaa]
/usr/bin/xtrabackup(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0xe4) [0x55eb3bff9a64]
/usr/bin/xtrabackup(fil_tablespace_redo_extend(unsigned char*, unsigned char const*, page_id_t const&, unsigned long, bool)+0xa8) [0x55eb3bd7ecf8]
/usr/bin/xtrabackup(+0x16d6868) [0x55eb3bedb868]
/usr/bin/xtrabackup(+0x16d8716) [0x55eb3bedd716]
/usr/bin/xtrabackup(recv_parse_log_recs()+0x97) [0x55eb3bede417]
/usr/bin/xtrabackup(Redo_Log_Parser::parse_log(unsigned char const*, unsigned long, unsigned long)+0x3a6) [0x55eb3b5e9dd6]
/usr/bin/xtrabackup(Redo_Log_Data_Manager::copy_once(bool, bool*)+0x93) [0x55eb3b5ee403]
/usr/bin/xtrabackup(Redo_Log_Data_Manager::start()+0xcd) [0x55eb3b5ee7cd]
/usr/bin/xtrabackup(xtrabackup_backup_func()+0xe08) [0x55eb3b58d138]
/usr/bin/xtrabackup(main+0x1db9) [0x55eb3b53fc29]
/lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7f6b90a4524a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f6b90a45305]
/usr/bin/xtrabackup(_start+0x21) [0x55eb3b5739b1]
Please report a bug at https://jira.percona.com/projects/PXB
We already had this issue at the end of last week. We then performed a logical dump of the database with mysqlsh and completely restored the cluster from the dump. This worked for three days until now.
Can anyone help us?
xtradb Version: Ver 8.0.43-34.1 for Linux on x86_64 (Percona XtraDB Cluster (GPL), Release rel34, Revision 0682ba7, WSREP version 26.1.4.3)
xtrabackup Version: 8.0.35-31 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 55ec21d7)