Réplicas secundárias de hiperescala

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:

Primária: atende operações de leitura e escrita
Secundária: fornece expansão de leitura, alta disponibilidade e replicação geográfica

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 com as camadas de computação sem servidor ou provisionada.

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 alta disponibilidade (HA) são usadas para aumentar a disponibilidade do banco de dados; elas atuam como réplicas de standby ativo 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á oferecem algum nível de lógica de nova tentativa 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 são visíveis nem podem ser gerenciadas como recursos autônomos, 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 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 endpoints comuns de gerenciamento e as ferramentas (por exemplo: Azure PowerShell, CLI do Azure, portal do Azure e API REST) para especificar o número de réplicas de alta disponibilidade (HA). A criação ou remoção de réplicas HA não afeta as conexões ativas na réplica primária.

Identificar réplicas

Você pode identificar todas as réplicas do Banco de Dados SQL do Azure na Hiperescala e suas funções ao se conectar a uma réplica primária com a visã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

Nos bancos de dados Hyperscale, o argumento ApplicationIntent na string de conexão usada pelo cliente determina se a conexão é roteada para a réplica primária de leitura e 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 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=<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 intenção de leitura será distribuída arbitrariamente entre todas as réplicas de HA disponíveis. Quando houver várias réplicas de HA, tenha em mente que cada uma delas pode ter uma latência diferente em relação às alterações de dados realizadas no primário. Cada réplica de HA usa os mesmos dados da réplica primária 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).
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.
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 diz respeito às cargas de trabalho somente de leitura:

Os usuários conectados a uma réplica nomeada não são desconectados se a réplica primária for redimensionada para cima ou para baixo.
Os usuários conectados à réplica primária não são afetados quando quaisquer réplicas nomeadas são aumentadas ou reduzidas em capacidade.

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:

Amostra de expansão do OLTP

Além disso, as réplicas nomeadas oferecem flexibilidade e elasticidade para também atender 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 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 Hyperscale, consulte Perguntas frequentes sobre réplicas nomeadas de Hyperscale do Banco de Dados SQL do Azure.

Redundância de zona para réplicas nomeadas Hiperescala

As réplicas nomeadas do Hyperscale com redundância de zona configurada usam Zonas de Disponibilidade do Azure para distribuir os nós de computação das réplicas nomeadas entre 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 dos seus bancos de dados Hyperscale contra uma gama mais ampla de falhas, incluindo interrupções no datacenter, sem nenhuma modificação na lógica do aplicativo. Para obter mais informações, consulte Disponibilidade com redundância entre zonas da Hiperescala.

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 primário.

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 que estejam 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 georréplicas também podem ser usadas em cenários geográficos de expansão de escala de leitura. A partir de outubro de 2022, há suporte à cópia de banco de dados de uma réplica geográfica secundária da camada Hyperscale.

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.
Criar uma réplica geográfica de uma réplica geográfica (também conhecido como "encadeamento de réplica geográfica") não é suportado.

Importante

A capacidade de criar várias réplicas geográficas nas mesmas regiões ou em regiões diferentes é um recurso de visualização antecipada.

Solucionar problemas

Solucionar problemas de réplicas nomeadas do Hyperscale 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.
Certifique-se de que pelo menos uma réplica de alta disponibilidade seja especificada ao criar uma réplica nomeada com redundância 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 por sys.databases, no caso de 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.