Mysql，失败的xtrabackup和怪异的撤消表空间度量标准

Question

我正在尝试设置一个MySQL副本服务器，但是，由于数据库的大小相当大，所以我使用xtrabackup。后者在开始时经常失败(虽然我以前经常使用它)：

xtrabackup: recognized server arguments: --innodb_log_buffer_size=32M --innodb_log_file_size=4096M --innodb_buffer_pool_size=64G --innodb_flush_log_at_trx_commit=2 --innodb_log_buffer_size=256M --innodb_io_capacity=3000 --innodb_checksum_algorithm=none --innodb_flush_method=O_DIRECT --innodb_read_io_threads=64 --innodb_write_io_threads=64 --server-id=5 --log_bin=mysql-bin 
xtrabackup: recognized client arguments: --port=3306 --socket=/tmp/mysql.sock --backup=1 --user=XXXX --password=XXXXXX --target-dir=/usr/local/public/backups 
xtrabackup version 8.0.14 based on MySQL server 8.0.21 FreeBSD12.2 (amd64) (revision id: 113f3d7)
220225 18:59:41  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/tmp/mysql.sock' as 'root'  (using password: YES).
220225 18:59:41  version_check Connected to MySQL server
220225 18:59:41  version_check Executing a version check against the server...
220225 18:59:41  version_check Done.
220225 18:59:41 Connecting to MySQL server host: localhost, user: XXXXX, password: set, port: 3306, socket: /tmp/mysql.sock
Using server version 8.0.22
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/db/mysql/
xtrabackup: open files limit requested 0, set to 5621859
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 4294967296
xtrabackup: using O_DIRECT
Number of pools: 1
220225 18:59:41 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /tmp/mysql.sock
xtrabackup: Redo Log Archiving is not set up.
Starting to parse redo log at lsn = 83173920975378
Recovery parsing buffer extended to 4194304.
Recovery parsing buffer extended to 8388608.
Recovery parsing buffer extended to 16777216.
Recovery parsing buffer extended to 33554432.
Recovery parsing buffer extended to 67108864.
Recovery parsing buffer extended to 134217728.
220225 18:59:59 >> log scanned up to (83174734573031)
xtrabackup: Generating a list of tablespaces
xtrabackup: Generating a list of tablespaces
Scanning './'
Completed space ID check of 4 files.
Allocated tablespace ID 8533 for wimc_test/mp_group, old maximum was 0
220225 19:00:00 >> log scanned up to (83174734978857)
Using undo tablespace './undo003.ibu'.
Using undo tablespace './undo004.ibu'.
Opened 2 existing undo tablespaces.
Cannot create undo tablespaces since innodb_read_only has been set. Using 0 existing undo tablespaces.
Cannot continue InnoDB startup in read_only mode because there are no existing undo tablespaces found.
xtrabackup: error: xb_load_tablespaces() failed with error code 11

在深入了解mysql内部之后，我注意到撤销表空间有奇怪的零度量FS_BLOCK_SIZE、FILE_SIZE和ALLOCATED_SIZE (尽管这四个文件的大小都不是0)：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES where row_format='Undo';
+------------+-----------------+------+------------+-----------+---------------+------------+---------------+-----------+----------------+----------------+---------------+------------+--------+
| SPACE      | NAME            | FLAG | ROW_FORMAT | PAGE_SIZE | ZIP_PAGE_SIZE | SPACE_TYPE | FS_BLOCK_SIZE | FILE_SIZE | ALLOCATED_SIZE | SERVER_VERSION | SPACE_VERSION | ENCRYPTION | STATE  |
+------------+-----------------+------+------------+-----------+---------------+------------+---------------+-----------+----------------+----------------+---------------+------------+--------+
| 4294898191 | innodb_undo_001 |    0 | Undo       |     16384 |             0 | Undo       |             0 |         0 |              0 | 8.0.14         |             1 | N          | active |
| 4294899206 | innodb_undo_002 |    0 | Undo       |     16384 |             0 | Undo       |             0 |         0 |              0 | 8.0.14         |             1 | N          | active |
| 4294967277 | undo_003        |    0 | Undo       |     16384 |             0 | Undo       |             0 |         0 |              0 | 8.0.22         |             1 | N          | active |
| 4294967276 | undo_004        |    0 | Undo       |     16384 |             0 | Undo       |             0 |         0 |              0 | 8.0.22         |             1 | N          | active |
+------------+-----------------+------+------------+-----------+---------------+------------+---------------+-----------+----------------+----------------+---------------+------------+--------+
4 rows in set (0.04 sec)

这是唯一一台这样的服务器。我是否正确地认为这是导致xtrabackup崩溃的根本原因？

我怎么才能解决这个问题？我尝试手动创建两个非系统撤消表空间，xtrabackup尝试使用它们，但仍然崩溃。这两个新的撤销表空间也将这两个度量设置为0。

Answer 1

长话短说。当满足数据库大小/布局/qps上的某些条件时，xtrabackup中存在一个bug；对于满足它的人来说，它是100%的可重现性(另一方面，这个版本/某些二进制文件可以成功地与其他实例一起工作)。与此同时，我在一台中文服务器上找到了一个线程，上面有半中文/半英文的讨论，描述了这一问题的根本原因(但在世界的英语部分没有任何痕迹)。

这个bug与可以看到的撤销表空间度量无关。事实上，尽管有零，这些表空间是完全可用的。

我无法重现xtraback8.0.26的问题。