Replicar dados para a Base 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 dados de um servidor MySQL externo em uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL. O servidor externo pode ser local, em máquinas virtuais, Banco de Dados do Azure para servidor único MySQL ou um serviço de banco de dados hospedado por outros provedores de nuvem. A replicação de dados é baseada na posição do arquivo de log binário (binlog) ou na replicação baseada em GTID. Para saber mais sobre a replicação binlog, consulte a Replicação MySQL.

Nota

A configuração da replicação Data-in para servidores habilitados com alta disponibilidade é suportada somente por meio da replicação baseada em GTID.

Quando usar a replicação de dados

Os principais cenários a serem considerados sobre o uso da replicação Data-in são:

  • Sincronização de dados híbrida: com a replicação de dados, você pode manter os dados sincronizados entre seus servidores locais e o Banco de Dados do Azure para o 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 dos usuários finais.
  • Sincronização Multinuvem: Para soluções de nuvem complexas, use a replicação de dados para sincronizar dados entre o Banco de Dados do Azure para o Servidor Flexível MySQL e diferentes provedores de nuvem, incluindo máquinas virtuais e serviços de banco de dados hospedados 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 transferência seletiva da 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 nas contas e permissões no servidor de origem não são replicadas. Se você criar uma conta no servidor de origem e essa conta precisar acessar o servidor de réplica, crie manualmente a mesma conta no servidor de réplica. Para entender as tabelas no banco de dados do sistema, consulte o manual do MySQL.

A replicação de dados é suportada em servidores habilitados para Alta Disponibilidade (HA)

O suporte para replicação de dados para servidor habilitado para alta disponibilidade (HA) está disponível somente 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.

Filtro

O parâmetro replicate_wild_ignore_table cria um filtro de replicação para tabelas no servidor de réplica. Para modificar esse parâmetro do 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 do Servidor" para exibir/editar o replicate_wild_ignore_table parâmetro.

Requisitos

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

  • Nossa recomendação é ter a mesma versão para as versões de servidor de origem e réplica. Por exemplo, ambos devem ser MySQL versão 5.7, ou ambos devem ser MySQL versão 8.0.

  • Nossa recomendação é ter uma chave primária em cada tabela. Se tivermos uma tabela sem uma chave primária, você poderá enfrentar lentidão na replicação.

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

  • O usuário deve ter as permissões corretas para configurar o 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 Banco de Dados do Azure para Servidor Flexível MySQL, consulte como configurar o binlog_expire_logs_seconds para Servidor Flexível ou Servidor Único

  • Se o servidor de origem tiver SSL habilitado, verifique se o certificado de CA SSL fornecido para o domínio foi incluído no mysql.az_replication_change_master procedimento armazenado. Consulte os exemplos a seguir e o master_ssl_ca parâmetro.

  • Certifique-se de que a máquina que hospeda o servidor de origem permita tráfego de entrada e de saída na porta 3306.

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

  • Com acesso privado (Integração VNet), certifique-se de que o nome do servidor de origem possa ser resolvido e esteja acessível a partir da VNet onde a instância do Banco de Dados do Azure para Servidor Flexível MySQL está sendo executada. (Para mais detalhes, visite Resolução de nomes para recursos em redes virtuais do Azure).

Chave primária invisível gerada

Para o MySQL versão 8.0 e superior, as Chaves Primárias Invisíveis Geradas (GIPK) são habilitadas por padrão para todas as instâncias do Banco de Dados do Azure para o Servidor Flexível do 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 erro de replicação: "ERRO 1068 (42000): Chave primária múltipla definida" se o servidor de origem criar uma chave primária na tabela sem chave primária. Para mitigação, execute o seguinte comando sql, 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>);

  • A replicação de dados falha com erro de replicação: "ERRO 1075 (42000): Definição de tabela incorreta; pode haver apenas uma coluna automática e ela deve ser definida como uma chave" se o servidor de origem adicionar uma coluna auto_increment como Chave Exclusiva. Para mitigação, execute o seguinte comando sql, 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 seja suportado 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óximos passos