Partilhar via

Replicação, rastreio de alterações, & captura de dados de alterações - Grupos de disponibilidade Always On

  • Artigo

Aplica-se a:SQL Server

A replicação do SQL Server, a captura de dados de alteração (CDC) e o controle de alterações (CT) são suportados em grupos de disponibilidade Always On. Os grupos de disponibilidade Always On ajudam a fornecer 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 está ciente dos grupos de disponibilidade Always On, o distribuidor que fornece acesso de agente ao banco de dados de publicação é configurado com entradas redirected_publishers. Essas entradas redirecionam o par editor/banco de dados originalmente configurado, fazendo uso de um nome de ouvinte do grupo de disponibilidade para se conectar ao editor 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 principal.

Num grupo de disponibilidade (AG), um banco de dados secundário não pode ser um publicador. A republicação só é suportada quando a replicação transacional é combinada com grupos de disponibilidade Always On.

Se um banco de dados publicado for membro de um grupo de disponibilidade e o editor for redirecionado, ele deverá ser redirecionado para um nome de ouvinte do grupo de disponibilidade associado ao grupo de disponibilidade. Ele 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 a exibir 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 através do Replication Monitor; no entanto, um token de rastreamento inserido no novo publicador através do 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 oferecer suporte a grupos de disponibilidade Always On. Os agentes Leitor de Log, Instantâneo e Mesclagem foram modificados para consultar a base de dados de distribuição do publicador redirecionado e para utilizar o nome do ouvinte do grupo de disponibilidade retornado, caso um publicador redirecionado tenha sido declarado, para se ligar ao publicador da base de dados.

Por padrão, quando os agentes consultam o distribuidor para determinar se o editor original foi redirecionado, a adequação do destino ou redirecionamento atual é verificada antes de retornar o servidor redirecionado ao agente. Esse 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 Log reader, Snapshot e Merge. Quando o switch é usado, o editor 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. Os erros com gravidade igual ou superior a 16 fazem com que os agentes terminem. Alguns recursos de repetição foram incorporados aos agentes para lidar com a desconexão esperada de um banco de dados publicado quando ele faz transição para um novo servidor primário.

Modificações do agente de leitura de logs

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

  • Consistência do banco de dados replicado

    Quando um banco de dados publicado é membro de um grupo de disponibilidade, por padrão, o leitor de logs 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 o 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 inativa porque o leitor de logs 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 logs, agora em execução no banco de dados secundário, não avança, pois o AG não pode confirmar quaisquer alterações em qualquer banco de dados secundário. Para permitir que o leitor de logs prossiga e ainda tenha capacidade de recuperação de desastres, remova a réplica primária original do grupo de disponibilidade usando "ALTER AVAILABILITY GROUP <group_name> REMOVE REPLICA". Em seguida, adicione uma nova réplica secundária ao grupo de disponibilidade.

  • Flag de Rastreio 1448

    O Sinalizador de Rastreamento 1448 permite que o leitor de logs de replicação avance mesmo que as réplicas secundárias assíncronas não tenham reconhecido a receção de uma alteração. Mesmo com este sinalizador de rastreamento habilitado, o leitor de log sempre aguarda as réplicas secundárias síncronas (elas podem se tornar assíncronas no modo de confirmação, conforme documentado aqui, para que o leitor de log possa avançar). O leitor de logs não ultrapassa a confirmação mínima das réplicas secundárias síncronas. Esse sinalizador de rastreamento se aplica à instância do SQL Server, não apenas a um grupo de disponibilidade, um banco de dados de disponibilidade ou uma instância de leitor de log. Esse sinalizador de rastreamento deve ser habilitado na instância do editor. Entra em vigor imediatamente sem um reinício. Pode ser ativado antecipadamente ou em caso de falha de uma réplica secundária assíncrona.

Procedimentos armazenados que suportam grupos de disponibilidade

  • sp_redirect_publisher

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

  • sp_get_redirected_publisher

    O procedimento armazenado sp_get_redirected_publisher é utilizado por agentes de replicação para consultar um distribuidor e determinar se um par publicador/base de dados tem um publicador redirecionado definido. Este procedimento armazenado serve dois propósitos. Primeiro, ele permite que o agente determine se o editor original foi redirecionado. Em segundo lugar, também pode iniciar um procedimento armazenado de validação executado no distribuidor (sp_validate_redirected_publisher) que verifica a adequação do nó de destino do redirecionamento para servir como um publicador para a base de dados nomeada.

    Para executar este 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 de uma Lista de Acesso à Publicação para uma publicação definida associada ao banco de dados do editor.

  • sp_validate_redirected_publisher

    Este procedimento armazenado tenta validar se o editor atual é capaz de hospedar o banco de dados publicado. Ele pode ser chamado a qualquer momento para verificar se o host atual do banco de dados publicado é capaz de suportar replicação.

  • sp_validate_replicate_hosts_as_publishers

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

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

Alterar a captura de dados

Os bancos de dados habilitados para captura de dados de alteração (CDC) podem usar grupos de disponibilidade Always On 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 a ser monitoradas e depositadas nas tabelas de alteração CDC. A ordem na qual os grupos de disponibilidade CDC e Always On são configurados não é importante. Os bancos de dados habilitados para CDC podem ser adicionados aos grupos de disponibilidade Always On; além disso, os bancos de dados que são membros de um grupo de disponibilidade podem ser habilitados para CDC. Em ambos os casos, no entanto, a configuração CDC é sempre executada na réplica primária atual ou pretendida. O CDC usa o agente do leitor de logs e tem as mesmas limitações descritas na seção modificações do agente do leitor de log anteriormente neste artigo.

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

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

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

    O exemplo a seguir cria o trabalho de captura.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Recolha de alterações para captura de dados de mudanças com replicação

    Se o CDC e a replicação estiverem ativados para um banco de dados, o leitor de logs gerirá a população das tabelas de alteração CDC. Nesse caso, as técnicas usadas pela replicação para utilizar grupos de disponibilidade Always On garantem que as alterações continuem a ser extraídas do log e armazenadas nas tabelas de alterações do CDC após o failover. Nada mais precisa ser feito para o CDC nessa 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. O exemplo a seguir cria a tarefa 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 CDC em execução no banco de dados primário antigo devem ser desabilitados quando o banco de dados local se tornar um banco de dados secundário. Envie isto se a réplica voltar a ser primária, terá de reativar as tarefas de CDC na réplica. Para desativar e habilitar trabalhos, use a opção @enabled de sp_update_job. Para obter mais informações sobre como criar empregos CDC, consulte sys.sp_cdc_add_job.

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

    Quando uma tabela é habilitada para CDC, é possível associar uma função de banco de dados à instância de captura. Se uma função for especificada, o utilizador que deseja usar as funções CDC baseadas em tabelas para aceder às alterações da tabela não deve apenas ter acesso de seleção às colunas da tabela controlada, mas também deve ser 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 CDC alteram dados e grupos de disponibilidade

    Os aplicativos cliente que utilizam funções com valor de tabela (TVFs) ou servidores ligados para aceder a dados de tabelas de alterações também necessitam da capacidade de encontrar um host CDC adequado após o failover. O nome do ouvinte do grupo de disponibilidade é o mecanismo fornecido pelos grupos de disponibilidade Always On para permitir de forma transparente que uma conexão seja redirecionada para um host diferente. Quando um nome de ouvinte de grupo de disponibilidade é associado a um grupo de disponibilidade, ele fica disponível para ser usado em cadeias de conexão TCP. Dois cenários de conexão diferentes são suportados por meio do nome do ouvinte do grupo de disponibilidade.

    • Assegura-se que as solicitações de conexão sejam sempre direcionadas à réplica primária atual.
    • Assegura-se que as solicitações de conexão sejam direcionadas para uma réplica secundária somente leitura.

    Se for usada para localizar uma réplica secundária de leitura única, deverá ser definida também uma lista de roteamento de leitura única para o grupo de disponibilidade. Para obter mais informações sobre como rotear o 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 do 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 de ouvinte do grupo de disponibilidade foi definido para o grupo de disponibilidade que hospeda um banco de dados CDC. A consulta retorna 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';

  • Redirecionar 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 estiver configurado para oferecer suporte a réplicas secundárias legíveis, os dados de alteração também poderão ser coletados de nós secundários.

    Quando um grupo de disponibilidade é configurado, o atributo ALLOW_CONNECTIONS associado ao SECONDARY_ROLE é usado para especificar o tipo de acesso secundário suportado. Se configurado como ALL, todas as conexões com o secundário são permitidas, mas apenas aquelas que exigem acesso somente leitura são bem-sucedidas. Se configurado como READ_ONLY, é necessário especificar a intenção de somente leitura ao estabelecer a ligação ao banco de dados secundário para que a conexão seja bem-sucedida. Para mais informações, veja Configurar acesso de 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 se conectar a 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 explícito do nó podem ser usados 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 explícito do servidor, e o parâmetro @provstr é usado para especificar a intenção de 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 aos dados de alteração de CDC e logins de domínio

    Em geral, você deve usar logons de domínio para acesso de cliente para alterar dados residentes em bancos de dados que são membros de grupos de disponibilidade. Para garantir o acesso contínuo aos dados de alteração após o failover, o utilizador do domínio precisa de permissões de acesso em todos os hosts que suportam réplicas do 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 a um logon de domínio, o usuário do banco de dados será propagado para bancos de dados secundários e continuará a ser associado ao 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 possa ser usado para aceder a dados de modificações no servidor primário onde o utilizador da base de dados foi originalmente definido, esse nó é o único em que o acesso seria possível. O logon de autenticação do SQL Server não poderia acessar dados de nenhum banco de dados secundário, nem de nenhum novo banco de dados primário além do banco de dados original onde o usuário do banco de dados foi definido.

  • Desativar 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 precisará executar nenhuma etapa extra para truncamento automático de log. Se você estiver em uma versão anterior ao SQL Server 2016 SP2 e desabilitar o CDC em um banco de dados que faça parte de um grupo de disponibilidade, precisará implementar uma das seguintes etapas para evitar o bloqueio do truncamento de log após a desabilitação do CDC:

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

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

Monitorização de alterações

Um banco de dados habilitado para controle de alterações (CT) pode fazer parte de um grupo de disponibilidade. Não é necessária mais configuração. 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), o controle de alterações não é suportado. Como alternativa à execução de consultas de controle de alterações na réplica primária, você pode criar um instantâneo de banco de dados de um banco de dados AG a partir da réplica secundária e, em seguida, usá-lo para consultar dados de alteração. Um instantâneo de banco de dados é uma exibição estática somente leitura de um banco de dados SQL Server (o banco de dados de origem), portanto, os dados de controle de alterações no instantâneo do banco de dados são do momento em que o instantâneo foi tirado no banco de dados 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 o uso da replicação

Esta seção descreve as considerações para implantar a replicação com grupos de disponibilidade Always On, 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 editor e o distribuidor devem executar pelo menos o SQL Server 2012 (11.x). O assinante pode estar usando um nível inferior do SQL Server.

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

    • Assinatura por push: o editor e o distribuidor devem executar pelo menos o SQL Server 2012 (11.x).

    • Assinatura pull: as bases de dados de editor, distribuidor e subscritor devem estar pelo menos na versão 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 Publisher satisfazem 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 suportadas de replicação em grupos de disponibilidade Always On:

Replicação Editora Distribuidor 1 Assinante
Transacional Sim

Nota: Não inclui suporte para replicação transacional bidirecional e recíproca.		 Sim Sim
Peer-to-peer2 Sim Sim 3 Sim
Mesclar 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 do Distribuidor não é compatível para uso com espelhamento de banco de dados.

2 Requer o SQL Server 2019 CU 13 ou posterior.

3 Requer SQL Server 2019 CU 17 ou posterior.

Considerações

  • O banco de dados de distribuição não é suportado para uso com espelhamento de banco de dados, mas é suportado 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 onde 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).

  • O failover de assinantes para um banco de dados secundário, embora suportado, é um procedimento manual para assinantes de replicação de fusão. O procedimento é essencialmente idêntico ao método usado para fazer failover de um banco de dados de assinantes espelhado. Os assinantes da replicação transacional não necessitam de tratamento especial ao participarem em grupos de disponibilidade do 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 de replicação e grupos de disponibilidade Always On (SQL Server)

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

Grupos de disponibilidade distribuídos

O editor ou o 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. Os bancos de dados do editor em um Grupo de Disponibilidade e os bancos de dados de distribuição em um Grupo de Disponibilidade exigem um endpoint de escuta 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

Alterar a captura de dados

Rastreamento de alterações

Conteúdo relacionado