Mysql，失敗的 xtrabackup 和奇怪的撤消表空間指標

我正在嘗試設置一個 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嘗試使用它們，但仍然崩潰。而這兩個新的 undo 表空間也將這兩個指標設置為 0。

所以，長話短說。xtrabackup 中存在一個錯誤，當滿足數據庫大小/佈局/qps 的某些條件時可能會遇到該錯誤；對於那些滿足它的人來說，它是 100% 可重現的（另一方面，這個版本/某些二進製文件可以成功地與其他實例一起使用）。同時，我設法在中文伺服器上找到了一個執行緒，其中包含半中文/半英文的討論，描述了其根本原因（儘管在世界英語部分沒有任何痕跡）。

此錯誤與可以看到的撤消表空間指標無關。事實上，儘管有零，但這些表空間是功能齊全的。

我無法使用 xtrabackup 8.0.26 重現該問題。

引用自：https://dba.stackexchange.com/questions/307983