Partilhar via

Réplicas secundárias de hiperescala

Aplica-se a:Banco de Dados SQL do Azure

Conforme descrito em Arquitetura de funções distribuídas, o Azure SQL Database Hyperscale tem dois tipos diferentes de nós de computação, também conhecidos como réplicas:

As réplicas secundárias são sempre apenas para leitura e podem ser de três tipos diferentes.

  • Réplica de alta disponibilidade
  • Geo-réplica
  • Réplica com nome

Cada tipo tem uma arquitetura, um conjunto de recursos, uma finalidade e um custo diferentes. Com base nos recursos que você precisa, você pode usar apenas um ou até mesmo todos os três juntos. Você pode usar réplicas secundárias com camadas de computação sem servidor ou provisionadas.

Para obter tutoriais sobre como configurar e gerenciar réplicas nomeadas do Hyperscale, consulte:

Réplica de alta disponibilidade

Uma réplica de alta disponibilidade (HA) usa os mesmos servidores de página que a réplica primária, portanto, nenhuma cópia de dados é necessária para adicionar uma réplica de HA. As réplicas HA são usadas para aumentar a disponibilidade do banco de dados; funcionam como réplicas prontas para transferência em caso de falha. Caso a réplica primária se torne indisponível, a comutação para uma das réplicas de alta disponibilidade existentes será automática e rápida. A cadeia de conexão não precisa ser alterada; Durante o failover, os aplicativos podem enfrentar um tempo de inatividade mínimo devido à queda de conexões ativas. Como de costume para esse cenário, recomenda-se a lógica de repetição adequada. Vários drivers já fornecem algum grau de lógica de repetição automática. Se você estiver usando o .NET, a biblioteca Microsoft.Data.SqlClient mais recente fornece suporte nativo completo para lógica de repetição automática configurável.

As réplicas HA usam o mesmo nome de servidor e banco de dados que a réplica primária. Seu Objetivo de Nível de Serviço (SLO) também é sempre o mesmo que para a réplica principal. As réplicas de HA não são visíveis ou geríveis como recursos autónomos, a partir do portal ou de qualquer API. Eles são cobrados na mesma taxa de computação da réplica principal, mas os custos de armazenamento não se aplicam às réplicas secundárias.

Pode haver de zero a quatro réplicas de HA. Você pode especificar o número de réplicas durante a criação de um novo banco de dados ou atualizar o número de réplicas para um banco de dados existente. Você pode usar os pontos de extremidade e as ferramentas de gerenciamento comuns (por exemplo: Azure PowerShell, CLI do Azure, portal do Azure, API REST) para especificar o número de réplicas de HA. Criar ou remover réplicas de HA não afeta as conexões ativas na réplica principal.

Identificar réplicas

Você pode identificar todas as réplicas de hiperescala do Banco de Dados SQL do Azure e suas funções quando conectadas a uma réplica primária com a exibição de gerenciamento dinâmico (DMV) sys.dm_hs_database_replicas (Transact-SQL). Por exemplo:

SELECT replica_role_desc, replica_server_name, replica_id
FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));

Conectar-se a uma réplica HA

Em bases de dados Hyperscale, o argumento ApplicationIntent na cadeia de conexão usada pelo cliente determina se a conexão é roteada para a réplica primária de leitura-gravação ou para uma réplica HA somente leitura. Se ApplicationIntent estiver definido como ReadOnly e o banco de dados não tiver uma réplica secundária, a conexão será roteada para a réplica primária e assumirá como padrão o ReadWrite comportamento.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Todas as réplicas de HA são idênticas em sua capacidade de recursos. Se mais de uma réplica de HA estiver presente, a carga de trabalho de leitura será distribuída de forma arbitrária entre todas as réplicas de HA disponíveis. Quando houver várias réplicas de HA, lembre-se de que cada uma delas pode ter um diferente nível de latência relativamente às alterações de dados feitas no servidor principal. Cada réplica de HA usa os mesmos dados que a principal no mesmo conjunto de servidores de página. No entanto, os caches de dados locais em cada réplica HA refletem as alterações feitas no primário por meio do serviço de log de transações, que encaminha registros de log da réplica primária para réplicas HA. Como resultado, dependendo da carga de trabalho executada na réplica HA, a aplicação de registros de log pode ocorrer em velocidades diferentes e, portanto, réplicas diferentes podem ter latência de dados diferente em relação à réplica primária.

Réplica com nome

Uma réplica nomeada, assim como uma réplica HA, usa os mesmos servidores de página que a réplica primária. Semelhante às réplicas HA, não há nenhuma cópia de dados necessária para adicionar uma réplica nomeada.

Há diferenças entre réplicas HA e réplicas nomeadas:

  • As réplicas nomeadas aparecem como bancos de dados SQL regulares (somente leitura) do Azure no portal e em chamadas de API (Azure CLI, Azure PowerShell, T-SQL).
  • As réplicas nomeadas podem ter um nome de banco de dados diferente da réplica primária e, opcionalmente, estar localizadas em um servidor lógico diferente (desde que estejam na mesma região da réplica primária).
  • As réplicas nomeadas têm seu próprio Objetivo de Nível de Serviço que pode ser definido e alterado independentemente da réplica primária.
  • O suporte para réplicas nomeadas permite até 30 réplicas nomeadas para cada réplica primária.
  • As réplicas nomeadas oferecem suporte a autenticação diferente para cada réplica nomeada, criando logins diferentes em servidores lógicos que hospedam réplicas nomeadas.

Como resultado, as réplicas nomeadas oferecem vários benefícios em relação às réplicas HA, especialmente para cargas de trabalho de leitura única.

  • Os utilizadores conectados a uma réplica nomeada não serão desconectados se a réplica primária for aumentada ou reduzida.
  • Os usuários conectados à réplica principal não são afetados quando as réplicas nomeadas são dimensionadas para cima ou para baixo.

O principal objetivo das réplicas nomeadas é permitir uma ampla variedade de cenários de expansão de leitura e melhorar as cargas de trabalho de processamento analítico e transacional híbrido (HTAP). Exemplos de como criar tais soluções estão disponíveis aqui:

Além disso, as réplicas nomeadas oferecem flexibilidade e elasticidade para também satisfazer muitos outros casos de uso:

  • Isolamento de acesso: você pode conceder acesso a uma réplica nomeada específica, mas não à réplica primária ou outras réplicas nomeadas.
  • Objetivo de nível de serviço dependente da carga de trabalho: como uma réplica nomeada pode ter seu próprio objetivo de nível de serviço, é possível usar réplicas nomeadas diferentes para cargas de trabalho e casos de uso diferentes. Por exemplo, uma réplica nomeada pode ser usada para atender solicitações do Power BI, enquanto outra pode ser usada para fornecer dados ao Apache Spark para tarefas de Ciência de Dados. Cada um pode ter um objetivo de nível de serviço independente e escalar de forma independente.
  • Roteamento dependente da carga de trabalho: com até 30 réplicas nomeadas, é possível usar réplicas nomeadas em grupos para que um aplicativo possa ser isolado de outro. Por exemplo, um grupo de quatro réplicas nomeadas pode ser usado para atender solicitações provenientes de aplicativos móveis, enquanto outro grupo de duas réplicas nomeadas pode ser usado para atender solicitações provenientes de um aplicativo Web. Esta abordagem permitiria um ajuste preciso do desempenho e dos custos para cada grupo.

Observação

Para perguntas frequentes sobre réplicas nomeadas Hyperscale, consulte Perguntas frequentes sobre réplicas nomeadas Hyperscale do Banco de Dados SQL do Azure.

Redundância de zona para réplicas nomeadas do Hyperscale

As réplicas nomeadas de hiperescala configuradas para redundância de zona usam as Zonas de Disponibilidade do Azure para distribuir nós de computação de réplicas nomeadas em diferentes locais físicos dentro de uma região do Azure. Ao escolher a redundância entre zonas para réplicas identificadas, poderá aumentar a resiliência de todas as camadas dos seus bancos de dados Hyperscale a uma variada gama de falhas, incluindo falhas de centros de dados, sem modificações na lógica da aplicação. Para obter mais informações, consulte Disponibilidade redundante da zona de hiperescala.

Para obter um tutorial para criar uma réplica Hyperscale de zona redundante nomeada, consulte Criar uma réplica nomeada Hyperscale.

Para solucionar problemas e testar a resiliência de falhas de aplicativos, consulte Testar resiliência de falhas de aplicativos.

Geo-réplica

Com a replicação geográfica ativa, você pode criar uma réplica secundária legível do banco de dados primário do Hyperscale na mesma região do Azure ou em uma região diferente. As réplicas geográficas devem ser criadas em um servidor lógico diferente. O nome do banco de dados de uma réplica geográfica sempre corresponde ao nome do banco de dados primário.

Quando você cria uma réplica geográfica, todos os dados são copiados do primário para um conjunto diferente de servidores de página. Uma réplica geográfica não compartilha servidores de página com o principal, mesmo que eles estejam na mesma região. Esta arquitetura fornece a redundância necessária para falhas geográficas.

As réplicas geográficas são usadas para manter uma cópia transacionalmente consistente do banco de dados por meio da replicação assíncrona. Se uma réplica geográfica estiver em uma região diferente do Azure, ela poderá ser usada para recuperação de desastres se houver um desastre ou interrupção na região principal. As réplicas geográficas também podem ser usadas para cenários de ampliação de leitura geográfica. A partir de outubro de 2022, a cópia de banco de dados de uma réplica secundária geográfica Hyperscale é suportada.

A replicação geográfica para o banco de dados Hyperscale tem as seguintes limitações atuais:

  • Apenas uma réplica geográfica pode ser criada (na mesma região ou em regiões diferentes).
  • A restauração em um ponto no tempo da réplica geográfica não é suportada.
  • A criação de uma réplica geográfica de uma réplica geográfica (também conhecida como "encadeamento de réplica geográfica") não é suportada.

Solucionar problemas

Solucionar problemas nas réplicas nomeadas de Hyperscale com redundância de zona

  • Para solucionar problemas e testar a resiliência de falhas de aplicativos, consulte Testar resiliência de falhas de aplicativos.

  • Certifique-se de que pelo menos uma réplica de alta disponibilidade seja especificada ao criar uma réplica nomeada com redundância zonal, no ambiente PowerShell e na CLI. Para obter um exemplo, consulte Criar uma réplica nomeada de hiperescala.

    • Na CLI do Azure, você deve especificar os parâmetros ha-replicas e redundant.
    • No PowerShell, você deve especificar o parâmetro HighAvailabilityReplicaCount e ZoneRedundant.
    • Se omitido, você recebe a mensagem de erro: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • O banco de dados Hyperscale deve ter redundância de zona já habilitada como pré-requisito para habilitar esse recurso para réplicas nomeadas.

    • É opcional habilitar a redundância de zona para réplicas nomeadas, mesmo que o banco de dados primário tenha a redundância de zona habilitada.
    • Se não estiver habilitado, você receberá a mensagem de erro: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Problemas conhecidos

Dados parcialmente incorretos retornados de sys.databases

Os valores de linha retornados de sys.databases, para réplicas nomeadas, em colunas diferentes de name e database_id, podem ser inconsistentes e incorretos. Por exemplo, a compatibility_level coluna de uma réplica nomeada pode ser relatada como 140 mesmo que o banco de dados primário correspondente à réplica nomeada esteja definido como nível de compatibilidade 150. Uma solução alternativa, quando possível, é obter os mesmos dados usando a DATABASEPROPERTYEX() função, que retorna dados corretos.

Conteúdo relacionado

Para obter tutoriais sobre como configurar e gerenciar réplicas nomeadas do Hyperscale, consulte:

Para obter mais informações, consulte: