Compartilhar via

Migrar o MySQL local para o Banco de Dados do Azure para MySQL - Avaliação

  • Artigo

Avaliar a migração de bancos de dados MySQL de ambientes locais para o Banco de Dados do Azure para MySQL é uma etapa fundamental para garantir uma transição suave e bem-sucedida. Este artigo examina minuciosamente os principais fatores e considerações envolvidos na fase de avaliação. Você pode tomar decisões informadas que se alinham às metas da sua organização avaliando sua infraestrutura atual, identificando possíveis desafios e entendendo os benefícios dos serviços de banco de dados gerenciados do Azure. Se você pretende aprimorar o desempenho, melhorar a escalabilidade ou reduzir os custos operacionais, este guia fornecerá as informações necessárias para planejar e executar efetivamente sua estratégia de migração.

Pré-requisitos

Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Caso de uso representativo

Visão geral

Antes de você ir diretamente para a migração de uma carga de trabalho do MySQL, há uma quantidade razoável de auditoria detalhada que precisa ser realizada. Isso inclui a análise dos dados, do ambiente de hospedagem e das cargas de trabalho do aplicativo para validar se a zona de destino do Azure está configurada corretamente e preparada para hospedar as cargas de trabalho que serão migradas em breve.

Limitações

O Banco de Dados do Azure para MySQL é uma versão totalmente compatível com o MySQL Community Edition em execução como uma plataforma como serviço. No entanto, há algumas limitações com as quais você deve se familiarizar ao fazer uma avaliação inicial.

As mais importantes incluem:

  • Suporte ao mecanismo de armazenamento somente para InnoDB e Memory

  • Suporte limitado para Privilege (DBA, SUPER, DEFINER)

  • Instruções de tratamento de dados desabilitadas (SELECT ... INTO OUTFILE, LOAD DATA INFILE)

  • Migração de banco de dados automática significativa (5.6 a 5.7, 5.7 a 8.0)

  • Ao usar as UDFs (funções definidas pelo usuário) do MySQL Server, a única opção de hospedagem viável são as VMs hospedadas no Azure, pois não há capacidade para carregar o componente so ou dll no Banco de Dados do Azure para MySQL.

Muitos dos outros itens são aspectos operacionais com os quais os administradores devem se familiarizar como parte do gerenciamento do ciclo de vida da carga de trabalho de dados operacionais. Este guia vai explorar muitos desses aspectos operacionais na seção Gerenciamento pós-migração.

Versões do MySQL

O MySQL tem uma história impressionante que começou em 1995. Desde então, ele evoluiu para se tornar um sistema de gerenciamento de banco de dados amplamente usado. O Banco de Dados do Azure para MySQL começou com o suporte do MySQL versão 5.6 e prosseguiu para a 5.7, chegando, recentemente, à versão 8.0. Para obter as novidades sobre o suporte de versão do Banco de Dados do Azure para MySQL, confira Versões compatíveis do servidor do Banco de Dados do Azure para MySQL. Na seção Gerenciamento pós-migração, examinaremos como as atualizações (como a 5.7.20 para a 5.7.21) são aplicadas às instâncias do MySQL no Azure.

Observação

O salto da 5.x para a 8.0 ocorreu, em grande parte, devido à aquisição do MySQL pela Oracle. Para ler mais sobre a história do MySQL, navegue até a página do wiki do MySQL.

Conhecer a versão de origem do MySQL é essencial. Os aplicativos que usam o sistema podem estar usando objetos de banco de dados e recursos específicos dessa versão. A migração de um banco de dados para uma versão inferior pode causar problemas de compatibilidade e perda de funcionalidade. Também é recomendável que os dados e a instância do aplicativo sejam testados exaustivamente antes de serem migrados para uma versão mais recente, pois os recursos introduzidos podem interromper o aplicativo.

Exemplos que podem influenciar o caminho de migração e a versão:

  • 5.6: coluna TIMESTAMP para o armazenamento correto de milissegundos e pesquisa de texto completo

  • 5.7: suporte para o tipo de dados JSON nativo

  • 8.0: suporte para o repositório de documentos NoSQL e as funções de tabela JSON e DDL atômicas e livres de falhas

    Observação

    O MySQL 5.6 perderá o suporte geral em fevereiro de 2021. As cargas de trabalho do MySQL precisarão migrar para o MySQL versão 5.7 ou superior.

Para verificar a versão do servidor MySQL:

SHOW VARIABLES LIKE "%version%";

Mecanismos de armazenamento de banco de dados

O Banco de Dados do Azure para MySQL só dá suporte aos mecanismos de armazenamento de banco de dados InnoDB e Memory. Outros mecanismos de armazenamento, como o MyISAM, precisarão ser migrados para um mecanismo de armazenamento compatível. As diferenças entre o MyISAM e o InnoDB são os recursos operacionais e a saída de desempenho. As tabelas de nível superior e a estrutura do esquema normalmente não são alteradas entre os mecanismos, mas os tipos de coluna de índice e tabela podem ser alterados por motivos de desempenho e armazenamento. Embora o InnoDB seja conhecido por ter tamanhos de arquivo de dados grandes, esses detalhes de armazenamento são gerenciados pelo serviço do Banco de Dados do Azure para MySQL.

Migrar do MyISAM para o InnoDB

O banco de dados e as tabelas do MyISAM precisarão ser convertidos em tabelas do InnoDB. Após a conversão, os aplicativos devem ser testados quanto à compatibilidade e ao desempenho. Na maioria dos casos, o teste exige a recriação da tabela e a alteração do mecanismo de armazenamento de destino por meio de instruções DDL. É improvável que essa alteração precise ser feita durante a migração, pois ela ocorre durante a criação do esquema no destino do Azure. Para obter mais detalhes, examine a documentação para desenvolvedores sobre como converter tabelas no site do MySQL.

Para localizar informações úteis da tabela, use esta consulta:

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

Observação

A execução da consulta no INFORMATION_SCHEMA em vários bancos de dados pode afetar o desempenho. Execução durante períodos de pouco uso.

Para converter uma tabela do MyISAM no InnoDB, execute o seguinte:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Observação

Essa abordagem de conversão faz com que a tabela seja bloqueada, e assim todos os aplicativos podem aguardar até que a operação seja concluída. O bloqueio de tabela faz com que o banco de dados seja exibido como offline por um breve período.

Em vez disso, a tabela pode ser criada com a mesma estrutura, mas com outro mecanismo de armazenamento. Depois que a tabela for criada, copie as linhas para a nova tabela:

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Observação

Para que essa abordagem seja bem-sucedida, a tabela original precisará ser excluída e a nova tabela será renomeada. Essa tarefa causa um breve período de inatividade.

Dados e objetos de bancos de dados

Os dados são um componente da migração de banco de dados. Os objetos que dão suporte ao banco de dados precisam ser migrados e validados para garantir que os aplicativos continuem sendo executados de modo confiável.

Esta é uma lista de itens que você deve inventariar antes e depois da migração:

  • Tabelas (esquema)

  • Chaves primárias, chaves estrangeiras

  • Índices

  • Funções

  • Procedimentos

  • Gatilhos

  • Exibições

Funções definidas pelo usuário

O MySQL permite o uso de funções que chamam um código externo. Infelizmente, as cargas de trabalho de dados que usam UDFs (funções definidas pelo usuário) com um código externo não podem ser migradas para o Banco de Dados do Azure para MySQL. Isso ocorre porque o suporte da função MySQL necessária para isso ou o código DLL não podem ser carregados no servidor do Azure.

Execute a seguinte consulta para encontrar as UDFs que podem ser instaladas:

SELECT * FROM mysql.func;

Sistemas de origem

A quantidade de preparação de migração pode variar dependendo do sistema de origem e da localização. Além dos objetos de banco de dados, considere como inserir os dados do sistema de origem no sistema de destino. A migração de dados pode se tornar complexa quando os firewalls e outros componentes de rede estão entre a origem e o destino.

Além disso, a migração de dados pela Internet pode ser mais lenta do que o uso de circuitos dedicados para o Azure. Portanto, ao migrar muitos gigabytes, terabytes e petabytes de dados, considere a possibilidade de configurar uma conexão do ExpressRoute entre a rede de origem e a rede do Azure.

Se o ExpressRoute já está presente, é provável que a conexão esteja sendo usada por outros aplicativos. A execução de uma migração em uma rota existente pode causar sobrecarga na taxa de transferência da rede e um impacto significativo no desempenho para a migração e os outros aplicativos que usam a rede.

Por fim, o espaço em disco precisa ser avaliado. Ao exportar um banco de dados grande, considere o tamanho dos dados. Verifique se o sistema no qual a ferramenta está em execução e, por fim, a localização de exportação têm espaço em disco suficiente para executar a operação de exportação.

Provedores de nuvem

A migração de bancos de dados de provedores de serviços de nuvem como a AWS (Amazon Web Services) pode exigir uma etapa de configuração de rede adicional para acessar as instâncias do MySQL hospedadas na nuvem. As ferramentas de migração, como os Serviços de Migração de Dados, exigem o acesso em intervalos de IP externos e podem ser bloqueadas de outra forma.

Local

Assim como os provedores de nuvem, se a carga de trabalho de dados do MySQL estiver atrás de firewalls ou de outras camadas de segurança de rede, um caminho precisará ser criado entre a instância local e o Banco de Dados do Azure para MySQL.

Ferramentas

Uma variedade de ferramentas e métodos pode ser usada para avaliar os ambientes e as cargas de trabalho de dados do MySQL. Cada ferramenta fornece um conjunto diferente de recursos e funcionalidades de avaliação e migração. Como parte deste guia, examinaremos as ferramentas usadas com mais frequência para avaliar as cargas de trabalho de dados do MySQL.

Migrações para Azure

Embora as Migrações para Azure não deem suporte à migração de cargas de trabalho de banco de dados MySQL diretamente, elas podem ser usadas quando os administradores não têm certeza de quais usuários e aplicativos estão consumindo os dados, sejam hospedados em um computador virtual ou baseado em hardware. A análise de dependência pode ser feita pela instalação e pela execução do agente de monitoramento no computador que hospeda a carga de trabalho do MySQL. O agente coleta as informações em um período definido, como um mês. Os dados de dependência podem ser analisados para localizar conexões desconhecidas que estão sendo feitas com o banco de dados. Os dados da conexão podem ajudar a identificar os proprietários de aplicativos que precisam ser notificados sobre a migração pendente.

Além da análise de dependência de aplicativos e dados de conectividade do usuário, as Migrações para Azure também podem ser usadas para analisar o Hyper-V, o VMware ou os servidores físicos para fornecer padrões de utilização das cargas de trabalho do banco de dados e ajudar a sugerir o ambiente de destino adequado.

Telgraf para Linux

As cargas de trabalho do Linux podem utilizar o MMA (Microsoft Monitoring Agent) para coletar dados nas máquinas virtuais e nos computadores físicos. Além disso, considere o uso do agente do Telegraf e da ampla gama de plug-ins oferecidos por ele para coletar suas métricas de desempenho.

Camadas de serviço

Equipado com as informações de avaliação (CPU, memória, armazenamento etc.), a próxima opção do usuário da migração é decidir qual tipo de preço do Banco de Dados do Azure para MySQL ele começará usando.

Atualmente, há três camadas:

  • Básico: cargas de trabalho que exigem desempenho de E/S e computação leve.

  • Uso Geral: a maioria das cargas de trabalho que exige computação e memória balanceadas com taxa de transferência de E/S escalonável.

  • Otimizado para memória: cargas de trabalho de banco de dados de alto desempenho que exigem desempenho na memória para o processamento mais rápido de transações e uma simultaneidade mais alta.

A decisão da camada pode ser influenciada pelos requisitos de RTO e RPO da carga de trabalho de dados. Quando a carga de trabalho de dados exige mais de 4 TB de armazenamento, é necessária uma etapa extra. Examine e selecione uma região que dê suporte a até 16 TB de armazenamento.

Normalmente, a tomada de decisões foca nas necessidades de armazenamento e de IOPS, ou nas operações de entrada/saída por segundo. Portanto, o sistema de destino sempre precisará ter, pelo menos, a mesma quantidade de armazenamento existente no sistema de origem. Além disso, como a IOPS recebe 3/GB, é importante corresponder as necessidades de IOPS ao tamanho final do armazenamento.

Fatores Camada
Basic Computador de desenvolvimento, sem a necessidade de alto desempenho e com menos de 1 TB de armazenamento.
Uso Geral Necessidades de mais IOPS do que a camada básica pode fornecer, mas para um armazenamento inferior a 16 TB e com menos de 4 GB de memória.
Otimizado para memória Cargas de trabalho de dados que utilizam memória alta ou cache alto e configuração de servidor relacionada ao buffer, como innodb_buffer_pool_instances de alta simultaneidade, tamanhos de blobs grandes e sistemas com muitas cópias de replicação.

Custos

Depois de avaliar todas as respectivas cargas de trabalho de dados do MySQL, a WWI determinou que precisaria de, pelo menos, 4 vCores e 20 GB de memória e, no mínimo, 100 GB de espaço de armazenamento com uma capacidade de IOP de 450 IOPS. Devido ao requisito de 450 IOPS, ela precisa alocar, pelo menos, 150 GB de armazenamento devido ao método de alocação de IOPS do Banco de Dados do Azure para MySQL. Além disso, ela exige, no mínimo, até 100% do seu armazenamento de servidor provisionado como um armazenamento de backup e uma réplica de leitura. Ela não prevê uma saída superior a 5 GB.

Usando a calculadora de preços do Banco de Dados do Azure para MySQL, a WWI conseguiu determinar os custos da instância do Banco de Dados do Azure para MySQL. Desde 9/2020, o TCO (custo total de propriedade) é exibido na seguinte tabela para o banco de dados de conferência da WWI.

Recurso Descrição Quantidade Custo
Computação (Uso Geral) 4 vCores, 20 GB 1 a US$ 0,351/hora US$ 3.074,76/ano
Armazenamento 5 GB 12 x 150 a US$ 0,115 US$ 207/ano
Backup Até 100% de armazenamento provisionado Nenhum custo extra em até 100% de armazenamento de servidor provisionado US$ 0,00/ano
Réplica de leitura Réplica de região de 1 segundo computação + armazenamento US$ 3.281,76/ano
Rede < Saída de 5GB/mês Gratuita
Total US$ 6.563,52/ano

Depois de examinar os custos iniciais, o CIO da WWI confirmou que ela está no Azure por um período muito superior a três anos. Ela decidiu usar as instâncias de reserva de três anos para economizar um valor adicional de ~US$ 4 mil/ano.

Recurso Descrição Quantidade Custo
Computação (Uso Geral) 4 vCores 1 a US$ 0,1375/hora US$ 1.204,5/ano
Armazenamento 5 GB 12 x 150 a US$ 0,115 US$ 207/ano
Backup Até 100% de armazenamento provisionado Nenhum custo extra em até 100% de armazenamento de servidor provisionado US$ 0,00/ano
Rede < Saída de 5GB/mês Gratuita
Réplica de leitura Réplica de região de 1 segundo computação + armazenamento US$ 1.411,5/ano
Total US$ 2,823/ano

Conforme mostra a tabela acima, os backups, a saída de rede e as réplicas de leitura precisam ser considerados no TCO (custo total de propriedade). À medida que mais bancos de dados são adicionados, o tráfego de rede e o armazenamento gerados são o único fator adicional baseado em custo a ser considerado.

Observação

As estimativas indicadas acima não incluem nenhum custo do ExpressRoute, do Gateway de Aplicativo do Azure, do Azure Load Balancer ou do Serviço de Aplicativo para as camadas do aplicativo.

O preço indicado acima pode ser alterado a qualquer momento e varia conforme a região.

Implicações do aplicativo

Quando você migrar para o Banco de Dados do Azure para MySQL, a conversão na comunicação baseada no protocolo SSL provavelmente será uma das alterações mais significativas para seus aplicativos. O SSL está habilitado por padrão no Banco de Dados do Azure para MySQL, e é provável que o aplicativo local e a carga de trabalho de dados não estejam configurados para se conectarem ao MySQL por meio do SSL. Quando habilitado, o uso do SSL adiciona uma sobrecarga de processamento extra, e deve ser monitorado.

Observação

Embora o SSL esteja habilitado por padrão, você tem a opção de desabilitá-lo.

Siga as atividades descritas em Configurar a conectividade SSL no seu aplicativo para se conectar com segurança ao Banco de Dados do Azure para MySQL para reconfigurar o aplicativo a fim de dar suporte a esse caminho de autenticação forte.

Por fim, modifique o nome do servidor nas cadeias de conexão do aplicativo ou alterne o DNS para que ele aponte para o novo servidor do Banco de Dados do Azure para MySQL.

Cenário da WWI

A WWI iniciou a avaliação coletando informações sobre os ativos de dados do MySQL, conforme mostrado na tabela a seguir.

Nome Fonte Mecanismo de BD Tamanho IOPS Versão Proprietário Tempo de inatividade
WwwDB AWS (PaaS) InnoDB 1 GB 150 5.7 Departamento de marketing 1 hora
BlogDB AWS (PaaS) InnoDB 1 GB 100 5.7 Departamento de marketing 4 horas
ConferenceDB Local InnoDB 5 GB 50 5.5 Departamento de vendas 4 horas
CustomerDB Local InnoDB 10 GB 75 5.5 Departamento de vendas 2 horas
SalesDB Local InnoDB 20 GB 75 5.5 Departamento de vendas 1 hora

Cada proprietário do banco de dados foi contatado para determinar o período de inatividade aceitável. O método de planejamento e migração selecionado foi baseado no tempo de inatividade aceitável do banco de dados.

Na primeira fase, a WWI se concentrou exclusivamente no banco de dados ConferenceDB. A equipe precisava da experiência de migração para ajudar a prosseguir com as migrações de carga de trabalho de dados. O banco de dados ConferenceDB foi escolhido devido à estrutura simples de banco de dados e ao amplo tempo de inatividade aceitável. Depois que o banco de dados foi migrado, a equipe se concentrou em migrar o aplicativo para a zona de destino segura do Azure.

Lista de verificação de avaliação

  • Teste se a carga de trabalho é executada com êxito no sistema de destino.

  • Verifique se os componentes de rede corretos estão em vigor para a migração.

  • Entenda os requisitos de recursos da carga de trabalho de dados.

  • Faça uma estimativa dos custos totais.

  • Entenda os requisitos de tempo de inatividade.

  • Esteja preparado para fazer alterações no aplicativo.

Próxima etapa

Migrar o MySQL local para o Banco de Dados do Azure para MySQL: planejamento