Compartilhar via

Réplicas secundárias de hiperescala

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Conforme descrito em Arquitetura de funções distribuídas, a Hiperescala do Banco de Dados SQL do Azure tem dois tipos diferentes de nós de computação, também chamados de réplicas:

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

  • Réplica de alta disponibilidade
  • Réplica geográfica
  • Réplica nomeada

Cada tipo tem uma arquitetura, um conjunto de recursos, uma finalidade e um custo diferentes. Com base nos recursos necessários, você pode usar apenas um ou até todos os três juntos. Você pode usar réplicas secundárias tanto com o nível de computação sem servidor quanto provisionado.

Para obter tutoriais sobre como configurar e gerenciar réplicas nomeadas do Hiperescala, confira:

Réplica de alta disponibilidade

Uma réplica de HA (alta disponibilidade) usa os mesmos servidores de páginas que a réplica primária, portanto, nenhuma cópia de dados é necessária para adicionar uma réplica de alta disponibilidade. As réplicas HA são usadas para aumentar a disponibilidade do banco de dados, já que funcionam como réplicas de acesso frequente em espera para fins de failover. Se a réplica primária não ficar mais disponível, o failover para uma das réplicas de HA existentes será rápido e automático. A cadeia de conexão não precisa ser alterada. Durante o failover, as aplicações podem enfrentar um tempo de inatividade mínimo devido à remoção das conexões ativas. Como de costume para esse cenário, uma lógica de repetição adequada é recomendada. 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 fornecerá um suporte nativo completo à lógica de repetição automática configurável.

As réplicas de HA usam o mesmo nome de servidor e de banco de dados da réplica primária. Seu Objetivo de Nível de Serviço (SLO) também é sempre o mesmo que o da réplica primária. As réplicas HA não ficam visíveis nem são gerenciáveis como um recurso autônomo, no portal ou em qualquer API. São cobradas à mesma tarifa de computação da réplica primária, mas nenhum custo de armazenamento se aplica às réplicas secundárias.

Pode haver zero a quatro réplicas de alta disponibilidade. 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 pontos de extremidade e ferramentas de gerenciamento comuns (por exemplo: Azure PowerShell, CLI do Azure, portal do Azure, API REST) para especificar o número de réplicas HA. A criação ou remoção de réplicas HA não afeta as conexões ativas na réplica primária.

Conectar-se a uma réplica de alta disponibilidade

Nos bancos de dados de Hiperescala, o argumento ApplicationIntent na cadeia de conexão usada pelo cliente determina se a conexão é roteada para a réplica de leitura-gravação primária ou para uma réplica somente leitura de HA. 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 o comportamento padrão será ReadWrite.

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

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

Réplica nomeada

Uma réplica nomeada, assim como uma réplica de HA, usa os mesmos servidores de páginas que a réplica primária. Assim como ocorre com as réplicas HA, nenhuma cópia de dados é necessária para adicionar uma réplica nomeada.

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

  • As réplicas nomeadas aparecem como bancos de dados SQL do Azure comuns (somente leitura) no portal e em chamadas à API (CLI do Azure, PowerShell do Azure, T-SQL).
  • Réplicas nomeadas podem ter um nome de banco de dados diferente da réplica primária e, opcionalmente, estarem localizadas em outro servidor lógico (desde que esteja na mesma região da réplica primária).
  • Réplicas nomeadas têm um objetivo de nível de serviço próprio que pode ser definido e alterado independentemente da réplica primária.
  • Réplicas nomeadas dão suporte a até 30 réplicas nomeadas (para cada réplica primária).
  • Réplicas nomeadas dão suporte a uma autenticação diferente para cada réplica nomeada pela criação de logons diferentes em servidores lógicos que hospedam as réplicas nomeadas.

Como resultado, as réplicas nomeadas oferecem vários benefícios em relação às réplicas de HA, no que se refere às cargas de trabalho somente leitura:

  • Os usuários conectados a uma réplica nomeada não serão desconectados se a réplica primária for escalonada ou reduzida verticalmente.
  • Os usuários conectados à réplica primária não serão afetados quando qualquer réplica nomeada for escalonada ou reduzida verticalmente.
  • As cargas de trabalho em execução em qualquer réplica — primária ou nomeada — não serão afetadas por consultas de execução prolongada em execução em outras réplicas.

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

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

  • Isolamento de acesso: você pode permitir acesso a uma réplica nomeada específica, mas não à réplica primária ou a 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 diferentes réplicas nomeadas para diferentes cargas de trabalho e casos de uso. Por exemplo, uma réplica nomeada pode ser usada para atender solicitações de Power BI, enquanto outra pode ser usada para oferecer dados ao Apache Spark para tarefas de Ciência de Dados. Cada uma pode ter um objetivo de nível de serviço independente e ser dimensionada de forma independente.
  • Roteamento dependente da carga de trabalho: com até 30 réplicas nomeadas, é possível usar réplicas nomeadas em grupos de forma que um aplicativo possa ser isolado de outro. Por exemplo, um grupo de quatro réplicas nomeadas poderia ser usado para atender a solicitações provenientes de aplicativos móveis, enquanto outro grupo de duas réplicas nomeadas pode ser usado para atender a solicitações provenientes de um aplicativo Web. Essa abordagem permitiria um ajuste refinado de desempenho e custos para cada grupo.

Observação

Para perguntas frequentes sobre as réplicas nomeadas de hiperescala, consulte Perguntas frequentes sobre réplicas nomeadas da Hiperescala do Banco de Dados SQL do Azure.

Redundância de zona para réplicas nomeadas Hiperescala

As réplicas nomeadas em hiperescala configuradas para redundância de zona usam Zonas de Disponibilidade do Azure para distribuir os nós de computação de réplicas nomeadas por diferentes locais físicos dentro de uma região do Azure. Ao escolher a redundância de zona para réplicas nomeadas, você pode aumentar a resiliência de todas as camadas de seus bancos de dados Hyperscale a uma ampla gama de falhas, incluindo paralisações do datacenter, sem modificações na lógica do aplicativo. Para obter mais informações, confira Disponibilidade com redundância de zona da Hiperescala para obter mais informações.

Para obter um tutorial sobre como criar uma réplica nomeada Hiperescala com redundância de zona, consulte Criar uma réplica nomeada Hyperscale.

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

Réplica geográfica

Com a replicação geográfica ativa, você pode criar uma réplica secundária para leitura do banco de dados primário de Hiperescala na mesma ou em outra região do Azure. 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 da primária.

Quando você cria uma réplica geográfica, todos os dados são copiados da primária para um conjunto diferente de servidores de página. Uma réplica geográfica não compartilha servidores de página com a primária, mesmo se estiverem na mesma região. Essa arquitetura fornece a redundância necessária para failovers geográficos.

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 estiver em uma região do Azure diferente, uma réplica geográfica poderá ser usada para recuperação de desastres caso ocorra um desastre ou indisponibilidade na região primária. As réplicas geográficas também podem ser usadas para cenários de escala horizontal de leitura geográfica. Desde outubro de 2022, há suporte para a cópia de banco de dados de uma réplica secundária geográfica da Hiperescala.

A replicação geográfica do banco de dados da Hiperescala tem as seguintes limitações atuais:

  • Somente uma réplica geográfica pode ser criada (na mesma ou em outra região).
  • A recuperação de um ponto no tempo da réplica geográfica não tem suporte.
  • A criação da réplica geográfica de uma réplica geográfica (também conhecida como "encadeamento de réplica geográfica") não tem suporte.

Solucionar problemas

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

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

  • Verifique se pelo menos uma réplica de alta disponibilidade seja especificada ao criar uma réplica nomeada redundante de zona, no PowerShell e na CLI. Para obter um exemplo, consulte Criar uma réplica nomeada Hiperescala.

    • Na CLI do Azure, você precisa especificar ambos os parâmetros ha-replicas e redundant.
    • No PowerShell, você precisa especificar o parâmetro HighAvailabilityReplicaCount e ZoneRedundant.
    • Se for omitido, você receberá 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 Hiperescala deve ter a redundância de zona já habilitada como pré-requisito para habilitar esse recurso para as réplicas nomeadas.

    • Habilitar a redundância de zona para réplicas nomeadas é opcional, mesmo se a redundância de zona do banco de dados primário estiver 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 as réplicas nomeadas, em colunas diferentes de name e database_id, podem ser inconsistentes e incorretos. Por exemplo, a coluna compatibility_level de uma réplica nomeada poderia ser reportada como 140, mesmo se o banco de dados primário correspondente à réplica nomeada estivesse definido com um nível de compatibilidade 150. Uma solução alternativa, sempre que possível, é obter os mesmos dados usando a função DATABASEPROPERTYEX(), que retorna os dados corretos.

Conteúdo relacionado

Para obter tutoriais sobre como configurar e gerenciar réplicas nomeadas do Hiperescala, confira:

Para saber mais, veja: