Partilhar 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 Não é possível aceder ao banco de dados '%.*ls' porque não possui quórum de nós para alta disponibilidade. Tente a operação novamente mais tarde.

Symptoms

Quando você tenta adicionar um banco de dados a um grupo de disponibilidade Always On ou executar operações de leitura/gravação na réplica primária, você pode receber o seguinte erro 988 do SQL Server:

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

Esse erro indica que o banco de dados não pode ser acessado ou adicionado porque o número necessário de réplicas secundárias sincronizadas não está disponível para confirmar a transação.

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. Se o número necessário de réplicas não estiver online, conectado e sincronizado, você poderá encontrar os seguintes problemas, que levam a cenários de bloqueio ou falha que acionam o erro 988.

  • A réplica principal não pode concluir confirmações.
  • Um banco de dados que está sendo adicionado não pode concluir o processo de junção, pois os secundários ainda não estão participando.

Scenarios

Você pode encontrar esse erro nos seguintes cenários:

Cenário 1: Adicionar um novo banco de dados

Quando um novo banco de dados é adicionado ao grupo de disponibilidade, os secundários ainda não fazem parte do grupo e não podem reconhecer a confirmação, causando uma condição de bloqueio.

Cenário 2: Falhas de confirmação de tempo de execução

Quando o valor configurado de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT é maior do que o número de secundários síncronos íntegros disponíveis, o primário não pode prosseguir com confirmações.

Workaround

Para contornar esse problema, use uma das seguintes opções:

Opção 1: Ajustar a definição de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Reduzir o valor para 0 permite que o primário confirme sem esperar por secundários síncronos.

Warning

Essa opção melhora a disponibilidade, mas aumenta o risco de perda de dados em cenários de failover.

Utilizar o SQL Server Management Studio (SSMS)

  1. Navegue até o nome do grupo de disponibilidade no SSMS.
  2. Right-click the name and select Properties.
  3. Defina o valor REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT ou 0 um valor apropriado.

Use T-SQL

Execute a seguinte consulta:

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

Opção 2: Pré-semear as réplicas secundárias (para adicionar bancos de dados)

Certifique-se de que os secundários estão prontos antes de adicionar um banco de dados. Then, use automatic seeding, or manually restore the database on each secondary by using the Join only option.

Troubleshooting

Para diagnosticar e resolver este problema, siga estes passos:

Etapa 1: Confirmar a configuração REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Para verificar se a configuração está habilitada REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT para seu grupo de disponibilidade (AG), use SSMS ou T-SQL. Se o valor for 1 ou superior, avance para Passo 2: Verificar o estado das réplicas secundárias síncronas.

Use SSMS

  1. Navegue até o nome do grupo de disponibilidade no SSMS.
  2. Right-click the name and select Properties.
  3. Verifique o valor REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT (Secundários sincronizados necessários para confirmar ).

Use T-SQL

Execute a seguinte consulta na réplica primária:

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

Note

Esta consulta pode ser executada mesmo se o erro 988 começar a ocorrer.

Etapa 2: Verificar o estado das réplicas secundárias síncronas

Para verificar se o número mínimo de réplicas secundárias síncronas está conectado, sincronizado e íntegro, use SSMS ou T-SQL.

Use SSMS

  1. Abra o Painel de Grupos de Disponibilidade na réplica principal.
  2. Analise o estado das réplicas secundárias.

Use T-SQL

Execute a seguinte consulta:

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;

Verifique se o número de CONNECTED, SYNCHRONIZEDe HEALTHY réplicas corresponde à REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT configuração.

A sessão de eventos estendida a seguir captura as configurações de diretiva de confirmação e as alterações de estado de sincronização para diagnosticar por que os secundários sincronizados necessários impedem confirmações de transações em grupos de disponibilidade Always On do 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