Avamar: Incrementele AlwaysOn SQL-back-ups mislukken soms vanwege loggap-fouten
Summary: Voor incrementele back-up tijdens vergelijking van logboekvolgnummer (LSN) retourneert de SQL-server de nieuwste LSN voor de database. Avamar-metadata hebben echter een oudere LSN-waarde in het sqlmeta.xml-bestand. Dit zorgt ervoor dat incrementele SQL-back-ups mislukken, een loggat is geïdentificeerd of geen volledige back-up is gevonden. Voor de clusterback-up is waargenomen dat er een generieke vertraging van 1 seconde is bij het bijwerken van de tabel sys.database_recovery_status met de nieuwste LSN-waarde. Als gevolg hiervan wordt het verouderde LSN-nummer geretourneerd via de Avamar SQL Plugin-query. ...
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.
De LSN-informatie in sqlmeta.xml is verouderd en loopt niet synchroon met de SQL Server-weergave van dezelfde database.
Cause
Voor incrementele SQL-back-ups vergelijkt het proces het LSN-nummer dat wordt opgehaald van sys.database_recovery_status bij het vinden van een logboekgap. De query die voor deze taak wordt gebruikt is:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id = DB_ID(N’db2-mi')"
Het logboek ziet er als volgt uit:
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 bestand tijdens deze incrementele update met behulp van de volgende query:
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE database_name=N'db2-mi' AND type LIKE 'L' ORDER by last_lsn DESC
De resultaten van de twee query's moeten hetzelfde LSN-nummer voor de database vermelden.
Als het resultaat niet overeenkomt, is er een bevestigde inbraakvolgorde en loggapfout verwacht tijdens incrementele back-ups. In een ideaal scenario tijdens clusterback-ups, na voltooiing van de back-up, werkt Microsoft SQL Server de tabel sys.database_recovery_status bij met de nieuwste LSN-waarde. Avamar SQL-plug-in zoekt in deze tabel naar LSN en slaat de waarde op in SQL-metadata. Tijdens de volgende incrementele back-up voert de Avamar SQL-plug-in opnieuw een query uit op de tabel en wordt de nieuwste LSN-waarde opgehaald. Deze LSN wordt vervolgens vergeleken met de LSN die is opgeslagen in SQL-metadata en er wordt een back-up gemaakt.
In drukke Always cluster-omgevingen, terwijl de Avamar SQL-plug-in een query uitvoert op de tabel voor LSN-waarde, wordt een oudere LSN-waarde verkregen en opgeslagen in SQL-metadata. Microsoft SQL Server werkt de tabel na enige tijd bij. Wanneer de SQL-plug-in tijdens de volgende incrementele back-up opnieuw een query uitvoert op de tabel, wordt de nieuwste LSN-waarde opgehaald. Wanneer deze waarde wordt vergeleken met de verouderde LSN die is opgeslagen in het sqlmeta.xml-bestand, wordt een loggat gevonden en wordt de back-up gepromoveerd naar volledig.
Resolution
Tijdelijke tijdelijke oplossing:
- Dwing een volledige back-up van deze database af om deze fout op te lossen.
- Hiermee wordt de LSN-nummerreeks voor de specifieke database in sqlmeta.xml en SQL-server opnieuw gesynchroniseerd.
- Alle volgende incrementele back-ups van deze database zouden nu met succes moeten zijn voltooid.
Permanente oplossing:
- Zorg ervoor dat u de vlag "--latest-lsn-from-msdb=true" toevoegt aan het avsql.cmd-bestand en pas de HotFix (HF) toe op basis van de versie van de clientplug-in:
- v19.10-100-135 => Geen HF beschikbaar, upgrade naar build 166 en pas de bijbehorende HF toe
- v19.10-100-166 (SP1) => HF 338887
- v19.12-100-186 => HF 338888
Zie de stappen beschreven in Avamar om de hotfix te downloaden van de Dell Support-zijde: Een producthotfix, patch, installatie of upgradepakket zoeken en downloaden van de Dell Support website
Als u de hotfix wilt toepassen, volgt u de instructies van Dell Support met behulp van het README-bestand of raadpleegt u het Dell Knowledge Base-artikel voor de specifieke hotfix.
Let op: Als het probleem zich blijft voordoen nadat u de hotfix hebt toegepast, neemt u contact op met Dell Support voor verdere hulp.