Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Planos de teste

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 aprofundada dos componentes essenciais de planos de teste eficazes, garantindo que seu processo de migração seja suave e bem-sucedido. Você pode reduzir os riscos descrevendo as principais estratégias de teste, identificando possíveis problemas, estabelecendo critérios de validação claros e garantindo que seus bancos de dados migrados tenham um desempenho ideal no ambiente do Azure. Seja focando em testes funcionais, testes de desempenho ou testes de segurança, este guia fornece o conhecimento e as práticas recomendadas necessárias para criar planos de teste robustos que oferecem 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

Descrição geral

A Primeira Guerra Mundial criou um plano de teste que incluía um conjunto de tarefas de TI e de Negócios. Migrações bem-sucedidas exigem que todos os testes sejam executados.

Testes:

• Verifique se o banco de dados migrado tem consistência (mesmas contagens de registros e resultados de consulta) com tabelas locais.

• Certifique-se de que o desempenho é aceitável (deve corresponder ao mesmo desempenho como se estivesse a ser executado no local).

• Garantir que o desempenho das consultas de destino atenda aos requisitos declarados.

• Garanta uma conectividade de rede aceitável entre o local e a rede do Azure.

• Certifique-se de que todos os aplicativos e usuários identificados possam se conectar à instância de dados migrada.

A Primeira Guerra Mundial identificou um fim de semana de migração e uma janela de tempo que começou às 22h e terminou às 2h (horário do Pacífico). Se a migração não foi concluída antes do destino das 2h (o objetivo de tempo de inatividade de 4 horas) com todos os testes aprovados, os procedimentos de reversão foram iniciados. Problemas foram documentados para futuras tentativas de migração. Todas as janelas de migração foram adiantadas e reagendadas com base em cronogramas comerciais aceitáveis.

Consultas de amostra

Uma série de consultas foi executada na origem e no destino para verificar o sucesso da migração do banco de dados. As consultas e 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 da 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}';

Execute a count(*) instrução SQL em cada tabela para obter uma contagem precisa de linhas. A execução deste comando pode levar uma grande quantidade de tempo em tabelas grandes. 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 da tabela

É provável que as tabelas de dados continuem a crescer com o uso contínuo do aplicativo. Em alguns casos, os dados podem não crescer, mas mudam constantemente através de exclusões e atualizações. Se assim for, é possível que haja uma fragmentação numerosa nos arquivos de banco de dados. A instrução MySQL OTIMIZE TABLE pode reduzir as necessidades de espaço de armazenamento físico e melhorar a eficiência de E/S.

Você pode otimizar as tabelas do MySQL executando o seguinte:

optimize table TABLE_NAME

Objetos da base de dados

Use a consulta a seguir para garantir que todos os outros objetos de banco de dados sejam contabilizados. Embora essas consultas possam calcular as contagens de linhas da tabela, elas podem não levar em conta a versão do objeto de banco de dados específico. Por exemplo, mesmo que um procedimento armazenado possa existir, ele pode ter sido alterado entre o início e o fim da migração. Recomenda-se congelar o desenvolvimento de objetos de banco de dados durante a migração.

Utilizadores

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}'

Vistas

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 e contagens de objetos usados em uma decisão de reversão. Os usuários de migração podem executar a primeira etapa de verificação de objetos verificando as contagens de objetos de origem e de destino. Uma discrepância nas contagens de objetos pode não significar necessariamente que uma reversão é necessária. A realização de uma avaliação aprofundada poderia apontar que a diferença é pequena e facilmente recuperável. A migração manual de alguns objetos com falha pode ser a solução. Por exemplo, se todas as tabelas e linhas de dados foram migradas, apenas algumas das funções foram perdidas, corrija esses objetos com falha e finalize a migração. Se o banco de dados for relativamente pequeno, poderá ser possível limpar a instância do Banco de Dados do Azure para MySQL e reiniciar a migração. Bancos de dados grandes podem precisar de mais tempo do que o disponível na janela de migração para determinar objetos ausentes. A migração precisa parar e retroceder.

A identificação de objetos de banco de dados ausentes precisa ocorrer rapidamente durante uma janela de migração. Cada minuto conta. Uma opção pode ser exportar os nomes de objetos de ambiente para um arquivo e usar uma ferramenta de comparação de dados para identificar objetos ausentes rapidamente. Outra opção poderia ser exportar os nomes de objeto do banco de dados de origem e importar os dados para uma tabela temporária do ambiente de banco de dados de destino. Compare os dados usando uma instrução SQL testada e com script. A velocidade e a precisão da verificação de dados são fundamentais para o processo de migração. Não confie na leitura e verificação manuais de uma longa lista de objetos de banco de dados durante uma janela de migração. A possibilidade de erro humano é muito grande. Seria melhor se você gerenciasse por exceção usando ferramentas.

Cenário da Primeira Guerra Mundial

O CIO da Primeira Guerra Mundial recebeu um relatório de confirmação de que todos os objetos de banco de dados foram migrados do banco de dados local para o Banco de Dados do Azure para a instância 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 verificar a fidelidade do objeto de migração de destino.

Lista de verificação dos planos de teste

• Tenha consultas de teste roteirizadas, testadas e prontas para serem executadas.

• Saiba quanto tempo as consultas de teste levam para serem executadas e torne-as parte do cronograma de migração documentado.

• Tenha uma estratégia de mitigação e reversão pronta para diferentes resultados potenciais.

• Tenha um cronograma de eventos bem definido para a migração.

Próximo passo