Compartilhar via

Replicar dados no Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor flexível

A replicação de dados permite sincronizar os dados de um servidor MySQL externo em um Servidor Flexível do Banco de Dados do Azure para MySQL. O servidor externo pode estar no local, em máquinas virtuais, no servidor único do Banco de Dados do Azure para MySQL ou em um host de serviço de banco de dados de outros provedores de nuvem. A replicação de dados se baseia na posição do arquivo de log binário (binlog) ou na replicação baseada no GTID. Para saber mais sobre a replicação do binlog, confira a Replicação do MySQL.

Observação

Só há suporte para a configuração da replicação de dados para servidores habilitados com alta disponibilidade por meio da replicação baseada em GTID.

Quando usar a replicação de dados

Os cenários principais a serem considerados o uso da replicação de dados são:

  • Sincronização de Dados Híbrida: com a replicação nos dados, você pode manter os dados sincronizados entre os servidores locais e o Banco de Dados do Azure para Servidor Flexível MySQL. Essa sincronização ajuda a criar aplicativos híbridos. Esse método é atraente quando você tem um servidor de banco de dados local existente, mas deseja mover os dados para uma região mais próxima aos usuários finais.
  • Sincronização de várias Nuvens: para soluções de nuvem complexas, use a replicação nos dados para sincronizar dados entre o Banco de Dados do Azure para Servidor Flexível MySQL e provedores de nuvem diferentes, incluindo máquinas virtuais e serviços de banco de dados nessas nuvens.
  • Migração: Os clientes podem migrar em Tempo Mínimo usando ferramentas de código aberto, como MyDumper/MyLoader com replicação de dados. Uma migração seletiva de carga de produção do banco de dados de origem para o de destino é possível com a replicação de dados.

Para cenários de migração, use o DMS (Serviço de Migração de Banco de Dados) do Azure.

Limitações e considerações

Dados não replicados

O banco de dados do sistema mysql no servidor de origem não é replicado. Além disso, as alterações em contas e permissões no servidor de origem não são replicadas. Para criar uma conta no servidor de origem e essa conta precisar acessar o servidor de réplica, crie manualmente a mesma conta no lado do servidor de réplica. Para entender as tabelas no banco de dados do sistema, consulte o Manual do MySQL.

Existe suporte para a replicação de dados em servidores habilitados para Alta Disponibilidade (HA)

O suporte para replicação de dados para servidor habilitado para alta disponibilidade (HA) só está disponível por meio da replicação baseada em GTID.

O procedimento armazenado para replicação usando GTID está disponível em todos os servidores habilitados para HA pelo nome mysql.az_replication_change_master_with_gtid.

Filtrar

O parâmetro replicate_wild_ignore_table cria um filtro de replicação para tabelas no servidor réplica. Para modificar esse parâmetro no portal do Azure, navegue até a instância do Servidor Flexível do Banco de Dados do Azure para MySQL usada como réplica e selecione “Parâmetros de Servidor” para exibir/editar o parâmetro replicate_wild_ignore_table.

Requisitos

  • A versão do servidor de origem deve ser pelo menos a versão 5.7 do MySQL.

  • Recomendamos ter a mesma versão para os servidores de origem e de réplica. Por exemplo, ambos devem ser MySQL versão 5.7 ou ambos devem ser MySQL versão 8.0.

  • Recomendamos ter uma chave primária em cada tabela. Se tivermos uma tabela sem uma chave primária, você talvez enfrente lentidão na replicação.

  • O servidor de origem deve usar o mecanismo InnoDB do MySQL.

  • O usuário deve ter as permissões corretas para configurar o registro em log binário e criar novos usuários no servidor de origem.

  • Os arquivos de log binários no servidor de origem não devem ser limpos antes que a réplica aplique essas alterações. Se a origem for o Servidor Flexível do Banco de Dados do Azure para MySQL, veja como configurar binlog_expire_logs_seconds para Servidor flexível ou Servidor único

  • Se o servidor de origem tem o SSL habilitado, verifique se o certificado de Autoridade de Certificação SSL fornecido para o domínio foi incluído no procedimento armazenado mysql.az_replication_change_master. Confira os seguintes exemplos e o parâmetro master_ssl_ca.

  • Garanta que o computador que hospeda o servidor de origem permita tráfego de entrada e saída na porta 3306.

  • Com o acesso público, verifique se o servidor de origem tem um endereço IP público, se o DNS está acessível publicamente ou se o servidor de origem tem um nome de domínio totalmente qualificado (FQDN). Se você tiver um ponto de extremidade privado e tiver desabilitado o acesso público, a replicação nos dados não terá suporte

  • Com o acesso privado (Integração VNET), verifique se o nome do servidor de origem pode ser resolvido e se ele está acessível na VNet em que a instância do Servidor Flexível do Banco de Dados do Azure para MySQL está em execução. (Para saber mais detalhes, visite Resolução de nomes para recursos em redes virtuais do Azure.)

Chave Primária Invisível Gerada

No MySQL versão 8.0 e superior, as GIPK (Chaves Primárias Invisíveis Geradas) são habilitadas por padrão para todas as instâncias do Servidor Flexível do Banco de Dados do Azure para MySQL. Os servidores MySQL 8.0+ adicionam a coluna invisível my_row_id às tabelas e uma chave primária nessa coluna, onde a tabela InnoDB é criada sem uma chave primária explícita. Esse recurso, quando habilitado, pode afetar alguns dos casos de uso de replicação de dados, conforme descrito abaixo:

  • A replicação de dados falha com o erro de replicação: "ERRO 1068 (42000): várias chaves primárias definidas" se o servidor de origem criar uma Chave primária na tabela sem Chave Primária. Para mitigação, execute o comando SQL a seguir, ignore o erro de replicação e reinicie a replicação de dados.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Falha na replicação de dados com o erro de replicação: "ERRO 1075 (42000): definição de tabela incorreta; pode haver apenas uma coluna automática e ela deverá ser definida como uma chave" se o servidor de origem adicionar uma coluna auto_increment como Chave Única. Para mitigação, execute o comando SQL a seguir, defina "sql_generate_invisible_primary_key" como OFF, ignore o erro de replicação e reinicie a replicação de dados.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • A replicação de dados falhará se o servidor de origem executar qualquer outro SQL que não tenha suporte quando "sql_generate_invisible_primary_key" estiver ATIVADO. Por exemplo, crie uma tabela de partição. Nesse cenário, a mitigação é definir "sql_generate_invisible_primary_key" como OFF e reiniciar a replicação de dados.

Próximas etapas