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. As réplicas secundárias são compatíveis com camadas de computação provisionadas e sem servidor.

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 de HA são usadas principalmente para aumentar a disponibilidade do banco de dados, pois funcionam como uma réplica de espera ativa 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á 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. O objetivo de nível de serviço também é sempre o mesmo que para a réplica primária. As réplicas de HA não ficam visíveis nem gerenciáveis como um recurso autônomo no portal ou em qualquer API.

Pode haver zero a quatro réplicas de alta disponibilidade. O número delas pode ser alterado durante a criação de um banco de dados ou depois que o banco de dados for criado por meio de pontos de extremidade de gerenciamento e de ferramentas comuns (por exemplo, o PowerShell, a CLI do AZ, o portal e a API REST). A criação ou a remoção das réplicas de 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 for 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 usará o comportamento ReadWrite como padrão.

-- 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 processada por uma réplica de alta disponibilidade, a aplicação de registros de log pode ocorrer em diferentes velocidades e, portanto, réplicas diferentes podem ter uma latência de dados distinta em 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 as réplicas de alta disponibilidade, não há 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:

  • Réplicas nomeadas são exibidas como bancos de dados SQL do Azure comuns (somente leitura) no portal e em chamadas à API (CLI do AZ, PowerShell e 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 sofrerão nenhuma desconexão se a réplica primária for aumentada ou reduzida verticalmente. Ao mesmo tempo, os usuários conectados à réplica primária não serão afetados pelo aumento nem pela redução das réplicas nomeadas.
  • 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 dos principais cenários listados acima, as réplicas nomeadas oferecem flexibilidade e elasticidade para atender também a 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 um objetivo de nível de serviço próprio, é 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 para 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

Observação

A redundância de zonas nomeadas para as réplicas nomeadas Hiperescala do Banco de Dados SQL do Azure está atualmente em versão prévia.

A redundância de zona para as réplicas nomeadas Hiperescala do Banco de Dados SQL do Azure usa as Zonas de Disponibilidade do Azure para distribuir nós de computação de réplicas nomeadas em diferentes locais físicos em 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.

Ao criar 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 eles 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 uma réplica geográfica estiver em outra região do Azure, ela poderá ser usada para recuperação de desastre em caso de desastre ou interrupção 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).
  • Não há suporte para a Recuperação Pontual da réplica geográfica.
  • Não há suporte para a criação de uma replicação geográfica de uma replicação geográfica (também conhecido como "encadeamento de réplica geográfica").

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ê deve especificar os parâmetros "ha-replicas" e "redundante".
    • No PowerShell, especifique 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.

    • É 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 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 relatada como 140, mesmo que o banco de dados primário do qual a réplica nomeada foi criada esteja definido como 150. Uma solução alternativa, quando possível, é obter os mesmos dados usando a função DATABASEPROPERTYEX(), que retornará os dados corretos.

Conteúdo relacionado

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

Para saber mais, veja: