Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Test Plans
O desenvolvimento de planos de teste abrangentes é fundamental na migração de bancos de dados MySQL de ambientes locais para o Banco de Dados do Azure para MySQL. Este artigo fornece uma visão detalhada dos componentes essenciais de planos de teste eficazes, garantindo que seu processo de migração seja tranquilo e bem-sucedido. Você pode atenuar os riscos delineando estratégias de teste importantes, identificando possíveis problemas, estabelecendo critérios claros de validação e garantindo que seus bancos de dados migrados sejam executados de forma ideal no ambiente do Azure. Independentemente de se concentrar em testes funcionais, testes de desempenho ou testes de segurança, este guia fornecerá o conhecimento e as práticas recomendadas para criar planos de teste robustos que dão suporte a uma migração perfeita.
Pré-requisitos
Migrar o MySQL local para o Banco de Dados do Azure para MySQL: métodos de migração
Visão geral
O WWI criou um plano de teste que inclui um conjunto de TI e tarefas corporativas. Para uma migração bem-sucedida, é necessário que todos os testes sejam executados.
Testes:
Confira se o banco de dados migrado é consistente (mesmo número de registros e resultados de consulta) com as tabelas locais.
Confira se o desempenho é aceitável (ele deve ser equivalente ao desempenho apresentado na execução local).
Confira se o desempenho das consultas de destino atende aos requisitos declarados.
Garanta uma conectividade de rede aceitável entre o ambiente local e a rede do Azure.
Verifique se todos os aplicativos e usuários identificados podem se conectar à instância de dados migrados.
O WWI estabeleceu um horário de fim de semana para a janela de migração, que começou às 22:00 e terminou às 2:00 (horário do Pacífico). No caso de a migração não ter sido concluída antes do prazo das 2:00 (tempo de inatividade de 4 horas) com todos os testes aprovados, foram iniciados os procedimentos de reversão. Os problemas foram documentados para futuras tentativas de migração. Todas as janelas de migrações foram adiadas e reagendadas com base em cronogramas corporativos aceitáveis.
Consultas de exemplo
Foi feita uma série de consultas na origem e no destino para verificar se a migração do banco de dados foi bem-sucedida. As consultas e os scripts a seguir ajudam a determinar se as ações de migração moveram todos os objetos de banco de dados necessários da origem para o destino.
Linhas de tabela
Você pode usar essa consulta para obter todas as tabelas e uma contagem de linhas estimada:
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';
Observação
A tabela INFORMATION_SCHEMA fornece um conjunto estimado de valores ao longo das tabelas. Para uma exibição mais precisa de métricas como o tamanho da tabela, aumente o tamanho da amostra da página com o parâmetro do servidor innodb_stats_transient_sample_pages. Quando se aumenta esse valor, mais páginas são analisadas, e os resultados são mais precisos.
Execute a instrução SQL count(*) em todas as tabelas para obter uma contagem precisa das linhas. Em tabelas maiores, esse comando pode levar bastante tempo para ser executado. O script a seguir gera um conjunto de instruções SQL que podem ser executadas para obter as contagens exatas:
SELECT CONCAT(
'SELECT "',
table_name,
'" AS table_name, COUNT(*) AS exact_row_count FROM `',
table_schema,
'`.`',
table_name,
'` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';
Fragmentação de tabela
Com o uso continuado do aplicativo, as tabelas de dados devem continuar aumentando em tamanho. Em alguns casos, ainda que a quantidade de dados não aumente significativamente, esses mesmos dados são alterados constantemente durante exclusões e atualizações. Nesse caso, é possível que haja várias fragmentações nos arquivos de banco de dados. A instrução OPTIMIZE TABLE do MySQL pode reduzir a necessidade de espaço de armazenamento físico e melhorar a eficiência de entrada e saída.
É possível otimizar as tabelas do MySQL executando o seguinte comando:
optimize table TABLE_NAME
Objetos de banco de dados
Use a consulta a seguir para garantir que todos os outros objetos de banco de dados sejam contabilizados. Ainda que essas consultas consigam fazer a contagem das linhas da tabelas, elas podem não levar em consideração a versão do objeto de banco de dados específico. Por exemplo, mesmo que exista um procedimento armazenado, ele pode ter sido alterado entre o início e o fim da migração. É recomendável congelar o desenvolvimento de objetos de banco de dados durante a migração.
Usuários
SELECT DISTINCT
USER
FROM
mysql.user
WHERE
user <> '' order by user
Índices
SELECT DISTINCT
INDEX_NAME
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Restrições
SELECT DISTINCT
CONSTRAINT_NAME
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
CONSTRAINT_SCHEMA = '{SchemaName}'
Exibições
SELECT
TABLE_NAME
FROM
information_schema.VIEWS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Procedimentos armazenados
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = '{SchemaName}'
Funções
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = '{SchemaName}'
Eventos
SELECT
EVENT_NAME
FROM
INFORMATION_SCHEMA.EVENTS
WHERE
EVENT_SCHEMA = '{SchemaName}'
Estratégias de reversão
As consultas acima fornecem uma lista de nomes de objetos e contagens usadas em uma decisão de reversão. Os usuários da migração podem executar a primeira etapa de verificação de objeto conferindo a contagem de objetos de origem e de destino. Uma discrepância na contagem de objetos não indica, necessariamente, que é necessária a reversão. Com uma avaliação aprofundada, é possível identificar se a diferença é pequena e facilmente recuperável. A solução pode ser migrar manualmente alguns objetos com falhas. Por exemplo, se todas as linhas de dados e tabelas forem migradas e apenas algumas das funções foram perdidas, corrija os objetos com falhas e finalize a migração. Se o banco de dados for relativamente pequeno, é possível limpar a instância do Banco de Dados do Azure para MySQL e reiniciar a migração. Bancos de dados maiores podem precisar de mais tempo para conferir objetos ausentes do que o disponível na janela de migração. A migração precisa então ser interrompida e revertida.
A identificação de objetos de banco de dados ausentes precisa ocorrer rapidamente durante uma janela de migração. Cada minuto importa. Uma opção pode ser exportar os nomes de objeto de ambiente para um arquivo e usar uma ferramenta de comparação de dados para identificar rapidamente objetos ausentes. Outra opção é exportar os nomes do objeto de banco de dados de origem e importá-los para uma tabela temporária do ambiente do banco de dados de destino. Compare os dados usando uma instrução SQL com script e testada. A velocidade e a precisão na verificação dos dados são fundamentais no processo de migração. Não confie na leitura e verificação manual de uma longa lista de objetos de banco de dados durante uma janela de migração. A possibilidade de erro humano é muito grande. É mais adequado gerenciar por exceção usando ferramentas.
Cenário do WWI
O CIO da WWI recebeu um relatório de confirmação de que todos os objetos de banco de dados foram migrados do banco de dados local para a instância do Banco de Dados do Azure para MySQL. A equipe do banco de dados executou as consultas acima no banco de dados antes do início da migração e salvou todos os resultados em uma planilha.
As informações do esquema do banco de dados de origem foram usadas para confirmar a fidelidade do objeto de migração de destino.
Lista de verificação de planos de teste
Deixe as consultas de teste com script, testadas e prontas para execução.
Verifique o tempo de execução das consultas de teste e inclua-o na linha do tempo de migração documentada.
Tenha uma estratégia de mitigação de risco e de reversão pronta para diferentes resultados potenciais.
Tenha uma linha do tempo definida para os eventos da migração.