Suspender e retomar a movimentação de dados em grupos de disponibilidade Always On do SQL Server

Suspender e retomar a movimentação de dados em grupos de disponibilidade Always On do SQL Server

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Neste 26º artigo para a série Grupos de disponibilidade Always On do SQL Server, discutiremos o processo para suspender e retomar movimentos de dados entre réplicas de AG.

Requisitos

Podemos configurar grupos de disponibilidade Always On do SQL Server no modo de confirmação Sincronizado e Assincronizado, dependendo da criticidade do aplicativo, perda de dados aceita, recuperação de desastre e largura de banda da rede.

Suponha que precisemos reiniciar os servidores para aplicar patches de SO, patches de SQL, atividades agendadas, problemas relacionados ao SO. Normalmente, seguimos esta ordem para evitar qualquer failover automático:

  • Reinicialize a réplica secundária primeiro
  • Failover de AG
  • Reinicialize a réplica secundária (réplica primária antiga)

Na confirmação síncrona, a réplica primária aguarda a confirmação da réplica secundária para confirmá-la na primária. Se pararmos o SQL Services na réplica secundária, o SQL Server mudará imediatamente a sincronização para o modo assíncrono. Depois que a réplica secundária estabelece uma conexão, a sincronização de dados torna-se uma confirmação síncrona. Enquanto seguimos a sequência para reinicializar os servidores, isso pode causar distribuição na sincronização de dados.

Considere outro caso em que você implementou uma confirmação de dados síncronos de duas réplicas. Seus dois servidores estão em sites diferentes e sua equipe de rede informou que haveria uma queda de rede ou lentidão na conectividade de rede entre os dois sites. Uma maneira de corrigir a sincronização de dados é alterar o modo para assíncrono. Dessa forma, a réplica primária não espera a confirmação da secundária. No entanto, nas flutuações da rede, você pode obter quedas de pacotes que podem causar problemas com a sincronização da réplica secundária.

Neste artigo, encontramos respostas para as seguintes perguntas:

  • Podemos suspender a movimentação de dados da réplica primária para a secundária?
  • Podemos suspender a movimentação de dados para uma réplica secundária específica no caso de termos várias réplicas secundárias?
  • Qual é o impacto em uma réplica primária caso você suspenda a movimentação de dados?
  • Como retomar a movimentação de dados da réplica primária para a secundária?

Pré-requisitos

Você deve ler os artigos anteriores (ToC na parte inferior) e configurar os dois ou mais nós do SQL Server Always On Availability Group.

Leia Também  O que é o serviço CEIP do SQL Server?

Neste artigo, usamos a seguinte réplica AG de dois nós.

  • Réplica primária: SQLNode2 INST1
  • Réplica secundária: SQLNode1 INST1
  • Banco de dados AG: SQLShackDemo

Suspender movimentos de dados em grupos de disponibilidade Always On do SQL Server

O SQL Server Always On tem dois tipos de réplicas – Primária e Secundária. Uma réplica primária é adequada para transações somente leitura e de gravação. A réplica secundária pode ser configurada para permitir conexões somente leitura, mas não podemos gravar dados nela até que ela assuma a função de uma réplica primária após o failover. A movimentação de dados ocorre da réplica primária para a secundária.

Podemos suspender essa movimentação de dados da réplica primária e secundária. Também podemos usar SSMS GUI, t-SQL ou script do PowerShell para essa finalidade.

Suspender a movimentação de dados da réplica primária em grupos de disponibilidade Always On do SQL Server

Se nos conectarmos à instância SQL primária e pararmos a movimentação de dados, ela interromperá a movimentação de dados para todas as réplicas secundárias conectadas. O SQL Server nos permite 5 réplicas síncronas (1 primária e 4 secundárias). Não podemos interromper a movimentação de dados para uma réplica secundária específica da instância SQL primária. Assim que interrompemos a movimentação de dados, a réplica primária funciona bem e fica disponível para as conexões do cliente. No caso de você usar o secundário legível, suas conexões existentes funcionam junto com as novas conexões.

Suspender a movimentação de dados da réplica secundária em grupos de disponibilidade Always On do SQL Server

Podemos suspender a movimentação de dados para uma réplica secundária específica também. Para este requisito, você precisa conectar a instância SQL correspondente e interromper a movimentação de dados. Se suspendermos a movimentação de dados para uma réplica secundária específica (no caso de várias réplicas secundárias), isso não afetará as outras réplicas e elas continuarão recebendo os dados regularmente. O banco de dados de réplica secundária local mostra o status NÃO SINCRONIZANDO. No caso de secundário legível, não permite novas conexões, mas a conexão existente funciona.

Como suspender a movimentação de dados em grupos de disponibilidade Always On do SQL Server

O processo para suspender a movimentação de dados é o mesmo da réplica primária e secundária; entretanto, você precisa estar conectado à instância apropriada.

Conecte-se ao SQL no SSMS, navegue até Grupos de disponibilidade Always On-> Grupos de disponibilidade-> Bancos de dados de disponibilidade.

Suspender a movimentação de dados em grupos de disponibilidade Always On do SQL Server

Clique com o botão direito do mouse no banco de dados do qual deseja suspender a movimentação de dados.

Clique nas opções do banco de dados

Como alternativa, você pode executar o seguinte t-SQL para suspender a movimentação de dados para o [SQLShackDemo] base de dados.

Leia Também  Removendo o rastreio padrão - Parte 1

Ele coloca um símbolo de pausa na frente do banco de dados para mostrar que a movimentação de dados foi interrompida.

Movimento de dados interrompido

Se você suspender a movimentação de dados da réplica primária e verificar o status da réplica secundária, será exibida uma marca de cruz vermelha.

Movimento de dados interrompido no secundário

No painel AG, você obtém avisos e erros porque os bancos de dados não estão sincronizados.

Avisos do painel AG

Impacto da suspensão da sincronização de dados no banco de dados de réplica principal

Normalmente, em um banco de dados autônomo, o SQL Server trunca o log após o backup do log. No grupo de disponibilidade síncrona, ele também trunca o log no ponto de verificação durante o backup do log, pois primeiro confirma os dados na réplica secundária.

Agora, se tivermos pausado a sincronização de dados, o banco de dados de réplica primário continuará a conter os logs de transações. Ele não truncará os logs, apesar de você fazer backups regulares do log de transações. Isso pode encher seu log de transações e causar problemas de pouco espaço em disco. Portanto, você não deve suspender a movimentação de dados por um período mais longo, especialmente no caso de um ambiente altamente OLTP. No entanto, se você ainda obtiver o problema de log de transações cheio, considere adicionar espaço em disco, retomar ou remover o banco de dados do grupo de disponibilidade.

Retomar a movimentação de dados nos grupos de disponibilidade Always On do SQL Server

Para retomar a movimentação de dados da réplica primária para a secundária, clique com o botão direito do mouse no banco de dados do grupo de disponibilidade e clique em Resume Data Movement.

Retomar a movimentação de dados

Como alternativa, você também pode executar o seguinte script t-SQL.

Se tivéssemos suspendido a movimentação de dados do primário, você também deveria retomar do primário. Ele retoma os movimentos de dados para todas as réplicas secundárias. No entanto, se suspendemos a movimentação de dados localmente da instância secundária, você deve retomá-la da instância secundária. Ele captura todos os logs de transações pendentes e altera o status do banco de dados para Sincronizado Sincronizando de acordo com sua configuração. Seu banco de dados secundário funciona na confirmação de dados assíncronos até que esteja totalmente sincronizado com o primário.

Ele também registra os eventos nos logs de erros do SQL Server. Na captura de tela abaixo, vemos alguns logs em destaque sobre o LSN de suspensão, retomada e recuperação.

Ver logs de erros

Monitore suspender e retomar a movimentação de dados usando visualizações de gerenciamento dinâmicas

Podemos utilizar visualizações de gerenciamento dinâmico para monitorar a movimentação de dados da réplica primária para a secundária.

Leia Também  Kit de primeiro respondente e kit de ferramentas do consultor atualizados para agosto de 2020

Na saída abaixo, capturamos o LSN e os detalhes do participante do commit no cenário a seguir.

  • Na primeira parte, o banco de dados está em um estado sincronizado em ambas as réplicas
    • Mostra o valor 1 para a coluna is_commit_participant. Mostra que temos o modo de confirmação sincronizado e ambas as réplicas participando da confirmação de dados
    • Vemos o mesmo valor LSN no last_hardended_lsn nas réplicas primária e secundária. Também é igual a last_sent_lsn na instância SQLNode INST1
  • Na segunda imagem, capturamos a mesma saída após suspender a movimentação de dados entre a réplica primária e secundária
    • Como a réplica secundária não está participando da confirmação (estado suspenso), você pode ver o valor 0 para a réplica secundária SQLNode INST1. Isso mostra que até nós configuramos o commit de dados síncrono, mas desta vez, AG trabalhando como um commit assíncrono
    • Podemos ver a diferença no last_hardened_lsn de ambas as réplicas. No estado suspenso, a réplica secundária não pode receber os blocos de transação; portanto, ele não aplica nenhum log no banco de dados secundário
  • Na terceira imagem, capturamos os dados após retomar a movimentação de dados
    • Ele novamente marca o valor is_commit_participant como 1 porque a réplica secundária obtém novamente um status sincronizado
    • Ele novamente corresponde ao last_hardened_lsn para ambas as réplicas

Monitore os números de sequência de registro

Conclusão

Neste artigo, exploramos os movimentos de suspensão e retomada de dados nos grupos de disponibilidade Always On do SQL Server. Você deve retomar a movimentação de dados assim que seu trabalho for concluído, para que o crescimento do log de transações esteja no controle do banco de dados de réplica primário.

Índice

Rajendra Gupta
Últimos posts de Rajendra Gupta (ver tudo)