Avamar: AlwaysOn SQL-trinvise sikkerhedskopieringer mislykkes tilfældigt på grund af "log gap"-fejl
Summary: For trinvis sikkerhedskopiering under sammenligning af logsekvensnummer (LSN) returnerer SQL-serveren det seneste LSN for databasen. Avamar-metadata har dog ældre LSN-værdi i sqlmeta.xml filen. Dette medfører, at SQL-trinvise sikkerhedskopieringer mislykkes, når der identificeres et loghul, eller der ikke blev fundet en fuld sikkerhedskopi. I forbindelse med sikkerhedskopieringen af klyngen blev det observeret, at der er en generisk forsinkelse på 1 sekund ved opdatering af tabellen sys.database_recovery_status med den seneste LSN-værdi. Som følge heraf returneres det forældede LSN-nummer fra Avamar SQL Plugin-forespørgslen. ...
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-oplysningerne i sqlmeta.xml er forældede og ikke synkroniseret med SQL-servervisningen for den samme database.
Cause
For SQL-trinvise sikkerhedskopieringer sammenligner processen LSN-nummer, der hentes fra sys.database_recovery_status, mens der findes loggab. Den forespørgsel, der bruges til denne opgave, er:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id = DB_ID(N’db2-mi')"
Loggen ville se sådan ud:
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 fil under denne trinvise opdatering ved hjælp af følgende forespørgsel:
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE database_name=N'db2-mi' AND type LIKE 'L' ORDER by last_lsn DESC
Resultaterne af de to forespørgsler bør rapportere det samme LSN-nummer for databasen.
Hvis resultatet ikke stemmer overens, forventes der en bekræftet indbrudssekvens for "logkæde" og loggabsfejl under trinvise sikkerhedskopieringer. I et ideelt scenarie under klyngesikkerhedskopieringer opdaterer Microsoft SQL-serveren tabellen med den nyeste LSN-værdi, når sys.database_recovery_status sikkerhedskopieringen er fuldført. Avamar SQL-plugin forespørger denne tabel efter LSN og gemmer værdien i SQL-metadata. Under den næste trinvise sikkerhedskopiering forespørger Avamar SQL-plugin'et igen på tabellen og henter den nyeste LSN-værdi. Dette LSN sammenlignes derefter med det LSN, der er gemt i SQL-metadata, og der udføres en sikkerhedskopi.
I travle Always-klyngemiljøer, mens Avamar SQL-plugin forespørger tabellen for LSN-værdi, hentes og gemmes ældre LSN-værdi i SQL-metadata. Microsoft SQL-server opdaterer tabellen efter et stykke tid. Under den næste trinvise sikkerhedskopiering, når SQL-plug-in'et forespørger tabellen igen, får det den seneste LSN-værdi. Når denne værdi sammenlignes med det forældede LSN, der er gemt i sqlmeta.xml-filen, findes der et loggab, og sikkerhedskopien fremmes til fuld.
Resolution
Midlertidig midlertidig løsning:
- Gennemtving en komplet sikkerhedskopiering af denne database for at løse denne fejl.
- Dette synkroniserer LSN-nummerserien igen for den specifikke database i sqlmeta.xml og SQL-serveren.
- Alle efterfølgende trinvise sikkerhedskopieringer af denne database bør nu være fuldført.
Permanent løsning:
- Sørg for at føje flaget "--latest-lsn-from-msdb=true" til avsql.cmd filen, og anvend hotfixet (HF) i henhold til klient-plug-in-versionen:
- v19.10-100-135 => Ingen HF tilgængelig, opgrader til build 166, og anvend den tilsvarende HF
- v19.10-100-166 (SP1) => HF 338887
- v19.12-100-186 => HF 338888
Hvis du vil downloade hotfixet fra Dell Support-siden, skal du se de trin, der er beskrevet i Avamar: Sådan finder og downloader du en produkthotfix-, programrettelses-, installations- eller opgraderingspakke fra Dells supportwebsted
Hvis du vil installere hotfixet, skal du følge instruktionerne fra Dell Support ved hjælp af README-filen eller se Dell Knowledge Base-artiklen for det specifikke hotfix.
Forsigtig: Hvis problemet fortsætter efter installation af hotfixet, skal du kontakte Dell Support for at få yderligere hjælp.