Leia réplicas no Banco de Dados do Azure para MySQL

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor único

Importante

O Banco de Dados do Azure para servidor único MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para o servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

O recurso de réplica de leitura permite replicar dados de um servidor de Banco de Dados do Azure para MySQL para um servidor somente leitura. Você pode replicar do servidor de origem para até cinco réplicas. As réplicas são atualizadas de forma assíncrona usando a tecnologia de replicação baseada em posição do arquivo binário nativo (log binário) do mecanismo MySQL. Para saber mais sobre a replicação do binlog, confira a visão geral da replicação do binlog do MySQL.

As réplicas são novos servidores que você gerencia de modo semelhante aos servidores normais do Banco de Dados do Azure para PostgreSQL. Para cada réplica de leitura, você será cobrado pela computação provisionada em vCores e pelo armazenamento em GB/mês.

Para saber mais sobre recursos e problemas de replicação do MySQL, consulte a documentação de replicação do MySQL.

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Quando usar uma réplica de leitura

O recurso de réplica de leitura ajuda a melhorar o desempenho e o dimensionamento de cargas de trabalho com uso intenso de leitura. As cargas de trabalho de leitura podem ser isoladas para as réplicas, enquanto as cargas de trabalho de gravação podem ser direcionadas para a origem.

Um cenário comum é ter cargas de trabalho analíticas e de BI usando a réplica de leitura como a fonte de dados para relatório.

Como réplicas são somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação na origem. Esse recurso não se destina a cargas de trabalho com uso intenso de gravação.

O recurso de réplica de leitura usa replicação assíncrona do MySQL. O recurso não se destina a cenários de replicação síncrona. Haverá um atraso mensurável entre a origem e a réplica. Os dados na réplica acabarão se tornando consistentes com os dados na origem. Use este recurso para cargas de trabalho que podem acomodar esse atraso.

Replicação entre regiões

Você pode criar uma réplica de leitura em uma região diferente da do servidor de origem. A replicação entre regiões pode ser útil para cenários como o planejamento de recuperação de desastres ou para trazer dados mais próximos dos seus usuários.

Você pode ter um servidor de origem em qualquer região do Banco de Dados do Azure para MySQL. Um servidor de origem pode ter uma réplica na região emparelhada ou nas regiões de réplica universal. A figura a seguir mostra quais regiões de réplica estão disponíveis dependendo da sua região de origem.

Regiões de réplica universal

Você pode criar uma réplica de leitura em qualquer uma das seguintes regiões, independentemente de onde o servidor de origem estiver localizado. As regiões de réplica universal compatíveis incluem:

Região Disponibilidade de réplica
Leste da Austrália ✔️
Sudeste da Austrália ✔️
Brazil South ✔️
Canadá Central ✔️
Leste do Canadá ✔️
Centro dos EUA ✔️
Leste dos EUA ✔️
Leste dos EUA 2 ✔️
Leste da Ásia ✔️
Leste do Japão ✔️
Oeste do Japão ✔️
Coreia Central ✔️
Sul da Coreia ✔️
Norte da Europa ✔️
Centro-Norte dos EUA ✔️
Centro-Sul dos Estados Unidos ✔️
Sudeste Asiático ✔️
Norte da Suíça ✔️
Sul do Reino Unido ✔️
Oeste do Reino Unido ✔️
Centro-Oeste dos EUA ✔️
Oeste dos EUA ✔️
Oeste dos EUA 2 ✔️
Europa Ocidental ✔️
Índia Central* ✔️
França Central* ✔️
Norte dos EAU* ✔️
Norte da África do Sul* ✔️

Observação

*Regiões em que o Banco de Dados do Azure para MySQL tem um armazenamento para uso geral v2 em Versão Prévia Pública
*Nessas regiões do Azure, você terá a opção de criar um servidor no armazenamento para uso geral v1 e v2. Nos servidores criados com um armazenamento para uso geral v2 em versão prévia pública, você está limitado a criar um servidor de réplica somente nas regiões do Azure compatíveis com o armazenamento para uso geral v2.

Regiões emparelhadas

Você pode criar uma réplica de leitura na região emparelhada do Azure do seu servidor de origem além das regiões de réplica universal. Se não souber o par da sua região, você pode encontrar essa informação no artigo Regiões emparelhadas do Azure.

Se você estiver usando réplicas entre regiões para o planejamento de recuperação de desastres, recomendamos criar a réplica na região emparelhada, e não em uma das outras regiões. Regiões emparelhadas evitam atualizações simultâneas e priorizam isolamento físico e residência de dados.

No entanto, há certas limitações a serem consideradas:

  • Disponibilidade regional: O Banco de Dados do Azure para MySQL está disponível na França Central, Norte dos EAU e Alemanha Central. Entretanto, suas regiões emparelhadas não estão disponíveis.

  • Pares unidirecionais: Algumas regiões do Azure são emparelhadas em uma direção apenas. Essas regiões incluem Oeste da Índia, Sul do Brasil e US Gov - Virgínia. Isso significa que um servidor de origem no Oeste da Índia pode criar uma réplica no Sul da Índia. Entretanto, um servidor de origem no Sul da Índia não pode criar uma réplica no Oeste da Índia. Isso ocorre porque a região secundária do Oeste da Índia é o Sul da Índia, mas a região secundária do Sul da Índia não é o Oeste da Índia.

Criar uma réplica

Importante

  • O recurso de réplica de leitura está disponível apenas para bancos de dados do Azure para servidores MySQL nas camadas de preços de uso geral ou de otimização de memória. Verifique se o servidor de origem está em um desses tipos de preços.
  • Se o servidor de origem não tiver servidores de réplica existentes, ele poderá precisar reiniciar para se preparar para a replicação, dependendo do armazenamento usado (v1/v2). Considere reiniciar o servidor e execute essa operação fora do horário de pico. Consulte Reinicialização do servidor de origem para ver mais detalhes.

Quando você inicia o fluxo de trabalho de criação de réplica, um servidor do Banco de Dados do Azure para MySQL é criado. O novo servidor é preenchido com os dados que estavam no servidor de origem. A hora de criação depende da quantidade de dados na origem e do tempo decorrido desde o último backup completo semanal. O tempo pode variar de alguns minutos a várias horas. O servidor de réplica é sempre criado no mesmo grupo de recursos e na mesma assinatura do servidor de origem. Se você quiser criar um servidor de réplica para um grupo de recursos diferente ou uma assinatura diferente, você pode mover o servidor de réplica após a criação.

Cada réplica é habilitada para armazenamento de aumento automático. O recurso de aumento automático permite que a réplica acompanhe os dados replicados e evita uma interrupção na replicação causada por erros de falta de armazenamento.

Saiba como criar uma réplica de leitura no portal do Azure.

Conectar-se a uma réplica

Uma réplica herda as regras de firewall do servidor de origem na criação. Essas regras são independentes do servidor de origem posteriormente.

A réplica herda a conta do administrador do servidor de origem. Todas as contas de usuário no servidor de origem são replicadas para as réplicas de leitura. Você só pode se conectar a uma réplica de leitura usando as contas de usuário disponíveis no servidor de origem.

Você pode se conectar à réplica usando seu nome de host e uma conta de usuário válida, assim como faria em um servidor regular do Banco de Dados do Azure para MySQL. Para um servidor chamado myreplica com o nome de usuário admin myadmin, você pode se conectar à réplica usando a CLI do mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p

No prompt, insira a senha da conta de usuário.

Monitorar a replicação

O Banco de Dados do Azure para MySQL fornece a métrica Atraso da replicação em segundos no Azure Monitor. Essa métrica está disponível apenas para réplicas. Essa métrica é calculada com o uso da métrica seconds_behind_master disponível no comando SHOW SLAVE STATUS do MySQL. Defina um alerta para informá-lo quando o retardo da replicação atinge um valor que não é aceitável para sua carga de trabalho.

Se você vir maior atraso de replicação, consulte Solucionando problemas de latência de replicação para solucionar problemas e entender possíveis causas.

Parar replicação

Você pode interromper a replicação entre uma origem e uma réplica. Após a replicação ser interrompida entre um servidor de origem e uma réplica de leitura, a réplica se torna um servidor autônomo. Os dados no servidor autônomo são os dados que estavam disponíveis na réplica no momento em que o comando de parar a replicação foi iniciado. O servidor autônomo não alcança o servidor de origem.

Quando você escolhe interromper a replicação em uma réplica, ela perde todos os links para a origem anterior e outras réplicas. Não há failover automatizado entre uma origem e sua réplica.

Importante

O servidor autônomo não pode se tornar uma réplica novamente. Antes de interromper a replicação em uma réplica de leitura, verifique se a réplica tem todos os dados de que você precisa.

Saiba como interromper a replicação para uma réplica.

Failover

Não há nenhum failover automatizado entre os servidores de origem e de réplica.

Como a replicação é assíncrona, há um atraso entre a origem e a réplica. A duração da latência pode ser influenciada por muitos fatores, como a intensidade da carga de trabalho em execução no servidor de origem e a latência entre os data centers. Na maioria dos casos, o atraso da réplica varia entre alguns segundos e alguns minutos. Você pode acompanhar o retardo de replicação real usando a métrica Retardo de réplica, que está disponível para cada réplica. A métrica Retardo da Réplica mostra o tempo decorrido desde a última transação reproduzida. É recomendável que você identifique o retardo médio, observando o retardo de réplica em um período de tempo. Você pode definir um alerta para o retardo de réplica, de modo que, se ele ficar fora do intervalo esperado, você poderá executar uma ação.

Dica

Se você realizar o failover para a réplica, o retardo no momento em que você desvincular a réplica da fonte indicará a quantidade de dados perdida.

Depois de decidir que deseja fazer failover para uma réplica:

  1. Pare a replicação para a réplica
    Essa etapa é necessária para tornar o servidor de réplica capaz de aceitar gravações. Como parte desse processo, o servidor de réplica será desvinculado da origem. Depois de iniciar a interrupção da replicação, o processo de back-end normalmente leva dois minutos para terminar. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Direcione seu aplicativo para a réplica (antiga)
    Cada servidor tem uma cadeia de conexão única. Atualize seu aplicativo para direcionar para a réplica (antiga) em vez da origem.

Depois que o aplicativo processar leituras e gravações com êxito, você concluiu o failover. A quantidade de tempo de inatividade com a qual suas experiências de aplicativo dependerão quando você detectar um problema e concluir as etapas 1 e 2 listadas anteriormente.

GTID (identificador de transação global)

O GTID (identificador de transação global) é um identificador exclusivo criado com cada transação confirmada em um servidor de origem e está desativado por padrão no banco de dados do Azure para MySQL. O GTID tem suporte nas versões 5.7 e 8.0 e apenas em servidores que dão suporte a armazenamento de até 16 TB (armazenamento de uso geral v2). Para saber mais sobre o GTID e como ele é usado na replicação, consulte a documentação de replicação do MySQL com GTID.

O MySQL dá suporte a dois tipos de transações: transações GTID (identificadas com GTID) e transações anônimas (não têm um GTID alocado)

Os seguintes parâmetros de servidor estão disponíveis para configurar o GTID:

Parâmetro do servidor Descrição Valor padrão Valores
gtid_mode Indica se os GTIDs são usados para identificar transações. As alterações entre os modos só podem ser feitas uma etapa por vez em ordem ascendente (por exemplo, OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF OFF: as transações novas e de replicação devem ser anônimas
OFF_PERMISSIVE: novas transações são anônimas. As transações replicadas podem ser transações anônimas ou GTID.
ON_PERMISSIVE: novas transações são transações GTID. As transações replicadas podem ser transações anônimas ou GTID.
ON: as transações novas e replicadas devem ser transações GTID.
enforce_gtid_consistency Impõe a consistência do GTID permitindo a execução apenas das instruções que podem ser registradas de maneira transacional segura. Esse valor deve ser definido como ON antes de habilitar a replicação de GTID. OFF OFF: nenhuma transação tem permissão para violar a consistência de GTID.
ON: nenhuma transação tem permissão para violar a consistência de GTID.
WARN: todas as transações têm permissão para violar a consistência de GTID, mas um aviso é gerado.

Observação

  • Depois que o GTID for habilitado, você não poderá desativar. Se você precisar desativar GTID, entre em contato com o suporte.

  • É possível alterar GTIDs de um valor para outro somente em uma etapa por vez em ordem crescente de modos. Por exemplo, caso gtid_mode no momento esteja definido como OFF_PERMISSIVE, será possível alterá-lo para ON_PERMISSIVE, porém não para ATIVADO.

  • Não é possível atualizar a replicação para um servidor mestre/de réplica com o objetivo de mantê-la consistente.

  • Recomendamos DEFINIR enforce_gtid_consistency como ATIVADO para definir gtid_mode=ON

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros do servidor gtid_mode e enforce_gtid_consistency usando o portal do Azure, o CLI do Azure ou o PowerShell.

Se GTID estiver habilitado em um servidor de origem (gtid_mode = on), as réplicas recém-criadas também terão GTID habilitado e usarão a replicação GTID. Para garantir que a replicação seja consistente, não é possível alterar gtid_mode após criar servidores mestre ou de réplica com o GTID habilitado.

Considerações e limitações

Tipos de preço

No momento, as réplicas de leitura estão disponíveis apenas nas camadas de preços de uso geral e de otimização de memória.

Observação

O custo da execução do servidor de réplica é baseado na região em que o servidor de réplica está em execução.

Reinicialização do servidor de origem

Para o servidor que tenha armazenamento de uso geral v1, o parâmetro log_bin será OFF por padrão. O valor será ativado (ON) ao criar a primeira réplica de leitura. Se um servidor de origem não tiver réplicas de leitura, ele primeiro será reiniciado para se preparar para a replicação. Considere reiniciar o servidor e execute essa operação fora do horário de pico.

Para o servidor de origem com armazenamento de uso geral v2, o parâmetro log_bin será ON por padrão e não exigirá reinicialização ao adicionar uma réplica de leitura.

Novas réplicas

Uma réplica de leitura é criada como um novo servidor de Banco de Dados do Azure para MySQL. Um servidor existente não pode se tornar uma réplica. Você não pode criar uma réplica de outra réplica de leitura.

Configuração da réplica

Uma réplica é criada usando a mesma configuração de servidor que a origem. Depois que uma réplica é criada, várias configurações podem ser alteradas independentemente do servidor de origem: geração de computação, vCores, armazenamento e período de retenção de backup. O tipo de preço também pode ser alterado de forma independente, exceto de ou para a camada básica.

Importante

Antes de uma configuração de servidor de origem ser atualizada com novos valores, atualize a configuração de réplica para valores iguais ou maiores. Esta ação garante que a réplica possa acompanhar as alterações realizadas na origem.

Regras de firewall e configurações de parâmetros são herdadas do servidor de origem para a réplica quando a réplica é criada. As regras da réplica são independentes posteriormente.

Réplicas paradas

Se você interromper a replicação entre um servidor de origem e uma réplica de leitura, a réplica interrompida se tornará um servidor autônomo que aceita leituras e gravações. O servidor autônomo não pode se tornar uma réplica novamente.

Servidores de origem e autônomo excluídos

Quando um servidor de origem é excluído, a replicação é interrompida para todas as réplicas de leitura. Essas réplicas se tornam servidores autônomos automaticamente e podem aceitar leituras e gravações. O próprio servidor de origem é excluído.

Contas de usuário

Os usuários no servidor de origem são replicados para as réplicas de leitura. Você só pode se conectar a uma réplica de leitura usando as contas de usuário disponíveis no servidor de origem.

Parâmetros do Servidor

Para impedir que os dados fiquem fora de sincronia e evitar possíveis perdas de dados ou danos, alguns parâmetros de servidor estão bloqueados para serem atualizados ao usar réplicas de leitura.

Os seguintes parâmetros do servidor estão bloqueados nos servidores e origem e de réplica:

O parâmetro event_scheduler está bloqueado nos servidores de réplica.

Para atualizar um dos parâmetros bloqueados no servidor de origem, exclua os servidores de origem, atualize o valor do parâmetro no servidor de origem e recrie as réplicas.

GTID

GTID tem suporte em:

  • Versões do MySQL 5.7 e 8.0.
  • Servidores que dão suporte a armazenamento de até 16 TB. Consulte o artigo tipo de preço para obter a lista completa de regiões que dão suporte ao armazenamento de 16 TB.

GTID está desativado por padrão. Depois que o GTID estiver habilitado, você não poderá desativá-lo. Se você precisar desativar GTID, entre em contato com o suporte.

Se o GTID estiver habilitado em um servidor de origem, as réplicas recém-criadas também terão GTID habilitado e usarão a replicação GTID. Para manter a replicação consistente, você não pode atualizar gtid_mode nos servidores de origem ou de réplica.

Outro

  • Não há suporte para a criação de uma réplica de uma réplica.
  • Tabelas na memória podem fazer com que as réplicas fiquem fora de sincronia. Esta é uma limitação da tecnologia de replicação do MySQL. Leia mais na documentação de referência do MySQL para mais informações.
  • Verifique se as tabelas de servidor de origem contêm chaves primárias. A falta de chaves primárias pode resultar em latência de replicação entre a origem e as réplicas.
  • Analise a lista completa das limitações de replicação do MySQL no documentação do MySQL

Próximas etapas