Migração de dados do MySQL para o Banco de Dados do Azure para MySQL – Instantâneo Consistente do MySQL
O Instantâneo Consistente do MySQL é um novo recurso que permite aos usuários fazer um Instantâneo Consistente de um servidor MySQL sem perder a integridade dos dados na origem devido a operações contínuas de CRUD (Criar, ler, atualizar e excluir). A consistência transacional é obtida sem a necessidade de definir o servidor de origem para o modo somente leitura por meio desse recurso. Além disso, há várias opções de consistência de dados apresentadas ao usuário: habilite o instantâneo consistente com o bloqueio de leitura (GA), habilite um instantâneo consistente sem bloqueios (versão prévia), Faça somente Leitura do Servidor de Origem e Nenhum. A seleção da opção 'None' não implica medidas adicionais para garantir a consistência dos dados. Ambas as opções habilita um instantâneo consistente com bloqueio de leitura (GA), habilita um instantâneo consistente sem suporte a bloqueios para executar uma migração online. É altamente recomendável selecionar a opção "Habilitar Instantâneo Consistente sem bloqueios" para manter a consistência transacional.
Habilitar instantâneo consistente sem bloqueios (versão prévia)
Quando você habilita essa opção, uma fase de reconciliação ocorrerá após a carga inicial. Isso é para garantir que os dados gravados em seu destino sejam transacionalmente consistentes com o servidor de origem de uma posição específica no log binário.
Com esse recurso, não fazemos um bloqueio de leitura no servidor. Em vez disso, lemos tabelas em um ponto diferente no tempo, mantendo o controle das diferentes posições de binlog de cada tabela. Isso ajuda a reconciliar as tabelas no final da carga inicial executando a replicação no modo catchup para obter uma captura de tela consistente.
Principais recursos do Instantâneo Consistente sem bloqueios:
- Capacidade de dar suporte a servidores de carga pesada ou servidores com transações de longa duração sem a necessidade de bloqueios de leitura.
- Resiliente na conclusão de migrações mesmo no caso de falhas causadas por blips transitórios de rede/servidor que resultam na perda de todas as conexões pré-criadas.
Habilitar instantâneo consistente com GA (bloqueio de leitura)
Quando você habilita essa opção, o serviço libera todas as tabelas no servidor de origem com um bloqueio de leitura para obter o instantâneo pontual. Essa liberação é feita porque um bloqueio global é mais confiável do que tentar bloquear bancos de dados ou tabelas individuais. Como resultado, mesmo que você não esteja migrando todos os bancos de dados em um servidor, eles serão bloqueados como parte da configuração do processo de migração. O serviço de migração inicia uma leitura repetível e combina o estado da tabela atual com o conteúdo do log de cancelamento do instantâneo. O instantâneo é gerado depois de obter o bloqueio amplo do servidor por alguns segundos e gerar várias conexões para a migração. Após a criação de todas as conexões que serão usadas para a migração, os bloqueios na tabela são liberados.
As leituras repetíveis são habilitadas para manter os logs de cancelamento acessíveis durante a migração, o que aumenta o armazenamento necessário na origem devido a conexões de execução prolongada. Uma migração de execução prolongada com várias alterações de tabela leva a um extenso histórico de logs de desfazer que precisa ser reproduzido e também pode aumentar os requisitos de computação e carregar no servidor de origem.
Tornar o servidor de origem somente leitura
Selecionar essa opção mantém a integridade de dados do banco de dados de destino à medida que a origem é migrada impedindo operações de Gravação/Exclusão no servidor de origem durante a migração. Quando você fizer o servidor de origem ser lido apenas como parte do processo de migração, a seleção se aplicará a todos os bancos de dados do servidor de origem, independentemente de eles estarem selecionados para migração.
Ao tornar o servidor de origem somente leitura, impede-se que os usuários modifiquem os dados, renderizando o banco de dados indisponível para quaisquer operações de atualização. No entanto, se essa opção não estiver habilitada, haverá a possibilidade de que as atualizações de dados ocorram durante a migração. Como resultado, os dados migrados podem ficar inconsistentes porque os instantâneos do banco de dados seriam lidos em diferentes pontos no tempo.
Pré-requisitos para habilitar instantâneo consistente com bloqueio de leitura
Para concluir a migração com êxito com o Instantâneo Consistente com o bloqueio de leitura habilitado:
Verifique se o usuário que está tentando liberar tabelas com leitura bloqueada tem a permissão RECARREGAR ou LIBERAR.
Use a ferramenta de cliente mysql para determinar se o log_bin está habilitado no servidor de origem. O log Bin nem sempre é ativado por padrão e deve ser verificado para ver se está habilitado, antes de iniciar a migração. A ferramenta de cliente mysql é usada para determinar se log_bin está habilitado na origem por meio da execução do comando: SHOW VARIABLES LIKE 'log_bin';
Observação
Com o Servidor Único do Banco de Dados do Azure para MySQL que dá suporte a até 4 TB, ele não é habilitado por padrão. No entanto, se você promover uma réplica de leitura para o servidor de origem e excluir a réplica de leitura, o parâmetro será definido como ON.
- Configure o parâmetro binlog_expire_logs_seconds no servidor de origem para garantir que os arquivos do binlog não sejam limpos antes de a réplica confirmar as alterações. Após a substituição bem-sucedida, o valor poderá ser redefinido.
Problemas conhecidos e limitações para habilitar instantâneo consistente sem bloqueios
- Não há suporte para tabelas com chaves estrangeiras com a cláusula Cascade ou Set Null on delete/on update.
- Nenhuma alteração de DDL deve ocorrer durante a carga inicial.
Problemas conhecidos e limitações para habilitar instantâneo consistente com bloqueio de leitura
Os problemas e limitações conhecidos associados ao Backup consistente se enquadram amplamente em duas categorias: bloqueios e repetições.
Observação
O serviço de migração executa a consulta START TRANSACTION WITH CONSISTENT SNAPSHOT para todos os threads de trabalho para obter o instantâneo do servidor. Mas isso só é suportado pelo InnoDB. Mais informações aqui.
Bloqueios
Normalmente, fazer um bloqueio é um processo simples, devendo levar entre alguns segundos e alguns minutos para ser concluído. Em alguns cenários, porém, as tentativas de se fazer um bloqueio no servidor de origem podem falhar.
A presença de consultas de execução prolongada pode resultar em tempo de inatividade desnecessário, pois o DMS pode bloquear um subconjunto das tabelas e, em seguida, ultrapassar o tempo limite ao esperar que as últimas fiquem disponíveis. Antes de iniciar a migração, verifique se há operações de execução prolongada executando o comando SHOW PROCESSLIST.
Se o servidor de origem estiver enfrentando muitas atualizações de gravação no momento em que um bloqueio for solicitado, não será possível fazer o bloqueio prontamente e ele poderá falhar após o tempo limite de espera de bloqueio. Isso acontece no caso de haver tarefas de processamento em lote nas tabelas, o que, quando em andamento, pode resultar na negação da solicitação de um bloqueio. Conforme mencionado anteriormente, o bloqueio solicitado é um bloqueio único de nível global para todo o servidor, portanto, mesmo que uma única tabela ou banco de dados esteja em processamento, a solicitação de bloqueio teria de aguardar a conclusão da tarefa em andamento.
Outra limitação está relacionada à migração de um servidor de origem AWS RDS. O RDS não é compatível com as tabelas de liberação com bloqueio de leitura, e a consulta LOCK TABLE é executada nas tabelas selecionadas nos bastidores. Como as tabelas são bloqueadas individualmente, o processo de bloqueio pode ser menos confiável e os bloqueios podem levar mais tempo para serem adquiridos.
Novas tentativas
A migração lida com problemas transitórios de conexão, e conexões adicionais normalmente são provisionadas antecipadamente para essa finalidade. Analisamos as configurações de migração, em especial o número de operações de leitura paralelas na origem e aplicamos um fator (normalmente ~ 1,5) e criamos o máximo de conexões antecipadamente. Dessa forma, o serviço garante que possamos manter operações em execução paralelamente. A qualquer momento, se houver uma perda de conexão ou se o serviço não conseguir fazer um bloqueio, ele usará as conexões excedentes provisionadas para tentar fazer a migração novamente. Se todas as conexões provisionadas estiverem esgotadas, resultando na perda da sincronização pontual, a migração deverá ser refeita do início. Em casos de êxito e falha, todas as ações de limpeza são executadas por esse serviço de migração offline, e o usuário não precisa executar nenhuma ação de limpeza explícita.