Logshipping secondary server is out of sync and LSRestore job failing
Logshipping secondary server is out of sync and transaction log restore job failing.
Problem
You can see that your logshipping is broken. In the SQL Error log, the message below is displayed :
Error: 14421, Severity: 16, State: 1.
The log shipping secondary database myDB.logshippingPrimary has restore threshold of 45 minutes and is out of sync. No restore was performed for 6258 minutes.
Description of error message 14420 and error message 14421 that occur when you use log shipping in SQL Server
https://support.microsoft.com/default.aspx?scid=329133
Cause
Inside the LSRestore job history, you can find out two kind of messages :
- Restore job skipping the logs on secondary server
Skipped log backup file. Secondary DB: 'logshippingSecondary', File: '\\myDB\logshipping\logshippingPrimary_20090808173803.trn'
- Backup log older is missing
*** Error 4305: The file '\\myDB\logshipping\logshippingPrimary_20090808174201.trn' is too recent to apply to the secondary database 'logshippingSecondary'.
**** Error : The log in this backup set begins at LSN 18000000005000001, which is too recent to apply to the database. An earlier log backup that includes LSN 18000000004900001 can be restored.
Transaction Log backups can only be restored if they are in a sequence. If the LastLSN field and the FirstLSN field do not display the same number on consecutive transaction log backups, they are not restorable in that sequence. There may be several reasons for transaction log backups to be out of sequence. Some of the most common reasons are a redundant transaction log backup jobs on the primary server that are causing the sequence to be broken or the recovery model of the database was probably toggled between transaction log backups.
Resolution
At this time, to check if there are a gaps in the Restore Process. You can run the query below to try to find out whether a redundant Backup Log was performed :
SELECT
s.database_name,s.backup_finish_date,y.physical_device_name
FROM
msdb..backupset AS s INNER JOIN
msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE
(s.database_name = 'databaseNamePrimaryServer')
ORDER BY
s.backup_finish_date DESC;
You can see that another Backup Log was running out of logshipping process. Now, you have just to restore this backup on the secondary and run the LSRestore Job.
Logshipping le serveur secondaire n'est plus synchroninsé et le job de restauration des fichiers de transaction est en échec.
Problème
Vous avez constaté que le logshipping ne fonctionne plus. Dans l'erreur log SQL server, vous avez les messages suivant affiché :
Error: 14421, Severity: 16, State: 1.
The log shipping secondary database myDB.logshippingPrimary has restore threshold of 45 minutes and is out of sync. No restore was performed for 6258 minutes.
Description de message d'erreur 14420 et message d'erreur 14421 se produire lorsque vous utilisez l'envoi de journaux dans SQL Server
https://support.microsoft.com/default.aspx?scid=329133
Cause
Dans l'historique du Job LSRestore vous pouvez observer les deux types de message suivant :
- Le job de restauration Restore ne restaure plus les derniers backup de transaction sur le serveur secondaire.
Skipped log backup file. Secondary DB: 'logshippingSecondary', File: '\\myDB\logshipping\logshippingPrimary_20090808173803.trn'
- Un message indique qu'il manque un fichier plus ancien qui brise la chaine des LSN
*** Error 4305: The file '\\myDB\logshipping\logshippingPrimary_20090808174201.trn' is too recent to apply to the secondary database 'logshippingSecondary'.
**** Error : The log in this backup set begins at LSN 18000000005000001, which is too recent to apply to the database. An earlier log backup that includes LSN 18000000004900001 can be restored.
Les sauvegardes du journal de transactions peuvent être restaurés seulement si elles se trouvent dans une séquence. Si le champ LastLSN et le champ FirstLSN n'affichent pas le même numéro de sauvegardes de journaux de transactions consécutifs, ils ne sont pas restorable dans cet ordre. Il peut y avoir plusieurs raisons pour que les sauvegardes de journaux transactions soient hors de la séquence. Les causes les plus courantes sont par exemple un backup du journal de transaction redondant sur le serveur principal qui rompe la séquence ou que mode de récupération de la base de données a probablement été changé en cours de route.
Résolution
Pour vérifier s'il y a un trou dans le processus de restauration. Je vous invite à lancer la requête ci-dessous :
SELECT
s.database_name,s.backup_finish_date,y.physical_device_name
FROM
msdb..backupset AS s INNER JOIN
msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE
(s.database_name = 'databaseNamePrimaryServer')
ORDER BY
s.backup_finish_date DESC;
Comme vous pouvez le voir, il y a une un backup de log qui n'est pas du au logshipping. Vous devez le restaurer sur le serveur secondaire et relancer le job LSRestore.
Logshipping el servidor secundario está fuera de sincronización y el trabajo de restauracion de transacción de registro de transacciones falla.
Problema
Usted puede ver que su logshipping está roto. En el registro de errores de SQL, el mensaje se muestra a continuación:
Error: 14421, gravedad: 16, estado: 1.
La base de datos secundaria de trasvase de registros myDB tiene un umbral de restauración de 45 minutos y no está sincronizada. No se ha realizado ninguna operación de restauración durante 6258 minutos. La latencia restaurada es de %5! minutos.
Descripción de mensajes de error 14420 y mensaje de error 14421 que producen cuando utiliza el trasvase de registros en SQL Server
https://support.microsoft.com/default.aspx?scid=329133
Causa
Dentro del historial de trabajo de LSRestore, usted puede encontrar dos tipos de mensajes:
- El trabajo de restauración se salta los registros en el servidor secundario
Registro de archivo de copia de seguridad saltado. Secondary DB: 'logshippingSecondary', File: '\\myDB\logshipping\logshippingPrimary_20090808173803.trn'
- La copia de seguridad más antigua de registro falta:
*** Error : The file '\\myDB\logshipping\logshippingPrimary_20090808174201.trn' es demasiado reciente para aplicarlo a la base de datos secundaria 'logshippingSecondary'.
**** Error : El registro de este conjunto de copia de seguridad empieza en el LSN 18000000005000001, demasiado reciente para aplicarlo a la base de datos. Se puede restaurar una copia de seguridad de registros anterior, que incluye el LSN 18000000004900001.
Sólo se pueden restaurar copias de seguridad del registro de transacciones si están en una secuencia. Si el campo LastLSN y el campo FirstLSN no muestran el mismo número de copias de seguridad del registro de transacción, No son restaurables en esa secuencia. Existen varios motivos por los cuales las copias de seguridad de registro de transacciones están fuera de secuencia. Algunas de las razones más comunes son trabajos redundantes de copias de seguridad de log de transacciones en el servidor principal que están provocando que la secuencia se rompa o cuando el modelo de recuperación de la base de datos haya cambiado entre las copias de seguridad del registro de transacciones.
Resolución
En este momento, para comprobar si hay deficiencias en el proceso de restauración puede ejecutar la consulta siguiente para tratar de averiguar si una copia de seguridad redundante se realizó:
SELECT
s.database_name,s.backup_finish_date,y.physical_device_name
FROM
msdb..backupset AS s INNER JOIN
msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE
(s.database_name = 'databaseNamePrimaryServer')
ORDER BY
s.backup_finish_date DESC;
Usted puede ver que otro registro de copia de seguridad se ejecuta fuera de proceso logshipping. Ahora, sólo tienes que restaurar esta copia de seguridad en la secundaria y ejecutar el trabajo LSRestore.
Understanding Logging and Recovery in SQL Server
Michel Degremont | Microsoft EMEA
Product Support Services Developer - SQL Server Core Engineer |