Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Migração de dados
A migração de dados é um aspecto fundamental da transição de bancos de dados MySQL de ambientes locais para bancos de dados do Azure para MySQL. Este artigo aborda os meandros da migração de dados, oferecendo um guia abrangente sobre as várias técnicas e práticas recomendadas para garantir uma transferência de dados perfeita. Você pode planejar e executar efetivamente sua estratégia de migração compreendendo os diferentes métodos de migração de dados, como migração lógica e física, e abordando possíveis desafios, como integridade de dados e tempo de inatividade. Este guia o equipa com o conhecimento para lidar com grandes conjuntos de dados, minimizar interrupções e usar os recursos robustos do Azure para otimizar o desempenho e a confiabilidade do banco de dados. Se você pretende modernizar sua infraestrutura ou aprimorar seus recursos de gerenciamento de dados, este artigo fornecerá os insights necessários para uma migração de dados bem-sucedida.
Pré-requisitos
Migrar o MySQL local para o Banco de Dados do Azure para MySQL – Linhas de base de desempenho
Fazer backup do banco de dados
Como etapa recomendada antes de atualizar ou migrar dados, exporte o banco de dados usando o MySQL Workbench ou manualmente por meio do comando mysqldump.
Offline vs. online
Antes da seleção de uma ferramenta de migração, deve-se determinar se a migração será online ou offline.
As migrações offline farão com que o sistema fique inoperante durante o processo. Essa opção garante que nenhuma transação esteja ocorrendo e que o estado dos dados será exatamente o esperado após a restauração no Azure.
As migrações online migrarão os dados praticamente em tempo real. Essa opção é apropriada quando há pouco tempo de inatividade para os usuários ou aplicativos que consomem a carga de trabalho de dados. O processo envolve a replicação dos dados com um método de replicação como
binlogou semelhante.
No caso do WWI, o ambiente tem alguns requisitos complexos de rede e segurança que não permitem que as alterações apropriadas sejam aplicadas para a conectividade de entrada e de saída no período da migração de destino. Essencialmente, essas complexidades e requisitos eliminam a abordagem online da escolha.
Observação
Revise as seções Planejamento e Avaliação para obter mais detalhes sobre a comparação entre a migração offline e a online.
Descompasso de dados
As estratégias de migração offline podem causar descompasso de dados. Ele ocorre quando dados de origem modificados recentemente ficam fora de sincronia com os dados migrados. Quando isso acontece, uma exportação completa ou uma exportação delta são necessárias. É possível atenuar esse problema interrompendo todo o tráfego para o banco de dados e executando a exportação em seguida. Se a interrupção de todo o tráfego de modificação de dados não for possível, será necessário considerar o descompasso.
A determinação das alterações pode se tornar complicada se as tabelas do banco de dados não tiverem colunas como chaves primárias baseadas em números ou algum tipo de data de modificação e criação em cada tabela que precisa ser migrada.
Por exemplo, se uma chave primária baseada em numérico estiver presente e a migração estiver sendo importada na ordem de classificação, será relativamente simples determinar onde a importação parou e reiniciá-la a partir desse ponto. Se nenhuma chave baseada em numérico estiver presente, será possível utilizar a data de modificação e criação e, novamente, realizar a importação de maneira classificada para poder reiniciar a migração a partir da última data vista no destino.
Recomendações do desempenho
Export
Usar uma ferramenta de exportação que possa ser executada em um modo multiencadeado, como mydumper
Com o MySQL 8.0, quando apropriado, use tabelas particionadas para aumentar a velocidade das exportações.
Importar
Crie chaves primárias e índices clusterizados antes de carregar os dados. Carregue os dados na ordem da chave primária ou em outra ordem caso a chave primária seja alguma coluna de data (como data de modificação ou de criação) na ordem classificada.
Atrase a criação de índices secundários até os dados serem carregados. Crie todos os índices secundários após o carregamento.
Desabilite as restrições de chave estrangeira antes do carregamento. Desabilitar as verificações de chave estrangeira proporciona ganhos significativos de desempenho. Habilite as restrições e verifique os dados após o carregamento para garantir a integridade referencial.
Carregar dados em paralelo. Evite paralelismo em excesso que possa causar contenção de recursos e monitore os recursos usando as métricas disponíveis no portal do Azure.
Realizar a migração
Fazer backup do banco de dados
Criar e verificar a zona de destino do Azure
Configurar parâmetros do servidor de origem
Configurar parâmetros do servidor de destino
Exportar os objetos de banco de dados (esquema, usuários etc.)
Exportar os dados
Importar os objetos de banco de dados
Importar os dados
Validação
Configurar parâmetros do servidor de destino
Migrar um ou mais aplicativos
Etapas comuns
Independentemente do caminho percorrido, há etapas comuns que devem ser realizadas:
Atualizar para uma versão do MySQL do Azure com suporte
Objetos de banco de dados de inventário
Exportar usuários e permissões
Migrar para a versão mais recente do MySQL
Como o banco de dados WWI Conference executa a 5.5, é necessário fazer uma atualização. O CIO solicitou a atualização para a versão mais recente do MySQL (atualmente 8.0).
A atualização pode ser feita de duas maneiras:
No local
Exportar/importar
Ao decidir fazer uma atualização, é importante executar a ferramenta Verificador de atualização para determinar se há conflitos. Por exemplo, ao atualizar para o MySQL Server 8.0, a ferramenta verificará os seguintes conflitos:
Nomes de objetos de banco de dados que estão em conflito com palavras de reserva no MySQL 8.0
Uso do conjunto de caracteres utf8mb3
Uso dos atributos de tipo de comprimento de exibição/ZEROFILL
Nomes de tabela que estão em conflito com tabelas na versão 8.0
Uso de tipo temporal
Nomes de restrição de chave estrangeira com mais de 64 caracteres
Caso o verificador de atualização não relate problemas, é seguro fazer uma atualização local substituindo os binários do MySQL. Os bancos de dados com problemas precisam ser exportados e os problemas resolvidos.
Cenário da WWI
Depois de migrar com sucesso a instância do MySQL para a 8.0, a equipe de migração do WWI percebeu que o caminho de migração original da Migração do MySQL local para o Banco de Dados do Azure para MySQL não poderia mais ser usado, pois atualmente a ferramenta DMS é compatível somente com as versões 5.6 e 5.7. O DMS solicitou acesso à rede. A equipe de migração do WWI não estava pronta para lidar com seus problemas de rede complexos. Esses problemas ambientais restringiram a escolha da ferramenta de migração para o MySQL Workbench.
Objetos de banco de dados
Conforme descrito na seção Planos de teste, um inventário de objetos de banco de dados deve ser feito antes e depois da migração para garantir que tudo foi migrado.
Para executar um procedimento armazenado a fim de gerar essas informações, use algo semelhante ao seguinte:
DELIMITER //
CREATE PROCEDURE `Migration_PerformInventory`(IN schemaName CHAR(64))
BEGIN
DECLARE finished INTEGER DEFAULT 0;
DECLARE tableName varchar(100) DEFAULT "";
#get all tables
DECLARE curTableNames
CURSOR FOR
SELECT TABLE_NAME FROM information_schema.tables where TABL
E_SCHEMA = schemaName;
-- declare NOT FOUND handler
DECLARE CONTINUE HANDLER
FOR NOT FOUND SET finished = 1;
DROP TABLE IF EXISTS MIG_INVENTORY;
CREATE TABLE MIG_INVENTORY
(
REPORT_TYPE VARCHAR(1000),
OBJECT_NAME VARCHAR(1000),
PARENT_OBJECT_NAME VARCHAR (1000),
OBJECT_TYPE VARCHAR(1000),
COUNT INT
)
ROW_FORMAT=DYNAMIC,
ENGINE='InnoDB';
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'TABLES', 'TABLES', COUNT(*)
FROM
information_schema.tables
where
TABLE_SCHEMA = schemaName;
#### Constraints
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'STATISTICS', 'STATISTICS', COUNT(*)
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'VIEWS', 'VIEWS', COUNT(*)
FROM
information_schema.VIEWS
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'PROCEDURES', 'PROCEDURES', COUNT(*)
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'EVENTS', 'EVENTS', COUNT(*)
FROM
information_schema.EVENTS
WHERE
EVENT_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USER DEFINED FUNCTIONS', 'USER DEFINED FUNCTIONS'
, COUNT(*)
FROM
mysql.func;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USERS', 'USERS', COUNT(*)
FROM
mysql.user
WHERE
user <> '' order by user;
OPEN curTableNames;
getTableName: LOOP
FETCH curTableNames INTO tableName;
IF finished = 1 THEN
LEAVE getTableName;
END IF;
SET @s = CONCAT('SELECT COUNT(*) into @TableCount FROM ', schemaName,
'.', tableName);
#SELECT @s;
PREPARE stmt FROM @s;
EXECUTE stmt;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'TABLECOUNT', tableName, 'TABLECOUNT', @TableCount;
DEALLOCATE PREPARE stmt;
END LOOP getTableName;
CLOSE curTableNames;
SELECT * FROM MIG_INVENTORY;
END //
DELIMITER ;
CALL Migration_PerformInventory('reg_app');
- Chamar esse procedimento no banco de dados de origem revela o seguinte (saída truncada):
- O resultado do procedimento do banco de dados de destino deve ser semelhante à imagem abaixo depois da migração. Observe que não há funções no banco de dados. As funções foram eliminadas antes da migração.
Usuários e permissões
Uma migração bem-sucedida requer a migração de permissões e usuários associados para o ambiente de destino.
Exporte todos os usuários e suas concessões com o seguinte script do PowerShell:
$username = "yourusername";
$password = "yourpassword";
mysql -u$username -p$password --skip-column-names -A -e"SELECT CONCAT('SHOW G
RANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" > Show
Grants.sql;
$lines = get-content "ShowGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password --skip-column-names -A -e"$line" >> AllGrants.sql
}
Criar um novo script do PowerShell usando o ISE do PowerShell (consulte o documento Instalação)
Defina seu nome de usuário como raiz e sua senha como a senha do usuário raiz
Em seguida, execute o script AllGrants.sql destinado ao novo Banco de Dados do Azure para MySQL:
$username = "yourusername";
$password = "yourpassword";
$server = "serverDNSname";
$lines = get-content "AllGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password -h$server --ssl-ca=c:\temp\BaltimoreCyberTrus
tRoot.crt.cer --skip-column-names -A -e"$line"
}
Também é possível criar usuários no Banco de Dados do Azure para MySQL usando o PowerShell: /en-us/azure/mysql/howto-create-users
Executar uma migração
Com os componentes básicos de migração em vigor, agora é possível continuar com a migração de dados. Diversas ferramentas e métodos foram introduzidos anteriormente. Para o WWI, eles utilizarão o caminho do MySQL Workbench para exportar os dados e, em seguida, importá-los para o Banco de Dados do Azure para MySQL.
Lista de verificação de migração de dados
Entenda a complexidade do ambiente e se uma abordagem online é viável.
Considere o descompasso de dados. Parar o serviço de banco de dados pode eliminar possíveis descompassos de dados.
Configure os parâmetros de origem para obter uma exportação rápida.
Configure os parâmetros de destino para obter uma importação rápida.
Teste todas as migrações com uma versão de origem diferente da de destino.
Migre qualquer objeto não baseado em dados, como privilégios e nomes de usuário.
Verifique se todas as tarefas estão documentadas e desmarcadas enquanto a migração é executada.