Banco de dados MySQL para Azure para migração de dados MySQL - Instantâneo consistente do MySQL
MySQL Consistent Snapshot é um novo recurso que permite aos usuários tirar um instantâneo consistente de um servidor MySQL sem perder a integridade dos dados na origem devido a operações CRUD (Criar, Ler, Atualizar e Excluir) em andamento. A consistência transacional é alcançada 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 - habilitar instantâneo consistente com bloqueio de leitura (GA), habilitar instantâneo consistente sem bloqueios (visualização), tornar o servidor de origem somente leitura e nenhum. Selecionar a opção «Nenhum» implica que não sejam tomadas medidas adicionais para garantir a coerência dos dados. Ambas as opções - habilitar instantâneo consistente com bloqueio de leitura (GA), habilitar instantâneo consistente sem bloqueios suporte a execução de uma migração on-line. É altamente recomendável selecionar a opção 'Ativar instantâneo consistente sem bloqueios' para manter a consistência transacional.
Habilitar instantâneo consistente sem bloqueios (visualização)
Quando você habilita essa opção, uma fase de reconciliação ocorrerá após o carregamento 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 usamos um bloqueio de leitura no servidor. Em vez disso, lemos tabelas em diferentes momentos no tempo, enquanto acompanhamos as 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 de recuperação para obter um instantâneo consistente.
Principais recursos do Consistent Snapshot sem bloqueios:
- Capacidade de suportar servidores de carga de trabalho pesada ou servidores com transações de longa execução sem a necessidade de bloqueios de leitura.
- Resiliente na conclusão de migrações, mesmo no caso de falhas causadas por falhas transitórias de rede/servidor que resultam na perda de todas as conexões pré-criadas.
Habilite o instantâneo consistente com bloqueio de leitura (GA)
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 point-in-time. 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 atual da tabela com o conteúdo do log de desfazer do instantâneo. O snapshot é gerado depois de obter o bloqueio de todo o servidor por alguns segundos e gerar várias conexões para a migração. Após a criação de todas as conexões usadas para a migração, os bloqueios na tabela são liberados.
As leituras repetíveis são habilitadas para manter os logs de desfazer acessíveis durante a migração, o que aumenta o armazenamento necessário na origem devido a conexões de longa execução. Uma migração de longa duração com várias alterações de tabela leva a um extenso histórico de log de desfazer que precisa ser repetido e também pode aumentar os requisitos de computação e a carga no servidor de origem.
Tornar o servidor de origem somente leitura
A seleção dessa opção mantém a integridade dos 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ê torna o servidor de origem somente leitura como parte do processo de migração, a seleção se aplica a todos os bancos de dados do servidor de origem, independentemente de eles estarem selecionados para migração.
Tornar o servidor de origem somente leitura impede que os usuários modifiquem os dados, tornando o banco de dados indisponível para quaisquer operações de atualização. No entanto, se essa opção não estiver habilitada, há a possibilidade de que as atualizações de dados ocorram durante a migração. Como resultado, os dados migrados podem ser inconsistentes porque os instantâneos do banco de dados seriam lidos em diferentes momentos 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 bloqueio de leitura ativado:
Certifique-se de que o usuário que está tentando liberar tabelas com um bloqueio de leitura tenha a permissão RELOAD ou FLUSH.
Use a ferramenta de cliente mysql para determinar se log_bin está habilitado no servidor de origem. O log do 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 fonte executando o comando: MOSTRAR VARIÁVEIS COMO 'log_bin';
Nota
Com o Banco de Dados do Azure para Servidor Único MySQL, que suporta até 4 TB, isso não é habilitado por padrão. No entanto, se você promover uma réplica de leitura para o servidor de origem e, em seguida, 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 binlog não sejam limpos antes que a réplica confirme as alterações. Após a transferência bem-sucedida, o valor pode 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.
- Nenhuma alteração 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 tentativas.
Nota
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 é suportado apenas pelo InnoDB. Mais informações aqui.
Bloqueios
Normalmente, é um processo simples para obter um bloqueio, que deve levar entre alguns segundos e alguns minutos para ser concluído. Em alguns cenários, no entanto, as tentativas de obter um bloqueio no servidor de origem podem falhar.
A presença de consultas de longa duração pode resultar em tempo de inatividade desnecessário, já que o DMS pode bloquear um subconjunto das tabelas e, em seguida, esperar que os últimos fiquem disponíveis. Antes de iniciar a migração, verifique se há operações de longa duração executando o comando SHOW PROCESSLIST .
Se o servidor de origem estiver enfrentando muitas atualizações de gravação no momento em que um bloqueio é solicitado, o bloqueio não poderá ser obtido prontamente e poderá falhar após o tempo limite de espera de bloqueio. Isso acontece no caso de tarefas de processamento em lote nas tabelas, que quando em andamento podem resultar na negação da solicitação de bloqueio. Como mencionado anteriormente, o bloqueio solicitado é um único bloqueio 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 que aguardar a conclusão da tarefa em andamento.
Outra limitação está relacionada à migração de um servidor de origem do AWS RDS. O RDS não suporta tabelas niveladas com bloqueio de leitura e a consulta LOCK TABLE é executada nas tabelas selecionadas sob o capô. Como as mesas são bloqueadas individualmente, o processo de bloqueio pode ser menos confiável e as fechaduras podem levar mais tempo para serem adquiridas.
Tentativas
A migração lida com problemas de conexão transitória e conexões adicionais geralmente são provisionadas antecipadamente para essa finalidade. Examinamos as configurações de migração, particularmente o número de operações de leitura paralela na origem e aplicamos um fator (normalmente ~1.5) e criamos o máximo de conexões antecipadamente. Desta forma, o serviço garante que podemos manter as operações funcionando em paralelo. A qualquer momento, se houver uma perda de conexão ou o serviço não conseguir obter um bloqueio, o serviço usará as conexões excedentes provisionadas para repetir a migração. Se todas as conexões provisionadas estiverem esgotadas, resultando na perda da sincronização point-in-time, a migração deverá ser reiniciada desde o início. Em casos de sucesso e falha, todas as ações de limpeza são realizadas por esse serviço de migração offline e o usuário não precisa executar nenhuma ação de limpeza explícita.