Este documento aborda a configuração e a execução do processo de migração da base de dados, incluindo cenários de falha. Este documento é a parte 2 de 2. Parte 1 apresenta conceitos, princípios e terminologia da migração de bases de dados com tempo de inatividade quase nulo para arquitetos de nuvem que precisam de migrar bases de dados para Google Cloud de ambientes no local ou de outras nuvens.
Configuração da migração de base de dados
Esta secção descreve as várias fases de uma migração de base de dados. Primeiro, tem de configurar a migração. Em seguida, depois de concluir a migração e mudar os clientes para as bases de dados de destino, remove as bases de dados de origem ou, se necessário, implementa um plano de contingência devido a problemas com a migração após a mudança. Uma alternativa ajuda a garantir a continuidade do negócio.
Durante a migração, tem de prestar especial atenção a quaisquer alterações ao esquema ou aos dados que possam ser introduzidas. Para mais informações sobre o impacto que estas alterações podem ter, consulte a secção Alterações dinâmicas durante a migração mais adiante neste documento.
Especificação do esquema de destino
Para cada sistema de base de dados de destino, tem de definir e criar o respetivo esquema. Para migrações de bases de dados homogéneas, pode criar esta especificação mais rapidamente exportando o esquema da base de dados de origem para a base de dados de destino, criando assim o esquema da base de dados de destino.
A forma como nomeia o seu esquema é importante. Uma opção é fazer corresponder os nomes dos esquemas de origem e de destino. No entanto, embora isto simplifique a mudança de clientes, esta abordagem pode confundir os utilizadores se as ferramentas se ligarem aos esquemas da base de dados de origem e de destino em simultâneo, por exemplo, para comparar dados. Se abstrair o nome do esquema através de um ficheiro de configuração, atribuir aos esquemas da base de dados de destino nomes diferentes dos da origem facilita a diferenciação dos esquemas.
Com as migrações de bases de dados heterogéneas, tem de criar cada esquema da base de dados de destino. Este processo de engenharia pode demorar várias iterações. Antes de poder implementar a migração, pode ter de alterar ainda mais os esquemas para acomodar o processo de migração e quaisquer modificações de dados.
Uma vez que é provável que crie bases de dados de destino várias vezes quando testar e executar a migração, o processo de criação do esquema tem de ser repetível (idealmente, realizado através de scripts de instalação). Pode usar um sistema de gestão de código para controlar a versão dos scripts, garantir a consistência e aceder ao histórico de alterações dos scripts.
Semântica de execução e migração de consultas
Eventualmente, tem de mudar os clientes do acesso aos sistemas de base de dados de origem para o acesso aos sistemas de base de dados de destino. Nas integrações de bases de dados homogéneas, as consultas podem permanecer inalteradas se os esquemas não forem modificados. Embora os clientes tenham de ser testados nos sistemas de base de dados de destino, não têm de ser modificados devido a consultas.
Em geral, para migrações de bases de dados heterogéneas, tem de modificar as consultas, uma vez que os esquemas entre as bases de dados de origem e de destino diferem. A diferença pode ser uma incompatibilidade de tipo de dados entre as bases de dados de origem e de destino. Além disso, nem todas as capacidades da linguagem de consulta disponíveis nos sistemas de base de dados de origem podem estar disponíveis nos sistemas de base de dados de destino, ou vice-versa. Em casos extremos, pode ter de converter uma consulta de um sistema de base de dados de origem em várias consultas no sistema de destino. Num cenário inverso, em que tem mais capacidades de linguagem de consulta disponíveis na base de dados de destino do que na origem, pode ter de combinar várias consultas da base de dados de origem numa única consulta na base de dados de destino correspondente.
A semântica das consultas também pode diferir. Por exemplo, alguns sistemas de base de dados materializam uma atualização numa transação imediatamente nessa transação, pelo que, quando o mesmo item de dados é lido, o valor atualizado é obtido. Outros sistemas não concretizam uma atualização imediatamente e aguardam até que a transação seja confirmada. Se a lógica no sistema de base de dados de origem depender da materialização da gravação, a mesma lógica na base de dados de destino pode causar dados incorretos ou até falhas.
Se tiver de migrar consultas, tem de testar todas as funcionalidades para garantir que o comportamento dos clientes é o mesmo antes e depois da migração. Também pode testar ao nível dos dados, mas esses testes não substituem os testes ao nível do cliente. Os clientes executam consultas do ponto de vista da lógica empresarial e só podem ser testados ao nível da lógica empresarial.
Processos de migração
Para migrações de bases de dados heterogéneas, os processos de migração especificam como os dados extraídos dos sistemas de bases de dados de origem são modificados e inseridos nas bases de dados de destino. As modificações de dados, como as abordadas em Alterações de dados neste documento, são definidas e executadas enquanto os itens de dados são extraídos das bases de dados de origem e transferidos para as bases de dados de destino.
Com as migrações de bases de dados homogéneas, quando os esquemas das bases de dados de origem e de destino são equivalentes, não é necessária a modificação de dados. Os dados são inseridos nas bases de dados de destino tal como foram extraídos das bases de dados de origem.
Consoante o seu sistema de migração de bases de dados, podem ser necessárias várias configurações. Por exemplo, tem de especificar se os dados que estão a ser modificados e transferidos têm de ser armazenados intermitentemente no sistema de migração da base de dados. O armazenamento dos dados pode abrandar o processo de migração geral, mas acelera significativamente a recuperação se ocorrer uma falha. Pode ter de especificar o tipo de validação. Por exemplo, alguns sistemas de migração de bases de dados consultam os sistemas de origem e de destino para estabelecer a equivalência do conjunto de dados migrado até ao ponto da consulta. O processamento de erros requer que especifique o comportamento de recuperação de falhas. Mais uma vez, este requisito depende do sistema de migração da base de dados em utilização.
É evidente que tem de testar a migração de dados exaustiva e repetidamente. Idealmente, a migração é testada para garantir que todos os itens de dados conhecidos são migrados, que não ocorrem erros de modificação de dados, que o desempenho e o débito são suficientes e que o tempo de migração pode ser alcançado.
Processos alternativos
Durante uma migração de base de dados, as bases de dados de origem permanecem operacionais (a menos que a migração envolva uma inatividade planeada). Se a migração da base de dados falhar em qualquer altura, pode (no pior cenário) anular a migração e repor a base de dados de destino para o respetivo estado inicial. Depois de resolver as falhas, pode reiniciar a migração da base de dados. A falha e a resolução não afetam os sistemas de base de dados de origem operacionais.
Se ocorrerem falhas após a conclusão da migração da base de dados e a mudança dos clientes para as bases de dados de destino, o processo de falha e resolução pode afetar os clientes de modo que não consigam funcionar corretamente. No melhor dos casos, a falha é resolvida rapidamente e o tempo de inatividade para os clientes é curto. No pior dos casos, a falha não é resolvida ou a resolução demora muito tempo e tem de voltar a mudar os clientes para as bases de dados de origem.
Para voltar a associar os clientes às bases de dados de origem, tem de migrar todas as modificações de dados nas bases de dados de destino de volta para as bases de dados de origem. Pode configurar e executar este processo como uma migração de base de dados separada e completa. No entanto, como os clientes estão inoperacionais nas bases de dados de destino neste momento, vai ocorrer um tempo de inatividade significativo.
Para evitar o período de inatividade do cliente neste cenário, tem de iniciar os processos de migração imediatamente após a conclusão da migração da base de dados original. Todas as alterações aplicadas aos sistemas de bases de dados de destino são aplicadas imediatamente aos sistemas de bases de dados de origem. Seguir esta abordagem garante que os sistemas de base de dados de destino e de origem são mantidos sincronizados em todos os momentos.
A preparação de uma alternativa das bases de dados de destino para as bases de dados de origem requer um esforço significativo. É fundamental decidir se quer implementar e testar processos de alternativa ou compreender as consequências de não o fazer, nomeadamente, um tempo de inatividade significativo.
Execução da migração de base de dados
A execução de uma migração de base de dados envolve cinco fases distintas, que esta secção aborda. Uma sexta fase é uma alternativa, mas uma alternativa é um caso extremo e é considerada uma exceção a uma execução normal da migração da base de dados.
O processo abordado nesta secção é uma migração de base de dados heterogénea com um tempo de inatividade quase nulo. Se puder incorrer num tempo de inatividade significativo, pode combinar as três primeiras fases (carregamento inicial, migração contínua e esgotamento) numa única fase usando a abordagem de cópia de segurança e restauro ou de exportação e importação.
Uma migração de base de dados homogénea apresenta um caso especial. Com este tipo de migração, pode usar a funcionalidade de replicação do sistema de gestão de bases de dados (para os sistemas que a suportam) que migra os dados enquanto os sistemas de base de dados de origem permanecem operacionais.
As fases abordadas aqui descrevem uma abordagem que pode ter de modificar de acordo com os requisitos do seu processo de migração da base de dados.
Fase 1: carregamento inicial
O ponto de partida é migrar todos os dados especificados para migração de todas as bases de dados de origem. No início da migração de dados, as bases de dados de origem têm um estado específico, e esse estado muda durante a migração.
Uma sugestão para iniciar uma migração enquanto ocorrem alterações em simultâneo é anotar a hora do sistema da base de dados imediatamente antes de o primeiro item de dados ser extraído. Com esta data/hora, pode obter todas as alterações da base de dados a partir do registo de transações a partir dessa data/hora. Além disso, o carregamento inicial tem de ler um estado da base de dados consistente em todos os dados. Pode precisar de um bloqueio de curta duração na base de dados para evitar a leitura de um conjunto de dados inconsistente.
Esta fase consiste no seguinte:
- Anotar a hora do sistema da base de dados imediatamente antes do início da migração da base de dados.
- Executar um processo de migração de carregamento inicial que consulte o conjunto de dados (completo ou parcial) das bases de dados de origem que precisam de ser migradas e migrar o conjunto de dados. Num modelo de base de dados relacional, os processos de migração de carregamento inicial executam consultas como
SELECT *ou consultas com seleção, ou projeção, ou ambas. O processo de migração executa a modificação de dados conforme especificado no processo.
Enquanto os processos de migração de carregamento inicial são executados, os clientes fazem normalmente alterações às bases de dados de origem. Como regista a hora do sistema da base de dados no início, pode derivar essas alterações do registo de transações posteriormente.
O resultado da fase de carregamento inicial é a migração completa do conjunto de dados inicial dos sistemas de base de dados de origem para os sistemas de base de dados de destino. No entanto, as bases de dados de origem e de destino ainda não estão sincronizadas porque os clientes provavelmente modificaram as bases de dados de origem durante a migração. A fase 2 envolve a captura e a migração dessas alterações.
Fase 2: continuar a migração
A continuação da migração tem dois objetivos. Primeiro, lê as alterações que ocorreram nas bases de dados de origem após o início do carregamento inicial. Em segundo lugar, captura e transfere essas alterações para as bases de dados de destino.
Esta fase consiste no seguinte:
- Início dos processos de migração contínuos a partir do sistema de base de dados tempo registado na Fase 1. A migração lê o registo de transações a partir desse momento e aplica todas as alterações ao sistema de base de dados de destino.
- Executar qualquer modificação de dados. O processo de migração executa este passo conforme especificado.
As alterações registadas após a hora do sistema da base de dados são, por vezes, transferidas durante o carregamento inicial. Por conseguinte, é possível que essas alterações possam ser aplicadas uma segunda vez durante a migração contínua. Tem de definir os processos de migração para garantir que as alterações não são aplicadas duas vezes, por exemplo, através de identificadores. Suponhamos que um item de dados alterado é transferido durante o carregamento inicial e que essa inserção é registada no registo de transações. Ao aplicar um identificador ao item de dados, o sistema de migração pode determinar a partir do registo de transações que não é necessária outra inserção porque o item de dados já existe.
O resultado da fase de migração contínua é que as bases de dados de destino estão totalmente sincronizadas ou quase totalmente sincronizadas com as bases de dados de origem. Quando uma alteração num sistema de base de dados de origem não é migrada, tem uma base de dados quase sincronizada.
Consoante a forma como configura o sistema de migração da base de dados, as discrepâncias podem ser pequenas ou grandes. Por exemplo, para aumentar a eficiência, nem todas as alterações devem ser migradas imediatamente. Caso contrário, pode criar uma carga pesada na origem se as alterações à origem aumentarem repentinamente. Em geral, as alterações são recolhidas e migradas em lotes como operações em massa. Com lotes mais pequenos, ocorrem menos discrepâncias entre a origem e o destino, mas a origem pode incorrer numa carga mais elevada se forem feitas alterações com frequência.
Se o tamanho do lote for configurado dinamicamente, é melhor sincronizar lotes maiores inicialmente na fase de migração contínua e, em seguida, sincronizar lotes de um tamanho gradualmente reduzido quando as bases de dados estiverem quase atualizadas. Esta abordagem torna o processo de sincronização mais eficiente e reduz a discrepância entre as bases de dados de origem e de destino mais tarde.
Fase 3: esgotamento
Para se preparar para mudar os clientes das bases de dados de origem para as bases de dados de destino, tem de garantir que as bases de dados de origem e a base de dados de destino estão totalmente sincronizadas. A drenagem é o processo de migração das alterações restantes das bases de dados de origem para as bases de dados de destino.
Esta fase consiste no seguinte:
- Desativar os sistemas de base de dados de origem. Isto significa que não podem ocorrer modificações de dados na base de dados de origem e que o registo de transações não recebe entradas de modificação adicionais.
- A aguardar que todas as alterações sejam migradas para as bases de dados de destino. Este processo é a drenagem real das alterações.
- Após a conclusão da eliminação, faça uma cópia de segurança das bases de dados de destino para ter um ponto de partida definido para futuras cópias de segurança incrementais.
O resultado da fase de esgotamento é que os sistemas de bases de dados de origem e os sistemas de bases de dados de destino são sincronizados, e não ocorrem modificações de dados.
Para garantir que a eliminação está concluída, pode escrever um item de dados "last insert" numa base de dados de origem. Assim que o item de dados "last insert" aparecer na base de dados de destino correspondente, a fase de esgotamento está concluída.
Fase 4: mudança
Após a conclusão da fase de esgotamento, pode mudar os clientes das bases de dados de origem para as bases de dados de destino. Recomendamos as seguintes práticas recomendadas:
- Antes de ativar o acesso à base de dados de produção, teste a funcionalidade básica para garantir que os clientes estão operacionais e funcionam conforme previsto. O número de casos de teste determina o tempo de inatividade real da base de dados de produção.
- Faça uma cópia de segurança das bases de dados de destino antes de ativar o acesso do cliente. Esta prática recomendada garante que o estado inicial das bases de dados de destino é recuperável.
No final da comutação, os clientes estão totalmente operacionais e começam a aceder às bases de dados de produção (o que este documento denominou bases de dados de destino até este ponto).
Fase 5: eliminação da base de dados de origem
Depois de concluir a comutação para as bases de dados de produção, pode eliminar as bases de dados de origem. É uma boa prática fazer uma cópia de segurança final de cada base de dados de origem para ter um estado final definido e acessível. Os regulamentos de dados também podem exigir cópias de segurança finais por motivos de conformidade.
Fase 6: alternativa
A implementação de uma alternativa, especialmente para clientes de bases de dados altamente críticos, pode ser uma boa salvaguarda contra problemas com a sua migração. Uma reversão é semelhante a uma migração, mas no sentido inverso. Ou seja, com uma alternativa, configura uma migração das bases de dados de destino de volta para as bases de dados de origem. Com as migrações de bases de dados heterogéneas, o recuo é mais complexo. É por este motivo que recomendamos que faça a mudança apenas depois de testar exaustivamente o seu processo de migração da base de dados e as suas aplicações ligadas à base de dados de dados de destino, cumprem os seus contratos de nível de serviço (SLAs).
Depois de esvaziar as bases de dados de origem e fazer uma cópia de segurança de todas as bases de dados, pode ativar processos de migração que identifiquem alterações nas bases de dados de destino e as migrem para as bases de dados de origem antes da mudança.
A criação destes processos de migração garante que, após os clientes fazerem alterações às bases de dados de destino, as bases de dados de origem são sincronizadas e o respetivo estado dos dados é mantido atualizado. Pode ser necessário um recuo dias ou semanas após a mudança. Por exemplo, os clientes podem aceder à funcionalidade pela primeira vez e ser bloqueados devido a uma funcionalidade danificada que não pode ser corrigida rapidamente. Neste caso, os clientes podem voltar a aceder às bases de dados de origem. Antes de os clientes serem novamente comutados, todas as alterações às bases de dados de destino têm de ser transferidas para as bases de dados de origem.
Nesta abordagem, algumas circunstâncias requerem atenção especial:
- Tem de conceber esquemas de destino para que seja possível uma migração inversa (das bases de dados de destino para as bases de dados de origem). Por exemplo, se o processo de migração inicial (da origem para o destino) tiver junções ou agregações, uma migração inversa é complexa ou até impossível. Nesse caso, os dados individuais também têm de estar disponíveis nas bases de dados de destino.
- Pode surgir um problema em que as bases de dados de origem têm registos de transações, mas as bases de dados de destino não oferecem essa funcionalidade não funcional. Neste caso, uma migração inversa (do destino para a origem) tem de se basear em consultas diferenciais. Essa configuração tem de ser concebida e preparada nos esquemas da base de dados de destino.
- Os clientes que operavam originalmente nas bases de dados de origem têm de ser mantidos disponíveis e operacionais para que possam ser ativados numa alternativa. Quaisquer alterações funcionais feitas aos clientes que acedem às bases de dados de destino também têm de ser feitas aos clientes que acedem à base de dados de origem para garantir a equivalência funcional.
Embora a alternativa seja um último recurso, a implementação de uma alternativa é essencial e tem de ser tratada como uma migração completa da base de dados, que inclui testes.
Alterações dinâmicas durante a migração
Em geral, as bases de dados são sistemas dinâmicos porque o esquema e os valores dos dados podem mudar. Os esquemas de bases de dados podem mudar com base em fatores como os requisitos da empresa e os valores dos dados podem mudar em conjunto com as alterações do esquema ou independentemente destas. As alterações aos valores dos dados podem ocorrer dinamicamente em qualquer altura com as alterações correspondentes à implementação de uma aplicação. As secções seguintes abordam algumas das possíveis alterações e as respetivas implicações para uma migração da base de dados.
Alterações ao esquema
As bases de dados podem ser categorizadas em sistemas que requerem um esquema predefinido ou que não têm esquema. Em geral, os sistemas que requerem um esquema predefinido suportam operações de alteração do esquema, por exemplo, adicionar atributos ou colunas num sistema relacional.
Nestes sistemas, controla as alterações através de um processo de gestão da mudança. Um processo de gestão de alterações permite que as alterações sejam feitas de forma controlada. Todas as operações que dependem do esquema, como consultas ou processos de migração de dados, são alteradas simultaneamente para garantir uma alteração consistente geral.
Os sistemas de base de dados que não requerem um esquema predefinido podem ser alterados em qualquer altura. Uma alteração do esquema só pode ser feita por um utilizador autorizado. Em alguns casos, é possível fazê-la por programação. Nestes casos, pode ocorrer uma alteração do esquema em qualquer altura. As operações que dependem do esquema podem falhar, por exemplo, consultas ou processos de migração de dados. Para evitar alterações não controladas ao esquema nestes sistemas de bases de dados, tem de implementar um processo de gestão de alterações como uma convenção e uma regra aceite, em vez de através da aplicação do sistema.
Alterações de dados
Em geral, os esquemas controlam os possíveis valores de dados para os vários atributos de dados. Os sistemas sem esquema não têm restrições nos valores dos dados.
Em qualquer dos casos, podem aparecer valores de dados que não foram armazenados anteriormente. Por exemplo, os tipos de enumeração são frequentemente implementados como um conjunto de strings em sistemas de bases de dados. Ao nível da linguagem de programação, estes podem ser implementados nos clientes como tipos de enumeração verdadeiros, mas não necessariamente. É possível que um cliente armazene o que considera um valor de enumeração válido que outros clientes não consideram válido. Além disso, um processo de migração de dados pode basear a sua funcionalidade em valores de enumeração. Se aparecerem novos valores, o processo de migração de dados pode falhar.
Outro exemplo encontra-se no armazenamento de estruturas JSON. Em muitos casos, as estruturas JSON são armazenadas numa string de tipo de dados. No entanto, são interpretadas como valores JSON no acesso. Se a estrutura JSON for alterada, o sistema de base de dados não deteta essa alteração. Os processos de migração de dados que interpretam uma string como um valor JSON podem falhar.
Alterações ao processo de migração
A gestão de alterações durante uma migração de base de dados em curso é difícil e complexa, e pode levar a falhas de migração de dados ou inconsistências de dados. É ideal que as alterações necessárias sejam atrasadas até ao final da fase de esgotamento, altura em que os sistemas de base de dados de origem e de destino são sincronizados. As alterações neste ponto ficam confinadas às bases de dados de destino e aos respetivos clientes (a menos que também seja implementada uma alternativa).
Se precisar de alterar o processo de migração durante uma migração de dados, recomendamos que mantenha as alterações ao mínimo e, possivelmente, faça várias alterações pequenas em vez de uma mais complexa. Além disso, pode considerar testar primeiro essas alterações usando instâncias de teste das bases de dados de origem e de destino. Idealmente, carrega a origem de teste com dados de produção que, em seguida, migra para o destino de teste. Com esta abordagem, pode validar as alterações propostas sem afetar a migração de produção em curso. Depois de testar e validar as alterações, pode aplicá-las ao seu sistema de produção.
Para que as alterações sejam possíveis durante uma migração de dados em curso, tem de poder parar o sistema de migração de dados e reiniciá-lo, possivelmente com processos de migração de dados modificados. Nesse caso, não tem de começar do início com uma fase de carregamento de dados inicial. Se o sistema de migração de dados suportar uma funcionalidade de execução de migração de teste, também pode usá-la.
Recomendamos que evite alterar o esquema, os valores de dados ou os processos de migração de dados durante uma migração de dados. Se tiver de fazer alterações, considere reiniciar a migração de dados desde o início para garantir que tem um estado inicial definido. Em qualquer caso, é fundamental que faça testes com dados de produção e que faça uma cópia de segurança das bases de dados antes de aplicar alterações para que, se necessário, possa repor o sistema geral para um estado consistente.
Mitigação de falhas de migração
Podem ocorrer problemas inesperados durante uma migração da base de dados. Os seguintes pontos destacam algumas áreas que podem exigir planeamento prévio:
- Débito insuficiente. Um sistema de migração pode não ter débito suficiente, apesar dos testes de carga. Este problema pode ter várias causas, como um aumento imprevisto da taxa de alterações da base de dados de origem ou a limitação da largura de banda da rede. Pode preparar-se para este caso preparando recursos adicionais para o aumento ou a expansão dinâmicos de todos os componentes envolvidos.
- Instabilidade da base de dados. As bases de dados de origem ou as bases de dados de destino podem apresentar instabilidade, o que pode atrasar os processos de migração de dados ou impedir o acesso intermitentemente. Os processos de migração de dados podem ter de ser recuperados com frequência. Neste caso, uma comutação intencional de HA ou DR pode resolver o problema. Uma comutação altera o ambiente não funcional (máquinas e armazenamento) e pode ajudar a mitigar o problema. Neste caso, tem de testar a mudança e os processos de recuperação da migração da base de dados para garantir que a mudança não causa inconsistências nos dados nas bases de dados de destino.
- Esgotamento do tamanho do ficheiro de registo de transações. Em alguns casos, os registos de transações são armazenados em ficheiros com um limite superior. É possível que este limite superior seja atingido e, em seguida, a migração da base de dados falhe. É importante compreender que partes de um sistema de base de dados podem ser reconfiguradas dinamicamente para resolver as limitações de recursos à medida que surgem. Se determinados aspetos não puderem ser configurados dinamicamente, a dimensão inicial tem de ser determinada cuidadosamente.
Quanto mais realista e completo for o teste inicial, maior a probabilidade de encontrar potenciais problemas a resolver antecipadamente.
O que se segue?
- Consulte os seguintes recursos sobre a migração de bases de dados:
- Consulte o artigo Migração de base de dados para ver mais guias de migração de bases de dados.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.