Partilhar 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 é um primeiro passo crítico 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. Pode tomar decisões informadas que se alinham com os objetivos da sua organização avaliando a sua infraestrutura atual, identificando potenciais desafios e compreendendo os benefícios dos serviços de base de dados geridos do Azure. Quer pretenda melhorar o desempenho, melhorar a escalabilidade ou reduzir os custos operacionais, este guia fornece-lhe as informações necessárias para planear e executar eficazmente a 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

Descrição geral

Antes de começar a migrar uma carga de trabalho do MySQL, há uma boa quantidade de diligência que deve ser realizada. Isso inclui analisar os dados, o ambiente de hospedagem e as cargas de trabalho do aplicativo para validar que a zona de aterrissagem do Azure está configurada corretamente e preparada para hospedar as cargas de trabalho migradas em breve.

Limitações

O Banco de Dados do Azure para MySQL é uma versão totalmente suportada da edição da comunidade MySQL em execução como uma plataforma como um serviço. No entanto, existem algumas limitações com as quais se familiarizar ao fazer uma avaliação inicial.

Os mais importantes dos quais incluem:

  • Suporte do mecanismo de armazenamento para InnoDB e Memory somente

  • Suporte limitado Privilege (DBA, SUPER, DEFINER)

  • Instruções de manipulação de dados desativadas (SELECT ... INTO OUTFILE, LOAD DATA INFILE)

  • Migração automática significativa de banco de dados (5,6 a 5,7, 5,7 a 8,0)

  • Ao usar UDFs (User-Defined Functions) do MySQL Server, a única opção de hospedagem viável é as VMs hospedadas do Azure, pois não há capacidade de carregar o so componente ou dll no Banco de Dados do Azure para MySQL.

Muitos dos outros itens são aspetos 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 explora muitos desses aspetos operacionais na seção Gerenciamento pós-migração.

Versões do MySQL

O MySQL tem uma história rica que começa em 1995. Desde então, evoluiu para um sistema de gerenciamento de banco de dados amplamente utilizado. O Banco de Dados do Azure para MySQL começou com o suporte do MySQL versão 5.6 e continuou para 5.7 e recentemente 8.0. Para obter as versões mais recentes sobre o Banco de Dados do Azure para MySQL, consulte Banco de Dados do Azure com suporte para versões do servidor MySQL. Na seção Gerenciamento Pós-Migração, analisamos como as atualizações (como 5.7.20 a 5.7.21) são aplicadas às instâncias do MySQL no Azure.

Nota

O salto de 5.x para 8.0 deveu-se em grande parte à aquisição do MySQL pela Oracle. Para ler mais sobre o histórico do MySQL, navegue até a página wiki do MySQL.

Conhecer a versão fonte do MySQL é essencial. Os aplicativos que usam o sistema podem estar usando objetos de banco de dados e recursos específicos para essa versão. Migrar um banco de dados para uma versão inferior pode causar problemas de compatibilidade e perda de funcionalidade. Também é recomendado que os dados e a instância do aplicativo sejam exaustivamente testados antes de migrar para uma versão mais recente, pois os recursos introduzidos podem quebrar seu aplicativo.

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

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

  • 5.7: Suporte para tipo de dados JSON nativo

  • 8.0: Suporte para NoSQL Document Store, atômico e funções de tabela DDL e JSON à prova de falhas

    Nota

    MySQL 5.6 perde suporte geral em fevereiro de 2021. As cargas de trabalho do MySQL precisam migrar para a versão 5.7 ou superior do MySQL.

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 dá suporte apenas aos mecanismos de armazenamento de banco de dados InnoDB e Memory . Outros mecanismos de armazenamento, como o MyISAM, precisam ser migrados para um mecanismo de armazenamento compatível. As diferenças entre MyISAM e 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 mudam entre os mecanismos, mas os tipos de coluna de índice e tabela podem mudar por motivos de armazenamento e desempenho. Embora o InnoDB seja conhecido por ter grandes tamanhos de arquivo de dados, esses detalhes de armazenamento são gerenciados pelo serviço Banco de Dados do Azure para MySQL.

Migrar do MyISAM para o InnoDB

O banco de dados e as tabelas MyISAM precisam ser convertidos em tabelas InnoDB. Após a conversão, os aplicativos devem ser testados quanto à compatibilidade e ao desempenho. Na maioria dos casos, o teste requer 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 executada durante a migração, pois ocorre durante a criação do esquema no destino do Azure. Para obter mais detalhes, consulte a documentação dos desenvolvedores de tabelas de conversão no site do MySQL.

Para encontrar informações úteis sobre a 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';

Nota

A execução de consultas em relação a INFORMATION_SCHEMA em vários bancos de dados pode afetar o desempenho. Executar durante períodos de baixa utilização.

Para converter uma tabela de MyISAM para InnoDB, execute o seguinte:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Nota

Essa abordagem de conversão faz com que a tabela seja bloqueada e todos os aplicativos podem esperar até que a operação seja concluída. O bloqueio de tabela faz com que o banco de dados apareça offline por um curto período.

Em vez disso, a tabela pode ser criada com a mesma estrutura, mas com um mecanismo de armazenamento diferente. Uma vez criadas, copie as linhas para a nova tabela:

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

Nota

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

Dados e objetos do banco de dados

Os dados são um componente da migração de banco de dados. Os objetos de suporte do banco de dados devem ser migrados e validados para garantir que os aplicativos continuem a ser executados de forma confiável.

Aqui está 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

  • Acionadores

  • Vistas

Funções definidas pelo usuário

MySQL permite o uso de funções que chamam código externo. Infelizmente, as cargas de trabalho de dados que usam UDFs (User-Defined Functions) com 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 ou o código dll não podem ser carregados no servidor do Azure.

Execute a seguinte consulta para localizar quaisquer UDFs que possam estar instalados:

SELECT * FROM mysql.func;

Sistemas de origem

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

Além disso, mover dados pela Internet pode ser mais lento do que usar circuitos dedicados para o Azure. Portanto, ao mover muitos gigabytes, terabytes e petabytes de dados, considere configurar uma conexão de Rota Expressa entre a rede de origem e a rede do Azure.

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

Por fim, o espaço em disco deve ser avaliado. Ao exportar um banco de dados grande, considere o tamanho dos dados. Verifique se o sistema onde a ferramenta está sendo executada e, finalmente, o local de exportação tem espaço em disco suficiente para executar a operação de exportação.

Fornecedores de serviços na nuvem

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

No local

Como os provedores de nuvem, se a carga de trabalho de dados do MySQL estiver atrás de firewalls ou 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

Muitas ferramentas e métodos podem ser usados para avaliar as cargas de trabalho e ambientes de dados do MySQL. Cada ferramenta fornece um conjunto diferente de recursos e funcionalidades de avaliação e migração. Como parte deste guia, revisamos as ferramentas mais usadas para avaliar cargas de trabalho de dados MySQL.

Azure migra

Embora o Azure Migrate não ofereça suporte à migração direta de cargas de trabalho de banco de dados MySQL, ele pode ser usado quando os administradores não têm certeza de quais usuários e aplicativos estão consumindo os dados, hospedados em uma máquina virtual ou baseada em hardware. A análise de dependência pode ser realizada instalando e executando o agente de monitoramento na máquina que hospeda a carga de trabalho do MySQL. O agente reúne as informações durante um determinado período, como um mês. Os dados de dependência podem ser analisados para encontrar conexões desconhecidas sendo feitas com o banco de dados. Os dados de 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, o Azure Migrate também pode ser usado para analisar o Hyper-V, VMware ou servidores físicos para fornecer padrões de utilização das cargas de trabalho de banco de dados para ajudar a sugerir o ambiente de destino adequado.

Telgraf para Linux

As cargas de trabalho do Linux podem utilizar o Microsoft Monitoring Agent (MMA) para coletar dados em suas máquinas virtuais e físicas. Além disso, considere usar o agente Telegraf e sua ampla gama de plugins para reunir suas métricas de desempenho.

Escalões de serviço

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

Existem atualmente três níveis:

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

  • Objetivo geral: a maioria das cargas de trabalho de negócios requer computação e memória equilibradas com taxa de transferência de E/S escalável.

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

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 requer mais de 4 TB de armazenamento, uma etapa extra é necessária. Analise e selecione uma região que suporte até 16 TB de armazenamento.

Normalmente, a tomada de decisão se concentra nas necessidades de armazenamento e IOPS, ou operações de entrada/saída por segundo. Assim, o sistema de destino sempre precisa de pelo menos tanto armazenamento quanto no sistema de origem. Além disso, como as IOPS são alocadas 3/GB, é importante fazer corresponder as necessidades de IOPs ao tamanho final do armazenamento.

Fatores Escalão de serviço
Básica Máquina de desenvolvimento, sem necessidade de alto desempenho com menos de 1 TB de armazenamento.
Fins Gerais Precisa de IOPS mais do que a camada básica pode fornecer, mas para armazenamento inferior a 16 TB e menos de 4 GB de memória.
Memória otimizada Cargas de trabalho de dados que utilizam alta memória ou cache alto e configuração de servidor relacionada ao buffer, como innodb_buffer_pool_instances de simultaneidade alta, grandes tamanhos de BLOB, sistemas com muitas cópias de replicação.

Custos

Depois de avaliar todas as cargas de trabalho de dados do WWI MySQL, a WWI determinou que eles precisariam de pelo menos 4 vCores e 20 GB de memória e pelo menos 100 GB de espaço de armazenamento com uma capacidade de IOP de 450 IOPS. Devido ao requisito de 450 IOPS, eles precisam 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, eles exigem pelo menos até 100% do armazenamento do servidor provisionado como armazenamento de backup e uma réplica de leitura. Eles não preveem uma saída de mais de 5 GB.

Usando a calculadora de preços do Banco de Dados do Azure para MySQL, a WWI conseguiu determinar os custos para o Banco de Dados do Azure para a instância do MySQL. A partir de 9/2020, os custos totais de propriedade (TCO) são exibidos na tabela a seguir para o Banco de Dados de Conferência da Primeira Guerra Mundial.

Recurso Description Quantidade Custo
Computação (Uso Geral) 4 vCores, 20 GB 1 @ $0.351/hr $3074.76 / ano
Armazenamento 5 GB 12 x 150 @ 0,115 $ $207 / ano
Cópia de segurança Até 100% do armazenamento provisionado Sem custo adicional de até 100% do armazenamento provisionado do servidor $0.00 / ano
Ler réplica Réplica de região de 1 segundo computação + armazenamento $3281.76 / ano
Rede < Saída de 5GB/mês Gratuito
Total $6563.52 / ano

Depois de analisar os custos iniciais, o CIO da WWI confirmou que eles estão no Azure por um período muito superior a três anos. Eles decidiram usar instâncias de reserva de 3 anos para economizar um extra de ~$4K/ano.

Recurso Description Quantidade Custo
Computação (Uso Geral) 4 vCores 1 @ $0.1375/hr $1204.5 / ano
Armazenamento 5 GB 12 x 150 @ 0,115 $ $207 / ano
Cópia de segurança Até 100% do armazenamento provisionado Sem custo adicional de até 100% do armazenamento provisionado do servidor $0.00 / ano
Rede < Saída de 5GB/mês Gratuito
Ler réplica Réplica de região de 1 segundo computação + armazenamento $1411.5 / ano
Total US$ 2.823 / ano

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

Nota

As estimativas acima não incluem custos de Rota Expressa, Gateway de Aplicativo do Azure, Balanceador de Carga do Azure ou Serviço de Aplicativo para as camadas de aplicativo.

O preço acima pode mudar a qualquer momento e varia de acordo com a região.

Implicações da aplicação

Ao mudar para o Banco de Dados do Azure para MySQL, a conversão para comunicação baseada em SSL (Secure Sockets Layer) 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 conectar ao MySQL usando SSL. Quando habilitado, o uso do SSL adiciona alguma sobrecarga de processamento extra e deve ser monitorado.

Nota

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

Siga as atividades em Configurar conectividade SSL em seu aplicativo para se conectar com segurança ao Banco de Dados do Azure para MySQL para reconfigurar o aplicativo para 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 apontar para o novo Banco de Dados do Azure para o servidor MySQL.

Cenário da Primeira Guerra Mundial

A Primeira Guerra Mundial iniciou a avaliação coletando informações sobre sua propriedade de dados MySQL, conforme mostrado na tabela a seguir.

Nome Origem Motor Db Tamanho IOPS Versão Proprietário 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 No local InnoDB 5 GB 50 5,5 Departamento de Vendas 4 horas
Banco de Dados de Clientes No local InnoDB 10 GB 75 5,5 Departamento de Vendas 2 horas
SalesDB No 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.

Para a primeira fase, a Primeira Guerra Mundial concentrou-se apenas no banco de dados ConferenceDB. A equipe precisava da experiência de migração para ajudar nas migrações de carga de trabalho de dados em andamento. O banco de dados ConferenceDB foi selecionado devido à estrutura simples do banco de dados e ao grande 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 aterrissagem segura do Azure.

Lista de verificação de avaliação

  • Teste 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.

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

  • Estimar os custos totais.

  • Entenda os requisitos de tempo de inatividade.

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

Próximo passo

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