Partilhar via

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

O MySQL é um dos mecanismos de banco de dados populares para executar aplicativos web e móveis em escala de internet. Muitos clientes usam o Banco de Dados do Azure para MySQL para uma ampla gama de aplicativos, incluindo educação online, streaming de vídeo, pagamentos digitais, comércio eletrônico, jogos, portais de notícias, sites governamentais e de saúde. Esses serviços devem ser capazes de servir e escalar à medida que o tráfego na web ou aplicativo móvel aumenta.

No lado das aplicações, os desenvolvedores normalmente usam Java ou PHP. Eles migram o aplicativo para ser executado em Conjuntos de Escala de Máquina Virtual do Azure, Serviços de Aplicativo do Azure ou o colocam em contêineres para serem executados no Serviço Kubernetes do Azure (AKS). Com o Conjunto de Dimensionamento de Máquina Virtual, o Serviço de Aplicativo ou o AKS como a infraestrutura subjacente, o dimensionamento de aplicativos é simplificado provisionando instantaneamente novas VMs e replicando os componentes sem monitoração de estado dos aplicativos para atender às solicitações. No entanto, o banco de dados muitas vezes se torna um gargalo como um componente com estado centralizado.

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

Você gerencia réplicas como novos servidores, assim como seu Banco de Dados do Azure de origem para instâncias do Servidor Flexível MySQL. Você incorre em cobranças para cada réplica de leitura com base na computação provisionada em vCores e armazenamento em GB por mês. Para obter mais informações, consulte preços.

O recurso de réplica de leitura só está disponível para instâncias do Servidor Flexível do Banco de Dados do Azure para MySQL nas camadas de preços Uso Geral ou Crítica para os Negócios. Verifique se o servidor de origem está em uma dessas camadas de preço.

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

Nota

Este artigo contém referências ao termo escravo, um termo que a Microsoft não usa mais. Quando removemos o termo do software, removemo-lo deste artigo.

Casos de uso comuns para réplica de leitura

O recurso de réplica de leitura ajuda a melhorar o desempenho e a escala de cargas de trabalho com uso intensivo de leitura. Você pode isolar cargas de trabalho de leitura para as réplicas, enquanto direciona cargas de trabalho de gravação para a origem.

Os cenários comuns incluem:

  • Dimensionamento de cargas de trabalho de leitura provenientes do aplicativo usando um proxy de conexão leve como ProxySQL ou usando um padrão baseado em microsserviços para dimensionar suas consultas de leitura provenientes do aplicativo para réplicas de leitura
  • Usando réplicas de leitura como fonte de dados para cargas de trabalho de BI ou relatórios analíticos
  • Ingestão de informações de telemetria no mecanismo de banco de dados MySQL enquanto usa várias réplicas de leitura para relatórios de dados em cenários de IoT ou Manufatura

Como as réplicas são somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação na origem. Esta funcionalidade não está direcionada para cargas de trabalho de escrita intensa.

O recurso de réplica de leitura usa a replicação assíncrona do MySQL. O recurso não se destina a cenários de replicação síncrona. Há um atraso mensurável entre a origem e a réplica. Os dados na réplica eventualmente se tornam consistentes com os dados na fonte. Utilize esta funcionalidade para cargas de trabalho que podem acomodar este atraso.

Replicação entre regiões

Você pode criar uma réplica de leitura em uma região diferente do servidor de origem. A replicação entre regiões pode ser útil em cenários como o planeamento de recuperação após desastre ou para que os dados fiquem mais próximos dos utilizadores. O Banco de Dados do Azure para Servidor Flexível MySQL permite provisionar uma réplica de leitura em qualquer região com suporte do Azure onde o Banco de Dados do Azure para Servidor Flexível MySQL esteja disponível. Usando esse recurso, um servidor de origem pode ter uma réplica em sua região emparelhada ou nas regiões de réplica universal. Consulte aqui para encontrar a lista de regiões do Azure onde o Banco de Dados do Azure para Servidor Flexível MySQL está disponível hoje.

Criar uma réplica

Ao iniciar o fluxo de trabalho de criação de réplica, você cria um Banco de Dados do Azure em branco para a instância do Servidor Flexível MySQL. O novo servidor contém os dados que estavam no servidor de origem. O tempo de criação depende da quantidade de dados na origem e do tempo desde o último backup completo semanal. O tempo pode variar entre alguns minutos e várias horas.

Nota

Você cria réplicas de leitura com a mesma configuração de servidor que a origem. Você pode alterar a configuração do servidor de réplica após a criação. Você sempre cria o servidor de réplica no mesmo grupo de recursos e assinatura que o servidor de origem. Se desejar criar um servidor de réplica em um grupo de recursos diferente ou em uma assinatura diferente, você poderá mover o servidor de réplica após a criação. Mantenha a configuração do servidor de réplica em valores iguais ou maiores do que a origem para garantir que a réplica possa acompanhar a origem.

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

Ligar a uma réplica

Quando você cria uma réplica, ela herda o método de conectividade do servidor de origem. Não é possível alterar o método de conectividade da réplica. Por exemplo, se o servidor de origem usar acesso privado (integração VNet), a réplica não poderá usar acesso público (endereços IP permitidos).

A réplica herda a conta de 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, como faria em uma instância normal do Banco de Dados do Azure para o Servidor Flexível 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 -p

Quando lhe for pedido, introduza a palavra-passe para a conta de utilizador.

Monitorizar a replicação

O Banco de Dados do Azure para Servidor Flexível MySQL fornece a métrica de atraso de replicação em segundos no Azure Monitor. Essa métrica está disponível apenas para réplicas. O Azure Monitor calcula essa métrica usando a seconds_behind_master métrica no comando do SHOW SLAVE STATUS MySQL. Defina um alerta para notificá-lo quando o atraso de replicação exceder um limite inaceitável para sua carga de trabalho.

Se você observar um aumento do atraso de replicação, consulte Solução de problemas de latência de replicação para solucionar problemas e entender possíveis causas.

Importante

A réplica de leitura usa a tecnologia de replicação baseada em armazenamento, que não usa mais a SLAVE_IO_RUNNING/REPLICA_IO_RUNNING métrica disponível no comando do SHOW SLAVESTATUS'/'SHOWREPLICA STATUS MySQL. Esse valor é sempre exibido como "Não" e não é indicativo do status de replicação. Para saber o status correto da replicação, consulte Métricas de replicação - Status da réplica IO e Status SQL da réplica na página Monitoramento.

Parar replicação

Você pode interromper a replicação entre um servidor de origem e um servidor de réplica. Quando você interrompe a replicação entre um servidor de origem e uma réplica de leitura, o servidor de réplica se torna um servidor autônomo. O servidor autônomo contém os dados que estavam disponíveis no servidor de réplica quando você iniciou o comando stop replication. O servidor autônomo não sincroniza nenhum dado ausente do servidor de origem.

Quando você interrompe a replicação para um servidor de réplica, o servidor de réplica perde todos os links para seu servidor de origem anterior e para outros servidores de réplica. Não há failover automatizado entre um servidor de origem e seus servidores de réplica.

Importante

Não é possível converter o servidor autônomo novamente em um servidor de réplica. Antes de interromper a replicação em uma réplica de leitura, verifique se o servidor de réplica tem todos os dados necessários.

Para obter mais informações, consulte Interromper a replicação para uma réplica.

Ativação pós-falha

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

As réplicas de leitura dimensionam cargas de trabalho de leitura intensiva e não fornecem alta disponibilidade para um servidor. Você executa failover manual interrompendo a replicação em uma réplica de leitura colocando-a online no modo de leitura-gravação.

Como a replicação é assíncrona, há um atraso entre a origem e a réplica. Muitos fatores influenciam a quantidade de atraso, como a carga de trabalho 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 controlar o atraso real da replicação usando a métrica Atraso da réplica , que está disponível para cada réplica. Esta métrica mostra o tempo desde a última transação repetida. Recomendamos que você identifique o atraso médio observando o atraso da réplica ao longo do tempo. Você pode definir um alerta sobre o atraso da réplica, para que, se ele sair do intervalo esperado, você possa agir.

Gorjeta

Se você fizer failover para a réplica, o atraso no momento em que você desvincular a réplica da origem indica quantos dados foram perdidos.

Depois de decidir fazer failover para uma réplica:

  1. Interromper a replicação para a réplica

    Você precisa interromper a replicação para tornar o servidor de réplica capaz de aceitar gravações. Esse processo desvincula o servidor de réplica da origem. Depois de iniciar a replicação de parada, o processo de back-end normalmente leva cerca de dois minutos para ser concluído. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Aponte seu aplicativo para a réplica (anterior)

    Cada servidor tem uma cadeia de conexão exclusiva. Atualize seu aplicativo para apontar para a réplica (anterior) em vez da fonte.

Quando seu aplicativo processa leituras e gravações com êxito, você conclui o failover. A quantidade de tempo de inatividade que seu aplicativo enfrenta depende de quando você deteta um problema e conclui as etapas 1 e 2.

Identificador global de transação (GTID)

Um identificador de transação global (GTID) é um identificador exclusivo que o servidor de origem cria com cada transação confirmada. O Banco de Dados do Azure para Servidor Flexível MySQL desativa o GTID por padrão. As versões 5.7 e 8.0 suportam GTID. Para obter mais informações sobre o GTID e como a replicação o usa, consulte a documentação de replicação do MySQL com GTID .

Use os seguintes parâmetros de servidor 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 modos só podem ser feitas um passo de cada vez em ordem crescente (ex., OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF* OFF: As transações novas e de replicação devem ser anônimas
OFF_PERMISSIVE: As novas transações são anónimas. As transações replicadas podem ser anônimas ou transações GTID.
ON_PERMISSIVE: Novas transações são transações GTID. As transações replicadas podem ser anônimas ou transações GTID.
ON: As transações novas e replicadas devem ser transações GTID.
enforce_gtid_consistency Reforça a consistência do GTID, permitindo a execução apenas das instruções que podem ser registradas de forma transacionalmente segura. Defina o valor ON antes de ativar a replicação GTID. OFF* OFF: Todas as transações podem violar a consistência do GTID.
ON: Nenhuma transação pode violar a consistência do GTID.
WARN: Todas as transações podem violar a consistência do GTID, mas um aviso é gerado.

Nota

Para instâncias do Banco de Dados do Azure para Servidor Flexível MySQL que têm o recurso de Alta Disponibilidade habilitado, o valor padrão é definido como ON.

Depois de ativar o GTID, não é possível desativá-lo. Se você precisar desativar o GTID, entre em contato com o suporte.

Você pode alterar GTIDs de um valor para outro apenas uma etapa de cada vez em ordem crescente de modos. Por exemplo, se gtid_mode estiver atualmente definido como OFF_PERMISSIVE, você pode alterá-lo para ON_PERMISSIVE , mas não para ON.

Para manter a replicação consistente, não é possível atualizá-la para um servidor primário ou de réplica.

Defina enforce_gtid_consistency como ON antes de definir gtid_mode como ON.

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros e enforce_gtid_consistency do gtid_mode servidor. Use Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure ou Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando a CLI do Azure.

Se um servidor de origem habilitar o GTID (gtid_mode = ON), as réplicas recém-criadas também habilitarão o GTID e usarão a replicação GTID. Para garantir a consistência da replicação, não é possível alterar gtid_mode depois de criar servidores primários ou de réplica com o GTID habilitado.

Considerações e limitações

Cenário Limitação/Consideração
Réplica no servidor no nível de preços Burstable Não suportado
Preços O custo de execução do servidor de réplica depende da região em que o servidor de réplica é executado.
Tempo de inatividade/reinicialização do servidor de origem Nenhum tempo de reinicialização ou inatividade é necessário ao criar uma réplica de leitura. Esta operação é uma operação online.
Novas réplicas Você cria uma réplica de leitura como uma nova instância do Banco de Dados do Azure para o Servidor Flexível MySQL. Não é possível transformar um servidor existente em uma réplica. Não é possível criar uma réplica de outra réplica de leitura.
Configuração da réplica Você cria uma réplica usando a mesma configuração de servidor que a origem. Depois de criar uma réplica, você pode alterar várias configurações independentemente do servidor de origem: geração de computação, vCores, armazenamento e período de retenção de backup. Você também pode alterar a camada de computação independentemente.

IMPORTANTE - Antes de atualizar uma configuração do servidor de origem para novos valores, atualize a configuração da réplica para valores iguais ou maiores. Esta ação garante que a réplica pode acompanhar quaisquer alterações feitas na origem.
O método de conectividade e as configurações de parâmetros são herdados do servidor de origem para a réplica quando você cria a réplica. Depois, as regras da réplica são independentes.
Réplicas interrompidas 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. Não é possível transformar o servidor autônomo em uma réplica novamente.
Servidores de origem excluídos Quando você exclui um servidor de origem, a replicação é interrompida para todas as réplicas de leitura. Essas réplicas se tornam automaticamente servidores autônomos e podem aceitar leituras e gravações. O próprio servidor de origem é excluído.
Contas de utilizador 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 dessincronizados e evitar potenciais perdas de dados ou corrupção, a atualização de alguns parâmetros de servidor é bloqueada ao utilizar réplicas de leitura.
Os seguintes parâmetros de servidor estão bloqueados nos servidores de origem e de réplica:
- innodb_file_per_table
- log_bin_trust_function_creators
O event_scheduler parâmetro está bloqueado nos servidores de réplica.
Para atualizar um dos parâmetros anteriores no servidor de origem, exclua os servidores de réplica, atualize o valor do parâmetro na origem e recrie réplicas.
Parâmetros de nível de sessão Ao configurar parâmetros de nível de sessão, como 'foreign_keys_checks' na réplica de leitura, verifique se os valores de parâmetro que você está definindo na réplica de leitura são consistentes com os do servidor de origem.
Adicionando uma coluna de Chave Primária AUTO_INCREMENT à tabela existente no servidor de origem Não recomendamos alterar a tabela com AUTO_INCREMENT depois de criar uma réplica de leitura, pois essa ação interrompe a replicação. Se você quiser adicionar uma coluna de incremento automático depois de criar um servidor de réplica, considere estas abordagens:
- Crie uma nova tabela com o mesmo esquema da tabela que você deseja modificar. Na nova tabela, altere a coluna com AUTO_INCREMENTe restaure os dados da tabela original. Solte a tabela antiga e renomeie-a na fonte; Essa abordagem não requer a exclusão do servidor de réplica, mas pode incorrer em um grande custo de inserção para criar uma tabela de backup.
- Recrie a réplica depois de adicionar todas as colunas de incremento automático.
Outro - A criação de uma réplica de uma réplica não é suportada.
- As tabelas na memória podem fazer com que as réplicas fiquem fora de sincronia. Esta limitação deve-se à tecnologia de replicação MySQL. Para obter mais informações, consulte a documentação de referência do MySQL.
- Verifique se as tabelas do servidor de origem tê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.
- Revise a lista completa de limitações de replicação do MySQL na documentação do MySQL.

Conteúdos relacionados

  • Last updated on