1、現象

使用8.0.30的備份集進行恢復，執行prepare命令報錯如下

網絡上有人遇到相同的問題，說回退了舊的版本之后就沒有出現，實驗回退到使用8.0.30的版本進行prepare操作，的確成功了

2、原因分析

查看斷言位置的代碼，可以發現歷史記錄里，有一個提交重新計算了開始掃描的lsn位置

During backup phase, PXB first reads the checkpoint LSN(say LSN A) from redo
files and then copies the checkpoint header having checkpoint LSN (LSN B)
from redo file.
If server does a checkpoint after PXB read the checkpoint LSN and before
PXB copies the checkpoint header, then LSN A would be differnt from LSN B

During backup phase, PXB copies redo logs starting from LSN A.
But during prepare phase, PXB was setting redo file start LSN using checkpoint
header (LSN B).

經測試驗證，高版本代碼注釋掉set_lsn也可以正常進行prepare操作，即set_lsn這里出現了錯誤，進一步調試發現，為計算結果溢出，這也就是為啥有的環境必現，有的環境一直復現不出來。

如下圖，此處的header_num、OS_FILE_LOG_BLOCK_SIZE、round_off均為uint32類型，程序計算結果的時候，直接就把結果以uint32輸出，當lsn比較大時，就會出現溢出的情況，導致set_lsn異常

3、解決方案

如果修改xtrabackup代碼，可以考慮將某個變量強制轉換為lsn_t（即uint_64），如圖

當前解決方案，backuprecovery使用恢復的包里添加8030的二進制，形如xtrabackup8030，恢復的時候解析xtrabackup_info文件，如果是8.0.30的備份工具備份的，使用xtrabackup8030進行prepare