Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A migração de dados é um aspeto fundamental da transição de bancos de dados MySQL de ambientes locais para bancos de dados do Azure para MySQL. Este artigo aprofunda as complexidades 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 sua estratégia de migração com eficiência, 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 fornece o conhecimento necessário 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. Seja com o objetivo de 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 uma etapa prudente antes de atualizar ou migrar dados, exporte o banco de dados antes da atualização usando o MySQL Workbench ou manualmente através do mysqldump comando.
Offline vs. online
Antes de selecionar uma ferramenta de migração, deve ser determinado se a migração deve ser online ou offline.
As migrações offline fazem com que o sistema fique inativo enquanto a migração ocorre. Essa opção garante que nenhuma transação esteja ocorrendo e que o estado dos dados seja exatamente o esperado quando restaurado no Azure.
As migrações online migram os dados quase 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 usando um método de replicação como
binlogou similar.
Para a Primeira Guerra Mundial, seu ambiente tem alguns requisitos complexos de rede e segurança que não permitem que as alterações apropriadas sejam aplicadas à conectividade de entrada e saída no período de migração de destino. Essas complexidades e requisitos essencialmente eliminam a abordagem on-line da consideração.
Nota
Consulte as seções Planejamento e Avaliação para obter mais detalhes sobre a migração Offline vs Online.
Desvio de dados
As estratégias de migração offline têm potencial para desvio de dados. O desvio de dados ocorre quando os dados de origem recém-modificados ficam fora de sincronia com os dados migrados. Quando isso acontece, é necessária uma exportação completa ou uma exportação delta. Você pode atenuar esse problema interrompendo todo o tráfego para o banco de dados e, em seguida, executando sua exportação. Se não for possível parar todo o tráfego de modificação de dados, você precisa levar em conta o desvio.
Determinar as alterações pode se tornar complicado 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 números estiver presente e a migração estiver importando em ordem de classificação, é relativamente simples determinar onde a importação parou e reiniciá-la a partir dessa posição. Se nenhuma chave baseada em números estiver presente, poderá ser possível utilizar modificar e criar data e, novamente, importar de maneira ordenada para que você possa reiniciar a migração a partir da última data vista no destino.
Recomendações de desempenho
Exportar
Use uma ferramenta de exportação que possa ser executada em um modo multi-threaded, como mydumper
Ao usar o MySQL 8.0, use tabelas particionadas quando apropriado para aumentar a velocidade das exportações.
Importar
Crie índices clusterizados e chaves primárias depois de carregar dados. Carregue dados em ordem de chave primária, ou outra se chave primária alguma coluna de data (como modificar data ou criar data) em ordem classificada.
Atrase a criação de índices secundários até que os dados sejam carregados. Crie todos os índices secundários após o carregamento.
Desative as restrições de chave estrangeira antes de carregar. A desativação de verificações de chaves estrangeiras proporciona ganhos de desempenho significativos. Habilite as restrições e verifique os dados após a carga para garantir a integridade referencial.
Carregue dados em paralelo. Evite muito paralelismo que poderia causar contenção de recursos e monitore recursos usando as métricas disponíveis no portal do Azure.
Executar a migração
Fazer backup do banco de dados
Criar e verificar a zona de aterrissagem do Azure
Configurar parâmetros do servidor de origem
Configurar parâmetros do servidor de destino
Exportar os objetos do banco de dados (esquema, usuários, etc.)
Exportar os dados
Importar os objetos de banco de dados
Importar os dados
Validação
Redefinir parâmetros do servidor de destino
Migrar um ou mais aplicativos
Medidas comuns
Apesar do caminho percorrido, existem passos comuns que devem ser realizados:
Atualizar para uma versão suportada do Azure MySQL
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 da Conferência Mundial está executando a versão 5.5, é necessário executar uma atualização. O CIO pediu que eles atualizassem para a versão mais recente do MySQL (atualmente 8.0).
Há duas maneiras de atualizar para a versão 8.0:
No local
Exportação/Importação
Ao decidir fazer uma atualização, é importante executar a ferramenta de verificação de atualização para determinar se há conflitos. Por exemplo, ao atualizar para o MySQL Server 8.0, a ferramenta verifica os seguintes conflitos:
Nomes de objetos de banco de dados que entram em conflito com palavras de reserva no MySQL 8.0
Uso do charset utf8mb3
Uso dos atributos de tipo de comprimento ZEROFILL/display
Nomes de tabelas que entram em conflito com tabelas na versão 8.0
Uso do tipo temporal
Nomes de restrição de chave estrangeira com mais de 64 caracteres
Se o verificador de atualização não relatar problemas, é seguro fazer uma atualização in-loco substituindo os binários do MySQL. As bases de dados com problemas têm de ser exportadas e as questões abordadas.
Cenário da Primeira Guerra Mundial
Depois de migrar com êxito a instância do MySQL para 8.0, a equipe de migração da Primeira Guerra Mundial percebeu que o caminho de migração original Migrar o MySQL local para o Banco de Dados do Azure para MySQL não poderia mais ser usado, pois a ferramenta DMS atualmente suporta apenas 5.6 e 5.7. DMS necessário acesso à rede. A equipe de migração da Primeira Guerra Mundial não estava pronta para lidar com seus complexos problemas de rede. Esses problemas ambientais restringiram a escolha da ferramenta de migração para o MySQL Workbench.
Objetos da base 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 você tenha migrado tudo.
Se você gostaria de executar um procedimento armazenado para gerar essas informações, você pode usar 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 este 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 após a conclusão da migração. Observe que não há funções no banco de dados. As funções foram eliminadas antes da migração.
Utilizadores e permissões
Uma migração bem-sucedida requer a migração de usuários associados e permissões para o ambiente de destino.
Exporte todos os usuários e suas concessões usando 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 de Instalação)
Defina seu nome de usuário para root e sua senha para a senha do usuário root
Em seguida, você pode executar o AllGrants.sql script direcionado 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"
}
Você também pode criar usuários no Banco de Dados do Azure para MySQL usando o PowerShell: /azure/mysql/howto-create-users
Executar migração
Com os componentes básicos de migração implementados, agora é possível prosseguir com a migração de dados. Foram introduzidas várias ferramentas e métodos anteriormente. Para a Primeira Guerra Mundial, 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
Compreender a complexidade do ambiente e se uma abordagem online é viável.
Contabilize o desvio de dados. Parar o serviço de banco de dados pode eliminar possíveis desvios de dados.
Configure parâmetros de origem para exportação rápida.
Configure parâmetros de destino para importação rápida.
Teste todas as migrações que tenham uma versão de origem diferente vs o destino.
Migre quaisquer objetos não baseados em dados, como nomes de usuário e privilégios.
Certifique-se de que todas as tarefas estão documentadas e com check-off à medida que a migração é executada.