Avamar: AlwaysOn SQL inkrementella säkerhetskopieringar misslyckas slumpmässigt på grund av "log gap"-fel
Summary: För inkrementell säkerhetskopiering under LSN-jämförelsen (Log Sequence Number) returnerar SQL-servern det senaste LSN för databasen. Avamar-metadata har dock ett äldre LSN-värde i den sqlmeta.xml filen. Detta gör att inkrementella SQL-säkerhetskopieringar misslyckas med att en logglucka har identifierats eller att en fullständig säkerhetskopia inte hittades. För klustersäkerhetskopieringen observerades att det finns en allmän fördröjning på 1 sekund vid uppdatering av tabellen sys.database_recovery_status med det senaste LSN-värdet. Det innebär att det inaktuella LSN-numret returneras från Avamar SQL-plugin-frågan. ...
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.
LSN-informationen i sqlmeta.xml är inaktuell och inte synkroniserad med SQL Server-vyn för samma databas.
Cause
För inkrementella SQL-säkerhetskopieringar jämför processen LSN-nummer som hämtas från sys.database_recovery_status när loggluckor hittas. Frågan som används för den här uppgiften är:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id = DB_ID(N’db2-mi')"
Loggen skulle se ut så här:
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 filen under den här inkrementella uppdateringen med hjälp av följande fråga:
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE database_name=N'db2-mi' AND type LIKE 'L' ORDER by last_lsn DESC
Resultatet av de två frågorna bör rapportera samma LSN-nummer för databasen.
Om resultatet inte matchar finns det en bekräftad inbrottssekvens för "loggkedja" och ett logggapsfel som förväntas under inkrementella säkerhetskopieringar. I ett idealiskt scenario under klustersäkerhetskopieringar, när säkerhetskopieringen har slutförts, uppdaterar Microsoft SQL Server tabellen sys.database_recovery_status med det senaste LSN-värdet. Avamar SQL-plugin-programmet frågar den här tabellen efter LSN och lagrar värdet i SQL-metadata. Under nästa inkrementella säkerhetskopiering frågar Avamar SQL-insticksprogrammet tabellen igen och hämtar det senaste LSN-värdet. Detta LSN jämförs sedan med det LSN som lagras i SQL-metadata och en säkerhetskopiering utförs.
I upptagna Always Cluster-miljöer, medan Avamar SQL-plugin-programmet frågar tabellen efter LSN-värde, hämtas äldre LSN-värde och lagras i SQL-metadata. Microsoft SQL Server uppdaterar tabellen efter en stund. Under nästa inkrementella säkerhetskopiering när SQL-plugin-programmet frågar tabellen igen får det det senaste LSN-värdet. När det här värdet jämförs med inaktuellt LSN, som lagras i den sqlmeta.xml filen, hittas en logglucka och säkerhetskopian befordras till fullständig.
Resolution
Tillfällig lösning:
- Tvinga fram en fullständig säkerhetskopiering av den här databasen för att lösa felet.
- Detta synkroniserar om LSN-nummerserien för den specifika databasen i sqlmeta.xml och SQL Server.
- Alla efterföljande inkrementella säkerhetskopieringar av den här databasen bör nu slutföras.
Permanent lösning:
- Se till att lägga till flaggan "--latest-lsn-from-msdb=true" i avsql.cmd-filen och tillämpa snabbkorrigeringen (HF) enligt versionen av klientens plugin-program:
- v19.10-100-135 => Ingen HF tillgänglig, uppgradera till build 166 och applicera motsvarande HF
- v19.10-100-166 (SP1) => HF 338887
- v19.12-100-186 => HF 338888
Om du vill ladda ner snabbkorrigeringen från Dells support följer du stegen som beskrivs i Avamar: Hitta och hämta snabbkorrigeringar, korrigeringsfiler, installations- eller uppgraderingspaket från Dells supportwebbplats
Om du vill installera snabbkorrigeringen följer du anvisningarna från Dells support med hjälp av README-filen eller läser Dells kunskapsbasartikel för den specifika snabbkorrigeringen.
Varning! Om problemet kvarstår efter att du har installerat snabbkorrigeringen kontaktar du Dells support för ytterligare hjälp.