Práticas recomendadas para link do Instância Gerenciada – Instância Gerenciada de SQL do Azure

Applies to:Instância Gerenciada de SQL do Azure

Este artigo descreve as práticas recomendadas para usar o link Instância Gerenciada para replicar dados entre Instância Gerenciada de SQL do Azure e suas instâncias de SQL Server hospedadas em qualquer lugar. O link fornece replicação de dados quase em tempo real entre as réplicas vinculadas.

Realize backups de logs regularmente

Se o SQL Server for seu primário inicial, faça o primeiro backup de log no SQL Server depois de terminar a semeadura inicial, quando o banco de dados não estiver mais no estado de Restaurando... na Instância Gerenciada do Azure SQL. Em seguida, faça backups de log de transações SQL Server regularmente para manter o tamanho do arquivo de log de transações íntegro enquanto SQL Server estiver na função primária.

O recurso de link replica dados usando a tecnologia de grupos de disponibilidade distribuídos com base nos Grupos de Disponibilidade Always On. A replicação de dados do grupo de disponibilidade distribuída baseia-se na replicação de registros de log de transações. A instância primária do SQL Server não pode truncar quaisquer registros de log de transação do banco de dados até que sejam replicados para a réplica secundária do banco de dados. Se problemas de conexão de rede fizerem com que a replicação do registro de log de transações seja lenta ou bloqueada, o arquivo de log continua crescendo na instância primária. A intensidade da carga de trabalho e a velocidade da rede determinam a velocidade de crescimento. Se uma interrupção de conexão de rede for prolongada e a carga de trabalho na instância primária for pesada, o arquivo de log poderá ocupar todo o espaço de armazenamento disponível.

Fazer backups regulares do log de transações trunca o log e minimiza o risco de ficar sem espaço na instância primária do SQL Server devido ao crescimento do arquivo de log. Nenhuma ação extra é necessária quando Instância Gerenciada de SQL é o principal, pois os backups de log já são feitos automaticamente. Ao fazer backups de log regularmente em seu SQL Server primário, você torna seu banco de dados mais resiliente a eventos de crescimento de log não planejados. Considere agendar tarefas diárias de backup de log usando um trabalho de SQL Server Agent.

Você pode usar um script Transact-SQL (T-SQL) para fazer backup do arquivo de log, como o exemplo fornecido nesta seção. Substitua os espaços reservados no script de exemplo pelo nome do seu banco de dados, o nome e o caminho do arquivo de backup e sua descrição.

Para fazer backup do log de transações, use o seguinte script de Transact-SQL de exemplo (T-SQL) no SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Use o seguinte comando Transact-SQL (T-SQL) para verificar o log espaçado usado pelo banco de dados no SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

A saída da consulta é semelhante ao exemplo a seguir para o banco de dados de amostra tpcc:

Nesse exemplo, o banco de dados usou 76% do log disponível, com um tamanho de arquivo de log absoluto de aproximadamente 27 GB (27,971 MB). Os limites para ação variam com base na sua carga de trabalho. No exemplo anterior, o tamanho do log de transações e o percentual de uso do log normalmente indicam que você deve fazer um backup de log de transações para truncar o arquivo de log e liberar algum espaço ou fazer backups de log mais frequentes. Também pode ser um indicativo de que transações abertas estão bloqueando o truncamento do log de transações. Para obter mais informações sobre como solucionar problemas de um log de transações no SQL Server, consulte Troubleshoot a Full Transaction Log (SQL Server Error 9002). Para obter mais informações sobre como solucionar problemas de um log de transações em Instância Gerenciada de SQL do Azure, consulte Troubleshoot transaction log errors with Instância Gerenciada de SQL do Azure.

Equilibrar a capacidade de desempenho entre réplicas

Ao usar o recurso de link, equipare a capacidade de desempenho entre SQL Server e Instância Gerenciada de SQL. Essa correspondência auxilia a evitar problemas de performance caso a réplica secundária não consiga acompanhar a replicação da réplica primária ou após o failover. A capacidade de desempenho inclui núcleos de CPU (ou vCores em Azure), memória e taxa de transferência de E/S.

Você pode monitorar o desempenho da replicação verificando o tamanho da fila de refazer na réplica secundária. O tamanho da fila de refazer mostra o número de registros de log que estão esperando para serem refeitos na réplica secundária. Um tamanho de fila de refazer consistentemente alto mostra que a réplica secundária não pode acompanhar a réplica primária. Você pode verificar o tamanho da fila de refazer das seguintes maneiras:

• O valor de redo_queue_size no visor de gerenciamento dinâmico sys.dm_hadr_database_replica_states na réplica primária.
• O valor de InstanceRedoLagReplicationSeconds em Get-AzSqlInstanceLink na réplica primária.

Se o tamanho da fila de restauração for consistentemente alto, considere aumentar os recursos na réplica secundária.

Monitorar o atraso de replicação

O monitoramento do atraso de replicação ajuda a determinar a rapidez com a qual a réplica secundária se sincroniza com a réplica primária. Uma grande discrepância indica que a réplica secundária está tendo problemas para acompanhar a réplica primária, que normalmente é causada pela taxa de transferência de rede lenta no vínculo entre as duas instâncias, alocação de recursos incompatível entre as duas réplicas ou por uma carga de trabalho excessivamente alta na réplica primária.

O monitoramento do atraso de replicação é especialmente importante ao executar um failover planejado, o que exige que a réplica secundária seja totalmente sincronizada com a réplica primária antes que o failover possa ser executado. Se o atraso de replicação for alto, o failover poderá levar mais tempo para ser concluído e, em alguns casos, pode até falhar.

Use a seguinte consulta T-SQL em SQL Server e Instância Gerenciada de SQL para monitorar o atraso de replicação entre as réplicas:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Rotação de Certificado

Talvez seja necessário girar manualmente o certificado usado para proteger o ponto de extremidade de espelhamento de banco de dados em SQL Server. Como o serviço gerencia e renova automaticamente o certificado usado para proteger o endpoint de espelhamento de banco de dados em Instância Gerenciada de SQL, você não precisa renová-lo manualmente.

SQL Server

O certificado que você usa para proteger o endereço de rede de espelhamento de banco de dados no SQL Server pode expirar. Se o certificado expirar, ele poderá gerar degradação de vínculo. Para evitar esse problema, renove o certificado antes de expirar.

Use o seguinte comando Transact-SQL (T-SQL) para verificar a data de validade do certificado atual:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

Se o certificado estiver prestes a expirar ou já tiver expirado, crie um novo certificado e altere o ponto de extremidade existente para substituir o certificado atual.

Depois de configurar o ponto de extremidade para usar o novo certificado, você poderá descartar o certificado expirado.

Instância Gerenciada de SQL

O certificado do ponto de extremidade de espelhamento do banco de dados em Instância Gerenciada de SQL é rotacionado automaticamente em intervalos regulares. Você não precisa monitorar a data de validade do certificado de ponto de extremidade de espelhamento de banco de dados no Instância Gerenciada de SQL, desde que possa validar a cadeia de certificados em SQL Server com êxito.

Validar a cadeia de certificados no SQL Server

Problemas com a cadeia de certificados podem prejudicar o link. Para evitar esse problema, validarregularmente a cadeia de certificados em SQL Server.

Os seguintes cenários podem causar problemas com a cadeia de certificados no SQL Server:

• Rotação de certificado agendada em Instância Gerenciada de SQL.
• Alterações não intencionais ou acidentais nos certificados do SQL Server, como remover ou alterar o certificado usado para proteger o endpoint de espelhamento de banco de dados.

Primeiro, determine o certificate_id do certificado de ponto de extremidade MI importado substituindo o valor de <ManagedInstanceFQDN> e, em seguida, executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

Em seguida, valide o certificado substituindo o valor de <certificate_id> do resultado da consulta anterior e, em seguida, executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Uma resposta de Commands completed successfully. Completion time: ... indica que o certificado do ponto de extremidade MI foi validado com êxito.

Se você encontrar um erro, a mitigação mais confiável será restaurar a cadeia de certificados primeiro excluindo todos os certificados criados nas seções Obter a chave pública do certificado da Instância Gerenciada do SQL e importá-la para o SQL Server e Importar chaves da autoridade certificadora confiáveis pela Azure para o SQL Server e, em seguida, reimportá-los novamente.

Adicionar sinalizadores de rastreamento na inicialização

Em SQL Server, há dois sinalizadores de rastreamento (-T1800 e -T9567) que, quando adicionados como parâmetros de inicialização, podem otimizar o desempenho da replicação de dados por meio do link. Veja Habilitar sinalizadores de rastreamento de inicialização para saber mais.

Utilize a confirmação síncrona com cuidado

O modo de confirmação padrão para o link é assíncrono. Embora seja possível alterar o modo de confirmação para síncrono, não é recomendável e não é necessário se proteger contra possíveis perdas de dados.

Durante um failover vinculado planejado, a replicação alterna temporariamente para o modo de confirmação síncrona até que o failover seja concluído. Após o failover, o modo de confirmação retorna para assíncrono, mesmo que tenha sido explicitamente configurado como modo de confirmação síncrono antes do failover.

O uso do modo de confirmação síncrona para o link pode afetar o desempenho da réplica primária, especialmente se houver alta latência de rede entre as réplicas. No modo de confirmação síncrona, as transações na réplica primária devem aguardar a confirmação de que os registros de log de transações são protegidos na réplica secundária antes que a transação possa ser confirmada no primário. Esse tempo de espera aumenta com maior latência de rede, o que pode levar ao aumento dos tempos de resposta da transação e à redução da taxa de transferência na réplica primária.

Conteúdo relacionado

Para usar o link:

• Preparar o ambiente para o link da Instância Gerenciada
• Configurar link entre SQL Server e Instância Gerenciada do SQL com SSMS
• Configurar link entre SQL Server e instância gerenciada do SQL com scripts
• Efetuar failover do link
• Migrar com o link
• Solucionar problemas com o link

Para saber mais sobre o link:

• Visão geral do link de Instância Gerenciada
• Recuperação de desastres com link de Instância Gerenciada
• As melhores práticas para manter o link

Para outros cenários de replicação e migração, considere:

• Replicação transacional com Instância Gerenciada de SQL
• LRS (Serviço de Reprodução de Log)