Compartilhar via

Réplicas de leitura no Azure Database para Servidor flexível do MySQL

  • Artigo

O MySQL é um dos mecanismos de banco de dados populares para a execução de aplicativos Web e móveis de escala da Internet. Muitos de nossos clientes o utilizam para os serviços de treinamento online, serviços de streaming de vídeo, soluções de pagamento digital, plataformas de comércio eletrônico, serviços de jogos, portais de notícias, governo e sites de saúde. Esses serviços são necessários para serem fornecidos e dimensionados conforme o tráfego no aplicativo Web ou móvel aumenta.

No lado dos aplicativos, o aplicativo normalmente é desenvolvido em Java ou PHP e migrado para ser executado em Conjuntos de Dimensionamento de Máquinas Virtuais do Azure ou Serviços de Aplicativos do Azure, ou são conteinerizados para serem executados no AKS (Serviço de Kubernetes do Azure). Com o Conjunto de Dimensionamento de Máquinas Virtuais, o Serviço de Aplicativo ou o AKS como infraestrutura subjacente, a escala do aplicativo é simplificada provisionando instantaneamente novas VMs e replicando os componentes de aplicativos sem estado para atender às solicitações, mas geralmente o banco de dados acaba sendo um gargalo como componente com estado centralizado.

O recurso de réplica de leitura permite que você replique 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 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 forma semelhante às instâncias de Servidor Flexível do Banco de Dados do Azure para MySQL de origem. Você terá cobranças de cada réplica de leitura com base na computação provisionada em vCores e no armazenamento em GB/mês. Para saber mais, confira os preços.

Observação

O recurso de réplica de leitura está disponível apenas para as instâncias de Servidor Flexível do Banco de Dados do Azure para MySQL nas camadas de preços de Uso Geral ou Comercialmente Crítico. Verifique se o servidor de origem está em um desses tipos de preços.

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.

Casos de uso comuns para 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.

Os cenários mais comuns são:

  • Dimensionamento de cargas de leitura de trabalho provenientes do aplicativo usando o proxy de conexão leve como ProxySQL, ou usando o padrão baseado em microsserviço para escalar horizontalmente suas consultas de leitura provenientes do aplicativo para ler as réplicas
  • As cargas de trabalho de BI ou de relatório analítico podem usar réplicas de leitura como fonte de dados para relatórios
  • Para o cenário de Manufatura ou IoT, em que as informações de telemetria são ingeridas no mecanismo de banco de dados MySQL enquanto várias réplicas de leitura são usadas para relatórios de dados

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. Há 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. O Servidor Flexível do Banco de Dados do Azure para MySQL permite provisionar uma réplica de leitura em todas as regiões com suporte do Azure em que o Servidor Flexível do Banco de Dados MySQL do Azure. Usando esse recurso, um servidor de origem pode ter uma réplica na respectiva região emparelhada ou nas regiões de réplica universal. Consulte aqui para localizar a lista de regiões do Azure em que o Servidor Flexível do Banco de Dados do Azure para MySQL está disponível hoje.

Criar uma réplica

Se um servidor de origem não tiver servidores de réplica, a origem será reiniciada primeiro para se preparar para a replicação.

Quando você inicia o fluxo de trabalho de criação de réplica, uma instância de Servidor Flexível do Banco de Dados do Azure para MySQL em branco é criada. 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.

Observação

As réplicas de leitura são criadas com a mesma configuração de servidor que a origem. A configuração do servidor de réplica pode ser alterada depois de criada. 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, poderá mover o servidor de réplica após a criação. É recomendável que a configuração do servidor de réplica seja mantida em valores iguais ou maiores do que a origem para garantir que a réplica seja capaz de acompanhar a origem.

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

Conectar-se a uma réplica

Em sua criação, a réplica 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 tiver Acesso privado (integração VNet), a réplica não poderá estar no Acesso público (endereços de IP permitidos).

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 uma instância do Servidor Flexível 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 -p

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

Monitorar a replicação

O Azure Database para Servidor Flexível do 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.

Importante

A Réplica de Leitura utiliza a tecnologia de replicação baseada em armazenamento, que não usa mais a métrica 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' disponível no comando 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' do MySQL. Esse valor sempre é exibido como "Não" e não é um indicativo do status de replicação. Para saber o status correto da replicação, consulte as métricas de replicação – Status de E/S da Réplica e Status do SQL da Réplica na Folha de monitoramento.

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.

As réplicas de leitura destinam-se ao dimensionamento de cargas de trabalho de leitura intensiva e não são projetadas para atender às necessidades de alta disponibilidade de um servidor. Parar a replicação na réplica de leitura para colocá-la online no modo de leitura/gravação é o meio pelo qual esse failover manual é executado.

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 é 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 do seu aplicativo depende de quando você detecta um problema e conclui as etapas 1 e 2 acima.

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á OFF por padrão no Servidor Flexível do Banco de Dados do Azure para MySQL. GTID tem suporte nas versões 5.7 e 8.0. Para saber mais sobre o GTID e como ele é usado na replicação, consulte a documentação de replicação do MySQL com GTID.

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.

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

Observação

  • Depois que o GTID estiver habilitado, você não poderá desativá-lo. Se você precisar desativar GTID, entre em contato com o suporte.
  • Você pode 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.
  • É recomendável DEFINIR enforce_gtid_consistency como ATIVADO antes de definir gtid_mode=ON.

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros de servidor gtid_mode e enforce_gtid_consistency usando o 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 o 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 master 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ço com capacidade de intermitência Sem suporte
Preços 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 Ao criar uma réplica para uma origem que não tem réplicas existentes, primeiro a origem será reiniciada para se preparar para a replicação. Leve isso em consideração e realize essas operações durante um período de pouca atividade
Novas réplicas Uma réplica de leitura é criada como uma nova instância do Servidor Flexível do 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. A camada de computação também pode ser alterada de forma independente.

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.
Método de conexão e configurações de parâmetros são herdados 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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Parâmetros de nível de sessão Ao configurar parâmetros de nível de sessão, como 'foreign_keys_check' na réplica de leitura, verifique se os valores do parâmetro que estão sendo definidos na réplica de leitura são consistentes com os do servidor de origem.
Adicionando a coluna de Chave Primária AUTO_INCREMENT à tabela existente no servidor de origem. Não recomendamos alterar a tabela após a criação da réplica de leitura AUTO_INCREMENT, pois ela interrompe a replicação. No entanto, caso você queira adicionar a postagem de coluna de incremento automático criando um servidor de réplica, recomendamos estas duas abordagens:
– Crie uma nova tabela com o mesmo esquema de tabela que você deseja modificar. Na nova tabela, altere a coluna com AUTO_INCREMENT e restaure os dados a partir da tabela original. Remova a tabela antiga e renomeie-a na origem, com isso não será necessária a nossa intervenção para excluir o servidor de réplica, mas pode levar a um grande custo de inserção para criar uma tabela de backup.
– O outro método mais rápido é recriar a réplica depois de adicionar todas as colunas de incremento automático.
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 na Documentação do MySQL

Conteúdo relacionado