Partilhar via

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

Aplica-se a:Instância Gerenciada do SQL do Azure

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

Faça backups de log regularmente

Se o SQL Server for o seu primário, é importante fazer o primeiro backup de log no SQL Server após a sementeira inicial estar concluída, quando o banco de dados não estiver mais no estado de Restaurando... na Instância Gerida do SQL do Azure. Em seguida, faça backups de log de transações do SQL Server regularmente para manter um tamanho de arquivo de log de transações saudável enquanto o SQL Server estiver na função principal.

A funcionalidade de link replica dados usando a tecnologia de grupos de disponibilidade distribuída com base nos grupos de disponibilidade Always On. A replicação de dados com grupos de disponibilidade distribuídos baseia-se na replicação de registros de log de transações. Nenhum registro de log de transações pode ser truncado do banco de dados na instância primária do SQL Server até que seja replicado para o banco de dados na réplica secundária. Se a replicação do registro de log de transações estiver lenta ou bloqueada devido a problemas de conexão de rede, o arquivo de log continuará crescendo na instância primária. A velocidade de crescimento depende da intensidade da carga de trabalho e da velocidade da rede. Se houver uma interrupção prolongada da conexão de rede e uma carga de trabalho pesada na instância principal, 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 de transações 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 a Instância Gerenciada SQL é a principal, uma vez que backups de log já são feitos automaticamente. Ao fazer backups de log regularmente em seu SQL Server principal, 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 do 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 banco de dados, nome e caminho do arquivo de backup e a descrição.

Para fazer backup do log de transações, use o seguinte script de exemplo Transact-SQL (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 se parece com o exemplo a seguir para o banco de dados de exemplo tpcc:

Captura de tela com os resultados do comando mostrando o tamanho do arquivo de log e o espaço usado

Neste exemplo, o banco de dados usou 76% do log disponível, com um tamanho absoluto de arquivo de log de aproximadamente 27 GB (27.971 MB). Os limites para ação variam de acordo com a sua carga de trabalho. No exemplo anterior, o tamanho do log de transações e a porcentagem de uso do log geralmente são uma indicação de que você deve fazer um backup de log de transações para truncar o arquivo de log e liberar algum espaço, ou, você deve fazer backups de log mais frequentes. Pode também indicar que o truncamento do log de transações está a ser bloqueado por transações abertas. Para obter mais informações sobre como solucionar problemas de um log de transações no SQL Server, consulte Solucionar problemas de um log de transações completo (Erro 9002 do SQL Server). Para obter mais informações sobre como solucionar problemas de um log de transações na Instância Gerenciada SQL do Azure, consulte Solucionar erros de log de transações com a Instância Gerenciada SQL do Azure.

Observação

Ao participar em um link, backups automatizados completos e de logs de transações são obtidos da Instância Gerenciada SQL, seja ou não a réplica principal. Os backups diferenciais não são feitos, o que pode levar a tempos de restauração mais longos.

Combine a capacidade de desempenho entre réplicas

Ao usar o recurso de link, é importante combinar a capacidade de desempenho entre o SQL Server e a Instância Gerenciada do SQL para evitar problemas de desempenho se a réplica secundária não puder 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 no Azure), memória e taxa de transferência de E/S.

Você pode verificar o desempenho da replicação com o tamanho da fila de refazer na réplica secundária. O tamanho da fila de reaplicação indica o número de registos de log que estão à espera de serem reaplicados na réplica secundária. Um tamanho de fila de refazer consistentemente alto indica que a réplica secundária não consegue acompanhar a réplica primária. Você pode verificar o tamanho da fila de refazer das seguintes maneiras:

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

Rotacionar certificado

Pode ser necessário substituir manualmente o certificado usado para proteger o endpoint de espelhamento de base de dados no SQL Server. Como o certificado usado para proteger o endpoint de espelhamento da base de dados na Instância Gerida SQL é gerido pelo serviço e renovado automaticamente, não precisa de o renovar manualmente.

SQL Server

É possível que o certificado que usa para proteger o endpoint de espelhamento da base de dados no SQL Server expire, o que pode levar à degradação da ligação. Para evitar esse problema, gire o certificado antes que ele expire.

Use o seguinte comando Transact-SQL (T-SQL) para verificar a data de expiração 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, pode criar um novo certificadoe depois alterar o ponto de extremidade existente para substituir o certificado atual.

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

SQL Managed Instance

O certificado de endpoint de espelhamento de base de dados na Instância Gerida SQL é automaticamente renovado periodicamente. Não é necessário monitorar a data de expiração do certificado do ponto final de espelhamento da base de dados na Instância Gerida SQL, desde que consiga validar a cadeia de certificação no SQL Server com sucesso.

Valide a cadeia de certificados no SQL Server

Observação

A cadeia de certificados deve ser periodicamente validada para elos existentes ou para resolver problemas com um elo degradado. Ignore esta secção se estiver a configurar um novo link ou se tiver concluído recentemente os passos nas secções: Obtenha a chave pública do certificado da Instância Gerida SQL e importe-a para o SQL Server e importe as chaves de autoridade de certificação raiz confiáveis no Azure para o SQL Server.

Problemas com a cadeia de certificados podem degradar a ligação. Para evitar este problema, valide regularmente a cadeia de certificados no SQL Server .

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

  • Rotação de certificados agendada na Instância Gerida do SQL.
  • Alterações não intencionais ou acidentais aos certificados no SQL Server, como a queda ou alteração do certificado usado para proteger o endpoint de espelhamento da base de dados.

Primeiro, determine o certificate_id certificado de endpoint MI importado substituindo o valor de <ManagedInstanceFQDN> e depois 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 endpoint MI foi validado com êxito.

Importante

O procedimento sp_validate_certificate_ca_chain armazenado depende dos serviços do sistema operativo host para realizar a validação de certificados, o que pode envolver uma verificação online de revogação de certificados. Se o sistema operativo anfitrião não estiver configurado para aceder à internet, a execução falha mesmo que a cadeia de certificados seja válida.

Se encontrar um erro, a mitigação mais fiável é restaurar a cadeia de certificados, primeiro eliminando todos os certificados criados em secções . Obtenha a chave pública do certificado da Instância Gerida SQL e importe-a para o SQL Server e importe as chaves de autoridade de certificação raiz confiáveis no Azure para o SQL Server, e depois reimportando-as novamente.

Adicionar sinalizadores de rastreamento de inicialização

No 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. Consulte Ativar sinalizadores de rastreamento de inicialização para saber mais.

Conteúdo relacionado

Para usar o link:

Para saber mais sobre o link:

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

  • Last updated on