Compartilhar via

Replicação, controle de alterações e Change Data Capture – grupos de disponibilidade AlwaysOn

Aplica-se a:SQL Server

SQL Server Há suporte para a replicação, a CDC (captura de dados de alteração) e o CT (controle de alterações) no Grupos de disponibilidade AlwaysOn. O Grupos de disponibilidade AlwaysOn fornece alta disponibilidade e outros recursos de recuperação de banco de dados.

Visão geral da replicação com grupos de disponibilidade

Redirecionamento do publicador

Quando um banco de dados publicado reconhecer o Grupos de disponibilidade AlwaysOn, o distribuidor que fornece ao agente acesso a esse banco de dados será configurado com as entradas de redirected_publishers. Essas entradas redirecionam o par de publicador/banco de dados configurado originalmente, usando um nome do ouvinte do grupo de disponibilidade para conectar-se ao publicador e ao banco de dados de publicação. As conexões estabelecidas por meio do nome do ouvinte do grupo de disponibilidade falham no failover. Quando o agente de replicação é reiniciado após o failover, a conexão é redirecionada automaticamente para o novo primário.

Em um AG (grupo de disponibilidade), um banco de dados secundário não pode ser um publicador. Há suporte para a republicação apenas quando a replicação transacional é combinada com o Grupos de disponibilidade AlwaysOn.

Se um banco de dados publicado for membro de um grupo de disponibilidade e o publicador for redirecionado, ele deverá ser redirecionado para um nome de ouvinte de grupo de disponibilidade associado ao grupo de disponibilidade. Pode não ser redirecionado para um nó explícito.

Observação

Após o failover para uma réplica secundária, o Replication Monitor não consegue ajustar o nome da instância de publicação do SQL Server e continua exibindo informações de replicação sob o nome da instância primária original do SQL Server. Após o failover, um token de rastreamento não pode ser inserido usando o Replication Monitor, no entanto, um token de rastreamento inserido no novo editor usando o Transact-SQL fica visível no Replication Monitor.

Alterações gerais nos agentes de replicação para dar suporte a grupos de disponibilidade

Três agentes de replicação foram modificados para dar suporte ao Grupos de disponibilidade AlwaysOn. O Leitor de Log, o Instantâneo e os Agentes de mesclagem foram modificados para consultar o banco de dados de distribuição para o publicador redirecionado e para usar o nome do ouvinte do grupo de disponibilidade retornado, se um publicador redirecionado tiver sido declarado, para conectar-se ao publicador de banco de dados.

Por padrão, quando os agentes consultam o distribuidor para determinar se o publicador original foi redirecionado, a adequação do destino ou redirecionamento atual é verificada antes de retornar o host redirecionado ao agente. Esse é o comportamento recomendado. No entanto, se a inicialização do agente ocorrer com frequência, a sobrecarga associada ao procedimento armazenado de validação poderá ser considerada muito dispendiosa. Uma nova opção de linha de comando, BypassPublisherValidation, foi adicionada aos agentes de Leitor de log, Instantâneo e Mesclagem. Quando o comutador é usado, o publicador redirecionado é retornado imediatamente ao agente e a execução do procedimento armazenado de validação é ignorada.

As falhas retornadas do procedimento armazenado de validação são registradas nos logs de histórico do agente. Esses erros com gravidade maior ou igual a 16 fazem com que os agentes sejam encerrados. Alguns recursos de tentar novamente foram embutidos para os agentes tratarem a desconexão esperada de um banco de dados publicado quando ocorrer failover para um novo primário.

Modificações do agente de leitor de log

O agente de leitor de log tem as seguintes alterações.

  • Consistência de banco de dados replicada

    Quando um banco de dados publicado é membro de um grupo de disponibilidade, por padrão, o leitor de log não processa registros de log que ainda não foram protegidos em todas as réplicas secundárias do grupo de disponibilidade. Isso garante que, durante um failover, todas as linhas replicadas para um assinante também estejam presentes no novo primário.

    Quando o editor tem apenas duas réplicas de disponibilidade (uma primária e uma secundária) e ocorre um failover, a réplica primária original permanece inoperante porque o leitor de log não avança até que todos os bancos de dados secundários sejam colocados online novamente ou até que as réplicas secundárias com falha sejam removidas do grupo de disponibilidade. O leitor de log, agora em execução no banco de dados secundário, não prossegue, pois o AG não pode proteger nenhuma alteração em nenhum banco de dados secundário. Para permitir que o leitor de log continue e ainda tenha a capacidade de recuperação de desastres, remova a réplica primária original do grupo de disponibilidade usando ALTER AVAILABITY GROUP <nome_do_grupo> REMOVE REPLICA. Em seguida, adicione uma nova réplica secundária ao grupo de disponibilidade.

  • Sinalizador de rastreamento 1448

    O sinalizador de rastreamento 1448 permite que o leitor de log de replicação avance mesmo que as réplicas secundárias assíncronas não tenham reconhecido a recepção de uma alteração. Mesmo com esse sinalizador de rastreamento habilitado, o leitor de log sempre aguarda as réplicas secundárias síncronas (elas podem se tornar modo de confirmação assíncrona, para que o leitor de log possa avançar). O leitor de log não vai além da min ack das réplicas secundárias síncronas. Ele se aplica à instância do SQL Server, e não apenas a um grupo de disponibilidade, um banco de dados de disponibilidade ou uma instância do leitor de log. Esse sinalizador de rastreamento deve ser habilitado na instância do editor. Ele entra em vigor imediatamente sem uma reinicialização. Ele pode ser ativado antecipadamente ou quando uma réplica secundária assíncrona apresentar falha.

Procedimentos armazenados que dão suporte a grupos de disponibilidade

  • sp_redirect_publisher

    O procedimento armazenado sp_redirect_publisher é usado para especificar um publicador redirecionado para um par de publicador/banco de dados existente. Se o banco de dados publicador pertencer a um grupo de disponibilidade, o publicador redirecionado será o nome do ouvinte do grupo de disponibilidade.

  • sp_get_redirected_publisher

    O procedimento armazenado sp_get_redirected_publisher é usado por agentes de replicação para consultar um distribuidor para determinar se um par de publicador/banco de dados tem um publicador redirecionado definido. Esse procedimento armazenado atende a dois objetivos. Primeiro, permite que o agente determine se o publicador original foi redirecionado. Em segundo lugar, também pode iniciar uma execução de procedimento armazenado de validação no distribuidor (sp_validate_redirected_publisher) que verifica a adequação do nó de destino do redirecionamento para servir como um editor para o banco de dados nomeado.

    Para executar esse procedimento armazenado, o chamador deve ser membro da função de servidor sysadmin , da função de banco de dados db_owner para o banco de dados de distribuição ou membro de uma Lista de Acesso à Publicação para uma publicação definida associada ao banco de dados publicador.

  • sp_validate_redirected_publisher

    Este procedimento armazenado tenta validar se o publicador atual pode hospedar o banco de dados publicado. Ele pode ser chamado a qualquer momento para verificar se o host atual do banco de dados publicado pode dar suporte à replicação.

  • sp_validate_replicate_hosts_as_publishers

    Embora seja útil para os agentes garantir que o primário atual possa funcionar como o publicador de replicação de um banco de dados publicador, uma funcionalidade de validação mais geral é necessária para estabelecer a validade de uma topologia de replicação inteira em um banco de dados do grupo de disponibilidade. O procedimento sp_validate_replica_hosts_as_publishers armazenado foi projetado para preencher essa necessidade.

    Esse procedimento armazenado sempre é executado manualmente. O chamador deve ser sysadmin no distribuidor, dbowner do banco de dados de distribuição ou membro da Lista de Acesso à Publicação de uma publicação do banco de dados publicador. Além disso, o logon do chamador deve ser válido para todos os hosts de réplica de disponibilidade e ter privilégios selecionados no banco de dados de disponibilidade associado ao banco de dados publicador.

Captura de dados de alterações

Os bancos de dados habilitados para CDC (Change Data Capture) podem usar o Grupos de disponibilidade AlwaysOn para garantir não apenas que o banco de dados permaneça disponível em caso de falha, mas que as alterações nas tabelas de banco de dados continuem sendo monitoradas e depositadas nas tabelas de alterações de CDC. A ordem na qual os grupos de disponibilidade CDC e Always On estão configurados não é importante. Bancos de dados habilitados para CDC podem ser adicionados a grupos de disponibilidade Always On e bancos de dados que são membros de um grupo de disponibilidade podem ser habilitados para CDC. Porém, nos dois casos, a configuração de CDC sempre é executada na réplica primária atual ou pretendida. O CDC usa o agente de leitor de log e tem as mesmas limitações descritas na seção modificações do agente de leitor de log anteriormente neste artigo.

  • Coleta de alterações para captura de dados de alteração sem replicação

    Se o CDC estiver habilitado para um banco de dados, mas a replicação não for, o processo de captura usado para coletar alterações do log e depositá-las em tabelas de alteração CDC será executado no host CDC como seu próprio trabalho do SQL Agent.

    Para retomar a coleta de alterações depois de um failover, o procedimento armazenado sp_cdc_add_job deve ser executado no novo primário para criar o trabalho de captura local.

    No exemplo a seguir, é criado o trabalho de captura.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Coleta de alterações para captura de dados de alteração com replicação

    Se o CDC e a replicação estiverem habilitados para um banco de dados, o leitor de log tratará da população das tabelas de alteração do CDC. Nesse caso, as técnicas usadas pela replicação para usar grupos de disponibilidade Always On garantem que as alterações continuem a ser colhidas do log e depositadas nas tabelas de alterações CDC após o failover. Não é necessário fazer nada mais para o CDC nesta configuração para garantir que as tabelas de alteração sejam preenchidas.

  • Alterar a limpeza da captura de dados

    Para garantir que a limpeza apropriada ocorra no novo banco de dados primário, um trabalho de limpeza local sempre deve ser criado. No exemplo a seguir, é criado o trabalho de limpeza.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Observação

    Você deve criar os trabalhos na nova réplica primária após o failover. Os trabalhos de CDC em execução no banco de dados primário antigo devem ser desabilitados quando o banco de dados local se torna um banco de dados secundário. Se a réplica original se tornar primária novamente, você precisará reabilitar os trabalhos CDC na réplica dessa réplica. Para desabilitar e habilitar trabalhos, use a opção @enabled de sp_update_job. Para obter mais informações sobre como criar trabalhos CDC, consulte sys.sp_cdc_add_job.

  • Adicionando funções CDC a uma réplica de banco de dados primário

    Quando uma tabela está habilitada para CDC, é possível associar uma função de banco de dados à instância de captura. Se uma função for especificada, o usuário que quiser usar as funções com valor de tabela do CDC para acessar as alterações para a tabela não somente terá que ter acesso de seleção às colunas de tabela rastreadas, mas também deverá ser um membro da função nomeada. Se a função especificada ainda não existir, a função será criada. Quando as funções de banco de dados são adicionadas automaticamente a um banco de dados primário em um grupo de disponibilidade, as funções também são propagadas para os bancos de dados secundários do grupo de disponibilidade.

  • Aplicativos cliente que acessam dados de alteração CDC e grupos de disponibilidade

    Aplicativos cliente que usam as TVFs (funções com valor de tabela) ou os servidores vinculados para acessar dados da tabela de alteração também precisam da capacidade de localizar um host de CDC apropriado depois do failover. O nome do ouvinte do grupo de disponibilidade é o mecanismo fornecido pelo Grupos de disponibilidade AlwaysOn para permitir que uma conexão sempre seja redirecionada para um host diferente de modo transparente. Depois que um nome de ouvinte do grupo de disponibilidade estiver associado a um grupo de disponibilidade, ele estará disponível para ser usado em cadeias de conexão TCP. Dois cenários de conexão diferentes têm suporte por meio do nome do ouvinte do grupo de disponibilidade.

    • Um garante que as solicitações de conexão sejam sempre direcionadas para a réplica primária atual.
    • O outro garante que as solicitações de conexão sejam direcionadas para uma réplica secundária somente leitura.

    Se for usado para localizar uma réplica secundária somente leitura, uma lista de roteamento somente leitura também deverá ser definida para o grupo de disponibilidade. Para obter mais informações sobre o roteamento de acesso a secundários legíveis, consulte Configurar o roteamento somente leitura para um grupo de disponibilidade Always On.

    Observação

    Há algum atraso de propagação associado à criação de um nome de ouvinte de grupo de disponibilidade e seu uso por aplicativos cliente para acessar uma réplica de banco de dados do grupo de disponibilidade.

    Use a consulta a seguir para determinar se um nome do ouvinte do grupo de disponibilidade foi definido para o grupo de disponibilidade que hospeda um banco de dados do CDC. A consulta retornará o nome do ouvinte do grupo de disponibilidade se um tiver sido criado.

    SELECT dns_name
FROM sys.availability_group_listeners AS l
     INNER JOIN sys.availability_databases_cluster AS d
         ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

  • Redirecionando a carga da consulta para uma réplica secundária legível

    Embora, em muitos casos, um aplicativo cliente sempre queira se conectar à réplica primária atual, essa não é a única maneira de usar grupos de disponibilidade Always On. Se um grupo de disponibilidade for configurado para dar suporte a réplicas secundárias legíveis, os dados de alteração também poderão ser coletados a partir de nós secundários.

    Quando um grupo de disponibilidade estiver configurado, o atributo ALLOW_CONNECTIONS associado à SECONDARY_ROLE será usado para especificar o tipo de acesso secundário com suporte. Se configurado como ALL, todas as conexões com o secundário serão permitidas, mas somente aquelas que exigem acesso somente leitura terão êxito. Se configurado como READ_ONLY, é necessário especificar a intenção somente leitura ao fazer a conexão com o banco de dados secundário para que a conexão seja bem-sucedida. Para obter mais informações, consulte Configurar o acesso somente leitura a uma réplica secundária de um grupo de disponibilidade Always On.

    A consulta a seguir pode ser usada para determinar se a intenção somente leitura é necessária para estabelecer a conexão com uma réplica secundária legível.

    SELECT g.name AS AG,
          replica_server_name,
          secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
     INNER JOIN sys.availability_groups AS g
          ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME';

    O nome do ouvinte do grupo de disponibilidade ou o nome de nó explícito pode ser usado para localizar a réplica secundária. Se o nome do ouvinte do grupo de disponibilidade for usado, o acesso será direcionado para qualquer réplica secundária adequada.

    Quando sp_addlinkedserver é usado para criar um servidor vinculado para acessar o secundário, o parâmetro @datasrc é usado para o nome do ouvinte do grupo de disponibilidade ou o nome do servidor explícito e o parâmetro @provstr é usado para especificar a intenção somente leitura.

    EXECUTE sp_addlinkedserver
    @server = N'linked_svr',
    @srvproduct = N'SqlServer',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'AG_Listener_Name',
    @provstr = N'ApplicationIntent=ReadOnly',
    @catalog = N'MY_DB_NAME';

  • Acesso do cliente a dados de alteração cdc e logons de domínio

    Em geral, você deve usar logons de domínio para o acesso do cliente para alterar os dados que residem em bancos de dados que são membros de grupos de disponibilidade. Para garantir o acesso contínuo à alteração de dados após o failover, o usuário do domínio precisa de privilégios de acesso em todos os hosts que dão suporte a réplicas de grupo de disponibilidade. Se um usuário de banco de dados for adicionado a um banco de dados em uma réplica primária, e o usuário estiver associado com um logon de domínio, o usuário de banco de dados será propagado para bancos de dados secundários e continua sendo associado com o logon de domínio especificado. Se o novo usuário do banco de dados estiver associado a um logon de autenticação do SQL Server, o usuário nos bancos de dados secundários será propagado sem um logon. Embora o logon de autenticação do SQL Server associado pudesse ser usado para acessar dados de alteração no primário onde o usuário de banco de dados foi definido originalmente, esse nó é o único em que o acesso seria possível. O logon de autenticação do SQL Server não seria capaz de acessar dados de nenhum banco de dados secundário, nem de nenhum novo banco de dados primário diferente do banco de dados original em que o usuário do banco de dados foi definido.

  • Desabilitando a captura de dados de alteração

    Se você precisar desabilitar o CDC (Change Data Capture) em um banco de dados que faz parte de um grupo de disponibilidade e estiver no SQL Server 2016 SP2 ou posterior, não será necessário executar nenhuma etapa extra para truncamento automático de log. Se você estiver em uma versão anterior do SQL Server 2016 SP2 e desabilitar o CDC em um banco de dados que faça parte de um grupo de disponibilidade, será necessário implementar uma das seguintes etapas para impedir o bloqueio do truncamento de logs depois que o CDC for desabilitado:

    • Reinicie o serviço SQL Server em cada instância da réplica secundária.

    • Remova o banco de dados de todas as instâncias da réplica secundária do grupo de disponibilidade e adicione-o às instâncias da réplica do grupo de disponibilidade usando a propagação automática ou manual.

Controle de alterações

Um banco de dados habilitado para CT (controle de alterações) pode fazer parte de um grupo de disponibilidade. Nenhuma configuração adicional é necessária. Os aplicativos cliente de controle de alterações que usam as TVFs (funções com valor de tabela) CDC para acessar dados de alteração precisam da capacidade de localizar a réplica primária após o failover. Se o aplicativo cliente se conectar por meio do nome do ouvinte do grupo de disponibilidade, as solicitações de conexão serão sempre direcionadas adequadamente para a réplica primária atual.

Os dados de controle de alterações sempre devem ser obtidos da réplica primária. Uma tentativa de acessar dados de alteração de uma réplica secundária resulta no seguinte erro:

Msg 22117, Level 16, State 1, Line 1

Para bancos de dados que são membros de uma réplica secundária (ou seja, para bancos de dados secundários), não há suporte para controle de alterações. Como alternativa à execução de consultas de controle de alterações na réplica primária, você pode criar um instantâneo do banco de dados AG da réplica secundária e usá-lo para consultar os dados de alteração. Um instantâneo de banco de dados é uma exibição estática somente leitura de um banco de dados do SQL Server (o banco de dados de origem), portanto, a alteração dos dados de controle no instantâneo do banco de dados é do momento em que o instantâneo foi tirado no banco de dados do AG da réplica secundária.

Observação

Quando ocorre um failover em um banco de dados com o controle de alterações habilitado, o tempo de recuperação na nova réplica primária pode levar mais tempo do que o normal, pois o controle de alterações requer uma reinicialização completa do banco de dados.

Pré-requisitos, restrições e considerações para usar a replicação

Esta seção descreve as considerações para implantar a replicação com o Grupos de disponibilidade AlwaysOn, incluindo pré-requisitos, restrições e recomendações.

Pré-requisitos

  • Ao usar a replicação transacional e o banco de dados de publicação estiver em um grupo de disponibilidade, o publicador e o distribuidor deverão executar pelo menos o SQL Server 2012 (11.x). O assinante pode usar um nível inferior do SQL Server.

  • Ao usar a replicação de mesclagem e o banco de dados de publicação estiver em um grupo de disponibilidade:

    • Assinatura push: o publicador e o distribuidor devem ser executados pelo menos no SQL Server 2012 (11.x).

    • Assinatura por pull: os bancos de dados publicador, distribuidor e assinante devem estar pelo menos no SQL Server 2012 (11.x). Isso ocorre porque o agente de mesclagem no assinante deve entender como um grupo de disponibilidade pode fazer failover para seu secundário.

  • As instâncias do Publicador atendem a todos os pré-requisitos necessários para participar de um grupo de disponibilidade. Para obter mais informações, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

Restrições

Combinações de replicação com suporte no Grupos de disponibilidade AlwaysOn:

Replicação Publicador Distribuidor 1 Subscriber
Transacional. Sim

Observação: não inclui suporte para replicação transacional bidirecional e recíproca.		 Sim Sim
Ponto a ponto2 Sim Sim 3 Sim
Mesclagem Sim Não Não
Instantâneo Sim Não Sim
Assinaturas atualizáveis – para replicação transacional Não Não Não

1 O banco de dados distribuidor não tem suporte para uso com espelhamento de banco de dados.

2 Requer o SQL Server 2019 CU 13 ou posterior.

3 Exige o SQL Server 2019 CU 17 ou posterior.

Considerações

  • O banco de dados de distribuição não tem suporte para uso com espelhamento de banco de dados, mas tem suporte com grupos de disponibilidade Always On sujeitos a determinadas limitações. Para obter mais informações, consulte Configurar Grupo de Disponibilidade de Distribuição. A configuração de replicação é acoplada à instância do SQL Server em que o Distribuidor está configurado; portanto, o banco de dados de distribuição não pode ser espelhado ou replicado. Também é possível fornecer alta disponibilidade para o Distribuidor usando um cluster de failover do SQL Server. Para obter mais informações, consulte Instâncias de Cluster de Failover Always On (SQL Server).

  • Embora haja suporte para o failover do assinante em um banco de dados secundário, esse é um procedimento manual para assinantes de replicação de mesclagem. O procedimento é essencialmente idêntico ao método usado para failover de um banco de dados de assinante espelhado. Os assinantes de replicação transacional não precisam de tratamento especial durante a participação em grupos de disponibilidade Always On. Os assinantes devem estar executando o SQL Server 2012 (11.x) ou posterior para participar de um grupo de disponibilidade. Para obter mais informações, consulte Assinantes da Replicação e grupos de disponibilidade AlwaysOn (SQL Server)

  • Metadados e objetos que existem fora do banco de dados não são propagados para as réplicas secundárias, incluindo logons, trabalhos, servidores vinculados. Se você precisar dos metadados e dos objetos no novo banco de dados primário após o failover, copie-os manualmente. Para obter mais informações, consulte Gerenciar logons para trabalhos usando bancos de dados em um grupo de disponibilidade Always On.

Grupos de disponibilidade distribuídos

O publicador ou banco de dados de distribuição em um Grupo de Disponibilidade não pode ser configurado como parte de um Grupo de Disponibilidade Distribuída. O banco de dados editor e o banco de dados de distribuição em um Grupo de Disponibilidade exigem um ponto de extremidade ouvinte para configuração e uso adequados. No entanto, não é possível configurar um ponto de extremidade de ouvinte para um grupo de Disponibilidade Distribuída.

Replicação

Captura de dados de alterações

Controle de alterações

Conteúdo relacionado

  • Last updated on