Compartilhar 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 acessar o banco de dados '%.*ls' porque ele não tem um quorum de nós para alta disponibilidade. Tente a operação novamente mais tarde.

Symptoms

Ao tentar 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ê poderá receber o seguinte erro do SQL Server 988:

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 disparam o erro 988.

  • A réplica primária 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 runtime

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

Workaround

Para encontrar uma solução alternativa para esse problema, use uma das seguintes opções:

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

A redução do valor 0 permite que o primário se confirme sem aguardar secundários síncronos.

Warning

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

Usar SSMS (SQL Server Management Studio)

  1. Navegue até o nome do grupo de disponibilidade no SSMS.
  2. Right-click the name and select Properties.
  3. Defina os SECUNDÁRIOS SINCRONIZADOS NECESSÁRIOS PARA CONFIRMAR o valor 0 ou 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é-propagar as réplicas secundárias (para adicionar bancos de dados)

Verifique se 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 esse problema, siga estas etapas:

Etapa 1: confirmar a configuração de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Para verificar se a REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT configuração está habilitada para seu grupo de disponibilidade (AG), use SSMS ou T-SQL. Se o valor for 1 ou superior, vá para a Etapa 2: verifique 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 os SECUNDÁRIOS SINCRONIZADOS NECESSÁRIOS PARA CONFIRMAR o valor.

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

Essa 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 primária.
  2. Examine 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 evento estendida a seguir captura as configurações de política 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ção 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