Partager via

MSSQLSERVER_988

Applies to:SQL Server

Details

Attribute Value
Product Name SQL Server
Event ID 988
Event Source MSSQLSERVER
Component SQLEngine
Symbolic Name DB_HADRON_DATABASE_NO_QUORUM
Message Text Impossible d’accéder à la base de données « %.*ls » car il manque un quorum de nœuds pour la haute disponibilité. Réexécutez l'opération ultérieurement.

Symptoms

Lorsque vous tentez d’ajouter une base de données à un groupe de disponibilité Always On ou d’effectuer des opérations de lecture/écriture sur le réplica principal, vous pouvez recevoir l’erreur SQL Server suivante 988 :

Unable to access database '<DB Name>' because it lacks a quorum of nodes for high availability. (Microsoft SQL Server, Error: 988)

Cette erreur indique que la base de données n’est pas accessible ou ajoutée, car le nombre requis de réplicas secondaires synchronisés n’est pas disponible pour valider la transaction.

Cause

The REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT setting enforces that the primary replica must wait for a specified number of synchronous secondary replicas to harden each transaction before committing. Si le nombre requis de réplicas n’est pas en ligne, connecté et synchronisé, vous pouvez rencontrer les problèmes suivants, ce qui entraîne des scénarios de blocage ou d’échec qui déclenchent l’erreur 988.

  • Le réplica principal ne peut pas terminer les validations.
  • Une base de données ajoutée ne peut pas terminer le processus de jointure, car les secondaires ne participent pas encore.

Scenarios

Vous pouvez rencontrer cette erreur dans les scénarios suivants :

Scénario 1 : Ajouter une nouvelle base de données

Lorsqu’une nouvelle base de données est ajoutée au groupe de disponibilité, les secondaires ne font pas encore partie du groupe et ne peuvent pas reconnaître la validation, ce qui provoque une condition de blocage.

Scénario 2 : Échecs de validation du runtime

Lorsque la valeur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT configurée est supérieure au nombre de secondaires synchrones synchrones disponibles disponibles, le serveur principal ne peut pas poursuivre les validations.

Workaround

Pour contourner ce problème, utilisez l’une des options suivantes :

Option 1 : Ajuster le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

L’abaissement de la valeur pour permettre au 0 principal de valider sans attendre les fichiers secondaires synchrones.

Warning

Cette option améliore la disponibilité, mais augmente le risque de perte de données dans les scénarios de basculement.

Utiliser SQL Server Management Studio (SSMS)

  1. Accédez au nom du groupe de disponibilité dans SSMS.
  2. Right-click the name and select Properties.
  3. Définissez la valeur DE VALIDATION SECONDAIRE SYNCHRONISÉE REQUISE sur 0 ou une valeur appropriée.

Use T-SQL

Exécutez la requête suivante :

ALTER AVAILABILITY GROUP [AGNAME] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

Option 2 : Pré-amorçage des réplicas secondaires (pour l’ajout de bases de données)

Assurez-vous que les fichiers secondaires sont prêts avant d’ajouter une base de données. Then, use automatic seeding, or manually restore the database on each secondary by using the Join only option.

Troubleshooting

Pour diagnostiquer et résoudre ce problème, procédez comme suit :

Étape 1 : Confirmer le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Pour vérifier si le REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT paramètre est activé pour votre groupe de disponibilité (AG), utilisez SSMS ou T-SQL. Si la valeur est 1 ou supérieure, passez à l’étape 2 : vérifiez l’état des réplicas secondaires synchrones.

Use SSMS

  1. Accédez au nom du groupe de disponibilité dans SSMS.
  2. Right-click the name and select Properties.
  3. Vérifiez la valeur REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT .

Use T-SQL

Exécutez la requête suivante sur le réplica principal :

SELECT name AS Availability_group_name,
       required_synchronized_secondaries_to_commit,
       *
FROM sys.availability_groups;

Note

Cette requête peut être exécutée même si l’erreur 988 démarre.

Étape 2 : Vérifier l’état des réplicas secondaires synchrones

Pour vérifier si le nombre minimal de réplicas secondaires synchrones est connecté, synchronisé et sain, utilisez SSMS ou T-SQL.

Use SSMS

  1. Ouvrez le tableau de bord groupes de disponibilité sur le réplica principal.
  2. Passez en revue l’état des réplicas secondaires.

Use T-SQL

Exécutez la requête suivante :

SELECT ag.name AS Availability_group_name,
       drcs.database_name,
       ar.replica_server_name,
       ars.role_desc,
       ars.connected_state_desc,
       ars.synchronization_health_desc,
       ars.last_connect_error_description,
       ars.last_connect_error_number,
       ars.last_connect_error_timestamp,
       ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states AS ars
     INNER JOIN sys.availability_replicas AS ar
         ON ars.replica_id = ar.replica_id
     INNER JOIN sys.availability_groups AS ag
         ON ar.group_id = ag.group_id
     INNER JOIN sys.dm_hadr_database_replica_cluster_states AS drcs
         ON ar.replica_id = drcs.replica_id;

Assurez-vous que le nombre de CONNECTEDSYNCHRONIZEDréplicas et HEALTHY le nombre de réplicas correspondent au REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT paramètre.

La session d’événements étendue suivante capture les paramètres de stratégie de validation et les modifications d’état de synchronisation pour diagnostiquer pourquoi les secondaires synchronisés requis empêchent les validations de transaction dans les groupes de disponibilité Always On SQL Server.

CREATE EVENT SESSION [ag_state_change] ON SERVER
ADD EVENT sqlserver.alwayson_ddl_executed
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_harden
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_set_policy
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_partner_set_policy
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_partner_set_sync_state
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text))
ADD TARGET package0.event_file
    (SET filename = N'ag_state_change')
WITH
(
        MAX_MEMORY = 4096 KB,
        EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
        MAX_DISPATCH_LATENCY = 30 SECONDS,
        MAX_EVENT_SIZE = 0 KB,
        MEMORY_PARTITION_MODE = NONE,
        TRACK_CAUSALITY = OFF,
        STARTUP_STATE = OFF
);
GO

The hadr_db_commit_mgr_update_harden event could be used to identify the issue. When the issue occurs, the MinSyncCommitFailure status means there aren't enough synchronization secondaries to meet the configured minimum synchronization count.

  • Last updated on