Guia de atualização de bases de dados auto-hospedadas: exportar, criar um instantâneo, migrar e reverter

A abordagem segura consiste em tratar uma atualização faseada, utilizando dumps nativos, snapshots do armazenamento, um ensaio de restauro isolado e um ponto de reversão claramente delimitado, como uma sequência de etapas observáveis, não como um único comando.

Numa base de dados PostgreSQL ou MariaDB em contentor num servidor doméstico, o risco prático é uma base de dados auto-hospedada precisar de uma atualização de versão sem perder objetos lógicos nem um caminho de reversão viável. Registe a identidade atual e o ponto de recuperação, comece pelo discriminador menos invasivo, interprete os resultados aprovados e reprovados antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina depois de a carga de trabalho original ser executada com êxito ou de as evidências atingirem um limite de escalonamento.

Defina a compatibilidade e a reversão antes da cópia de segurança

Registe o motor da base de dados e a versão de origem exata, a versão de destino, a versão da aplicação, as extensões ou os plug-ins, o conjunto de caracteres, as regras de autenticação, as tarefas agendadas e o tempo de inatividade disponível. Leia as notas de atualização da aplicação, bem como o percurso da base de dados, porque uma migração da aplicação pode tornar os binários antigos incompatíveis com o novo esquema.

As atualizações de versões principais exigem frequentemente um dump lógico e um restauro ou uma ferramenta de migração compatível, em vez de montar o diretório de dados antigo numa nova imagem. Um fluxo independente de atualização da versão principal da base de dados no Compose descreve uma atualização da versão principal do PostgreSQL baseada em Compose e mostra por que motivo o contentor e o volume antigos têm de permanecer distintos do destino.

Defina agora o prazo e o acionador da reversão: verificações de integridade falhadas, funções ou extensões em falta, erros da aplicação ou desempenho inaceitável. A reversão só continua viável até serem iniciadas escritas de produção no destino, exceto se tiver sido testado um plano de migração de dados inversa.

Crie dois pontos de recuperação independentes

Execute a cópia de segurança lógica nativa do motor, incluindo os objetos globais quando aplicável, e guarde o comando, a versão, o estado de saída, o manifesto e a soma de verificação. Verifique se os utilizadores, as permissões, as extensões, os esquemas, as tarefas agendadas e os objetos grandes estão incluídos, em vez de assumir que um único dump da base de dados contém todas as dependências ao nível do servidor.

Faça um snapshot coordenado ou uma cópia da unidade de dados com a base de dados parada, depois de confirmar que esta se encontra num estado compatível. O dump lógico proporciona portabilidade e inspeção ao nível dos objetos; a cópia do armazenamento preserva um ponto de reversão exato da versão antiga. Nenhum dos dois deve substituir o outro.

Utilize a lista de verificação de validação da ZimaSpace para determinar se a lista de verificação da integridade da cópia de segurança da base de dados está completa. A etapa da cópia de segurança só é aprovada quando o dump é legível, o ponto de recuperação do armazenamento está identificado e ambos estão guardados fora do volume que será atualizado.

Faça um ensaio da migração num destino isolado

Inicie a base de dados de destino num volume e numa porta separados, instale as extensões necessárias, restaure a cópia de segurança lógica e guarde todos os avisos. Um guia da Percona sobre o percurso de atualização através de dump lógico e restauro destaca a sequência de dump e restauro e a necessidade de utilizar ferramentas compatíveis com o percurso de atualização do PostgreSQL pretendido.

Ligue uma instância descartável da aplicação à base de dados restaurada. Teste o início de sessão, as leituras, as escritas, as tarefas em segundo plano, a pesquisa, os anexos, os fusos horários e um reinício. Compare as contagens de linhas e os agregados críticos, em vez de confiar apenas num código de saída de restauro bem-sucedido.

Não avance se as extensões não estiverem disponíveis, se as alterações de agrupamento não estiverem resolvidas, se as migrações falharem ou se o tempo de restauro exceder a janela de manutenção. Corrija o ensaio e crie um dump novo; a produção não é o lugar para descobrir incompatibilidades com a versão de destino.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Transfira as escritas e mantenha a reversão limpa

Entre no modo de manutenção, pare os processos de escrita e as tarefas da aplicação, confirme que as ligações ativas são encerradas e, em seguida, crie o dump final ou o delta compatível. Restaure-o num destino limpo, execute verificações de integridade e dos objetos, atualize a ligação da aplicação e inicie os serviços pela ordem das dependências.

Observe as taxas de erro, os bloqueios, a execução das tarefas, as cópias de segurança e as transações reais da aplicação. Mantenha a base de dados antiga parada e só de leitura, com o volume original e o resumo criptográfico da imagem. Nunca permita que ambas as bases de dados aceitem escritas independentes com a mesma identidade da aplicação.

Declare o sucesso apenas depois de a aplicação, a tarefa de cópia de segurança nativa, o reinício e um restauro de teste a partir da nova versão serem todos aprovados. Se um acionador de reversão for ativado antes do limite de escrita, aponte a aplicação novamente para a instância antiga preservada; depois de existirem novas escritas, pare e utilize o plano de reconciliação documentado, em vez de fingir que um simples reinício reverte os dados.