Guide de mise à niveau d’une base de données auto-hébergée : export, instantané, migration et restauration en arrière

L’approche sûre consiste à traiter une mise à niveau progressive utilisant des sauvegardes natives, des instantanés du stockage, une répétition de restauration isolée et un point de retour clairement défini comme une suite de contrôles observables, et non comme une seule commande.

Sur une base de données PostgreSQL ou MariaDB conteneurisée sur un serveur domestique, le risque pratique est de devoir mettre à niveau une base de données auto-hébergée sans perdre les objets logiques ni une possibilité viable de retour en arrière. Notez l’identité actuelle et le point de récupération, commencez par le discriminateur le moins invasif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le processus ci-dessous ne se termine qu’une fois que la charge de travail d’origine fonctionne ou que les éléments disponibles atteignent une limite nécessitant une escalade.

Définir la compatibilité et le retour en arrière avant la sauvegarde

Notez le moteur de base de données et la version source exacte, la version cible, la version de l’application, les extensions ou modules, le jeu de caractères, les règles d’authentification, les tâches planifiées et la durée d’indisponibilité disponible. Lisez les notes de mise à niveau de l’application ainsi que celles concernant le chemin de la base de données, car une migration de l’application peut rendre les anciens binaires incompatibles avec le nouveau schéma.

Les mises à niveau majeures nécessitent souvent une sauvegarde logique et une restauration, ou un outil de migration pris en charge, plutôt que le montage de l’ancien répertoire de données dans une nouvelle image. Un processus indépendant de mise à niveau majeure d’une base de données Compose décrit une mise à niveau majeure de PostgreSQL basée sur Compose et montre pourquoi l’ancien conteneur et le volume doivent rester distincts de la cible.

Définissez dès maintenant la date limite et les déclencheurs du retour en arrière : contrôles d’intégrité échoués, rôles ou extensions manquants, erreurs de l’application ou performances inacceptables. Le retour en arrière reste possible uniquement jusqu’au début des écritures de production sur la cible, sauf si un plan de migration inverse des données a été testé.

Créer deux points de récupération indépendants

Exécutez la sauvegarde logique native du moteur avec les objets globaux lorsque cela s’applique, puis enregistrez la commande, la version, le code de sortie, le manifeste et la somme de contrôle. Vérifiez que les utilisateurs, autorisations, extensions, schémas, tâches planifiées et objets volumineux sont inclus, plutôt que de supposer qu’une seule sauvegarde de base contient toutes les dépendances au niveau du serveur.

Prenez un instantané coordonné ou une copie du volume de la base de données à l’arrêt, après avoir confirmé que la base se trouve dans un état pris en charge. La sauvegarde logique offre portabilité et inspection au niveau des objets ; la copie du stockage préserve un point de retour exact vers l’ancienne version. L’une ne doit pas écraser l’autre.

Utilisez la liste de contrôle de vérification de ZimaSpace pour déterminer si la liste de contrôle de l’exhaustivité de la sauvegarde de la base de données est respectée. Le contrôle de sauvegarde n’est validé que lorsque la sauvegarde est lisible, que le point de récupération du stockage est identifié et que les deux éléments sont stockés en dehors du volume mis à niveau.

Répéter la migration dans une cible isolée

Démarrez la base de données cible sur un volume et un port distincts, installez les extensions requises, restaurez la sauvegarde logique et enregistrez chaque avertissement. Un guide Percona consacré au processus de mise à niveau par sauvegarde logique et restauration met en évidence la séquence de sauvegarde et de restauration, ainsi que la nécessité d’utiliser des outils correspondant au chemin de mise à niveau PostgreSQL prévu.

Connectez une instance d’application jetable à la base de données restaurée. Testez la connexion, les lectures, les écritures, les tâches en arrière-plan, la recherche, les pièces jointes, les fuseaux horaires et un redémarrage. Comparez les nombres de lignes et les agrégats critiques au lieu de vous fier uniquement à un code de sortie de restauration réussi.

Ne poursuivez pas si des extensions sont indisponibles, si des changements de collation restent non résolus, si les migrations échouent ou si la durée de restauration dépasse la fenêtre de maintenance. Corrigez la répétition et créez une nouvelle sauvegarde ; la production n’est pas l’endroit où découvrir une incompatibilité avec la version cible.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Basculer les écritures et préserver un retour en arrière propre

Passez en mode maintenance, arrêtez les processus d’écriture et les tâches de l’application, vérifiez que les connexions actives se ferment, puis créez la sauvegarde finale ou le delta pris en charge. Restaurez-le sur une cible propre, exécutez les contrôles d’intégrité et des objets, mettez à jour la connexion de l’application et démarrez les services dans l’ordre des dépendances.

Surveillez les taux d’erreur, les verrous, l’exécution des tâches, les sauvegardes et les transactions réelles de l’application. Maintenez l’ancienne base de données arrêtée et en lecture seule, avec son volume d’origine et son condensat d’image. Ne laissez jamais les deux bases de données accepter des écritures indépendantes sous la même identité d’application.

Ne déclarez la réussite qu’après validation de l’application, de la tâche de sauvegarde native, du redémarrage et d’une restauration de test depuis la nouvelle version. Si un déclencheur de retour en arrière se manifeste avant la limite d’écriture, redirigez l’application vers l’ancienne instance préservée ; après de nouvelles écritures, arrêtez-vous et utilisez le plan de rapprochement documenté au lieu de prétendre qu’un simple redémarrage annule les données.