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 dados de um servidor MySQL externo em uma instância de 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

A configuração da replicação de entrada de dados para servidores habilitados com alta disponibilidade é suportada somente 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 de dados, você pode manter os dados sincronizados entre seus servidores locais e o servidor flexível do Banco de Dados do Azure para 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 de dados para sincronizar dados entre o servidor flexível do Banco de Dados do Azure para 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 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 de 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 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 Banco de Dados do Azure para servidor flexível MySQL, consulte 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).
  • Com acesso privado, verifique se o nome do servidor de origem pode ser resolvido e está acessível na rede virtual em que a instância do servidor flexível do Banco de Dados do Azure para MySQL está sendo executada. (Para saber 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 de 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