Avamar:AlwaysOn SQL 增量備份會因為「記錄間隙」錯誤而隨機失敗
Summary: 針對記錄順序編號 (LSN) 比較期間的增量備份,SQL 伺服器會為資料庫傳回最新的 LSN。但是,Avamar 中繼資料在 sqlmeta.xml 檔案中有較舊的 LSN 值。這會導致 SQL 增量備份失敗,並識別出記錄間隙,或找不到完整備份。 針對叢集備份,我們觀察到使用最新的 LSN 值更新表格sys.database_recovery_status時一般有 1 秒的延遲。因此,Avamar SQL 附掛程式查詢會傳回過期的 LSN 編號。 ...
Symptoms
2021/03/22-04:30:53.62299 [avsql_assist] Before alignment - Str1: '240000000392000001', Str2: '241000000328000001' 2021/03/22-04:30:53.62299 [avsql_assist] After alignment - Str1: '240000000392000001', Str2: '241000000328000001' 2021/03/22-04:30:53.62299 [avsql_assist] <=== avsql_assist::align_numeric_ustrings 2021-03-22 00:30:53 avsql Info <15765>: A log gap was identified or a full backup was not found. 2021/03/22-04:30:53.62299 [avsql_assist] ===> sqlconnect::~sqlconnect 2021/03/22-04:30:53.62299 [avsql_assist] <=== sqlconnect::~sqlconnect 2021/03/22-04:30:53.62299 [avsql_assist] <=== avsql_assist::snapup_check_timestamps 2021-03-22 00:30:53 avsql Error <40418>: Skipping database 'oalistener07\OA05_AG/_Sync' due to the following reason: A log gap was identified or a full backup was not found.
sqlmeta.xml中的 LSN 資訊已過時,並且與同一資料庫的 SQL 伺服器檢視不同步。
Cause
若為 SQL 增量備份,此程序會比較在尋找記錄差距時,從 sys.database_recovery_status 擷取的 LSN 編號。用於此工作的查詢為:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id = DB_ID(N’db2-mi')"
記錄看起來類似:
2022/08/24-03:28:01.12199 [avsql_assist] retrieving last backup lsn for 'db2-mi' db from sys.database_recovery_status 2022/08/24-03:28:01.12199 [avsql_assist] ===> sqlconnectimpl_smo::InitDll 2022/08/24-03:28:01.12199 [avsql_assist] SMO dll already loaded. 2022/08/24-03:28:01.12299 [avsql_assist] <=== sqlconnectimpl_smo::InitDll 2022/08/24-03:28:01.12400 [avsql_assist] ==> SMOWrap::SMO_GetLastBackupLSN 2022/08/24-03:28:01.28200 [avsql_assist] database 'db2-mi', last backup lsn = '315000000022400001' 2022/08/24-03:28:01.28200 [avsql_assist] <=== sqlconnectimpl_smo::get_last_backup_lsn 2022/08/24-03:28:01.28200 [avsql_assist] ===> avsql_metadata::get 2022/08/24-03:28:01.28200 [avsql_assist] ===> avsql_metadata::get 2022/08/24-03:28:01.28299 [avsql_assist] <=== avsql_metadata::get 2022/08/24-03:28:01.28299 [avsql_assist] <=== avsql_metadata::get 2022/08/24-03:28:01.28299 [avsql_assist] Last backup LSN: '315000000022400001' (Get from sqlmeta.xml), Current LSN: '315000000022400001'
在此增量更新期間,使用下列查詢sqlmeta.xml檔案:
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE database_name=N'db2-mi' AND type LIKE 'L' ORDER by last_lsn DESC
兩個查詢的結果應報告資料庫的相同 LSN 編號。
如果結果不相符,則在增量備份期間會出現確認的中斷「記錄鏈結」順序和記錄間隙錯誤。在群集備份期間的理想情況下,備份完成後Microsoft SQL 伺服器使用最新的 LSN 值更新表sys.database_recovery_status。Avamar SQL 附掛程式會查詢此表中的 LSN,並將值儲存在 SQL 中繼資料中。在下一次增量備份期間,Avamar SQL 附掛程式會再次查詢表格並取得最新的 LSN 值。然後將此 LSN 與存儲在 SQL 元數據中的 LSN 進行比較,並執行備份。
在忙碌的總是叢集環境中,當 Avamar SQL 附掛程式查詢表中的 LSN 值時,會取得較舊的 LSN 值並儲存在 SQL 中繼資料中。Microsoft SQL 伺服器會在一段時間後更新表格。在下一次增量備份期間,當 SQL 外掛程式再次查詢表時,它會獲取最新的 LSN 值。將此值與存儲在sqlmeta.xml檔中的過時 LSN 進行比較時,將發現日誌間隙並將備份提升為完全。
Resolution
臨時因應措施:
- 強制對此資料庫進行完整備份以解決此故障。
- 這將重新同步 sqlmeta.xml 和 SQL 伺服器中特定資料庫的 LSN 編號規則。
- 此資料庫的所有後續增量備份現在應成功完成。
永久修正:
- 請務必將旗標「--latest-lsn-from-msdb=true」新增至 avsql.cmd 檔案,並根據用戶端附掛程式版本套用修補程式 (HF):
- v19.10-100-135 => 無可用的 HF,請升級至組建 166 並套用對應的 HF
- v19.10-100-166 (SP1) => HF 338887
- v19.12-100-186 => HF 338888
若要從 Dell 支援端下載 Hotfix,請參閱 Avamar 中所述的步驟:如何從 Dell 支援網站尋找和下載產品 hotfix、修補程式、安裝或升級套裝
若要套用 Hotfix,請依照 Dell 支援使用的讀我檔案提供的指示操作,或參閱 Dell 知識文章,以取得特定的 Hotfix。
警示:如果在套用 hotfix 後問題仍然存在,請聯絡 Dell 支援以取得進一步協助。