Mise à niveau de Postgres sans interruption

Préparation à la mise à niveau de Postgres

• Évaluation des risques : dresser la liste des risques pouvant survenir pendant la mise à niveau et les classer par ordre d'importance.
• Recherche de solutions aux risques : envisager des solutions permettant d'éliminer complètement les risques ou de les répartir dans le temps.
• Mise à jour de la liste des risques : actualiser la liste si de nouveaux risques sont découverts au cours du projet.

À propos de la surveillance et des métriques

• Supervision du système : utiliser des outils rigoureux pour surveiller l'état de santé de la base de données et du système.
• Observation des métriques clés : surveiller les principales métriques comme l'ID de transaction, l'utilisation CPU, les sessions en attente, la latence des requêtes et la latence de réponse des API.

Options de mise à niveau de Postgres

Mise à niveau sur place (inadaptée à une mise à niveau sans interruption)

• Limites de la mise à niveau sur place : lorsqu'elle est exécutée sur AWS RDS, un redémarrage de la base de données est nécessaire, et la durée dépend du volume de données.

Mise à niveau basée sur la réplication

• Choix d'une mise à niveau basée sur la réplication : permet une migration progressive, de tester la nouvelle base de données avec la charge réelle et les données réelles, et de garder le contrôle sur la mise à niveau.
• Configuration des bases source et cible : configurer un slot de réplication et définir wal_level sur logical.

Choisir une méthode de réplication des tables

Réplication des « petites » tables

• Réplication des petites tables : possible via un simple add et un rafraîchissement de l'abonnement.

Grandes tables en ajout uniquement

• Réplication des tables en ajout uniquement : définir l'option copy_data sur false pour ne répliquer que les changements futurs, puis backfiller les données antérieures à partir d'une sauvegarde.

Grandes tables avec de nombreuses mises à jour

• Réplication des grandes tables très mises à jour : réduire la taille de la table, exécuter VACUUM et envisager le partitionnement de la table.

Vérification de l'état de réplication des tables

• Supervision de l'état de la réplication : vérifier l'état de réplication via la table système pg_subscription_rel, et il est recommandé de répliquer une seule table à la fois.

Arrêt de la réplication

• Méthode d'arrêt de la réplication : si nécessaire, il est possible d'arrêter la réplication d'une table et de revenir en arrière en rafraîchissant l'abonnement.

Attention au transfert des slots de réplication

• Problème lié au transfert des slots de réplication : le LSN d'un slot de réplication est propre à la base de données principale, il ne peut donc pas être copié directement vers une nouvelle base de données.

Finaliser la migration

• Validation de la cohérence des tables : vérifier que le nombre de lignes des tables correspond entre les deux bases de données et, si nécessaire, valider la cohérence des données par échantillonnage aléatoire.

Modifications au niveau applicatif

• Modification des connexions à la base de données : modifier l'application pour qu'elle se connecte à la nouvelle base de données et établir une stratégie de bascule du trafic.

Point complémentaire sur les séquences

• Synchronisation des séquences : comme les valeurs de séquence ne sont pas synchronisées pendant la réplication, il faut les définir manuellement.

Checklist de vérification finale

• Vérification finale : cohérence des tables, état de l'abonnement, correspondance du schéma, taille de la base de données, ajout de réplicas, reconstruction des index, tests de performance, évaluation des risques et répétition en environnement de staging.

Bascule finale

• Exécution de la bascule finale : répliquer les tables en soirée, répéter plusieurs fois en environnement de staging, puis effectuer la vérification finale et basculer le flag.

L'avis de GN⁺

• Importance : Knock a mené avec succès le processus complexe de mise à niveau de Postgres de 11.9 à 15.3 sans interruption, marquant une étape importante pour l'administration des bases de données et la disponibilité du service.
• Intérêt : l'approche de mise à niveau basée sur la réplication permet aux administrateurs de bases de données d'effectuer une transition en douceur vers une nouvelle base, ce qui peut susciter un fort intérêt dans la communauté technique.
• Aspect remarquable : le processus de mise à niveau de Knock montre un excellent exemple de gestion structurée des risques et de résolution de problèmes pour surmonter des défis techniques complexes.

[GN⁺]

Commentaires sur Hacker News

• Il existe une meilleure méthode que de copier de très grosses tables.

  • On peut créer un slot de réplication, obtenir un snapshot, restaurer ce snapshot sur une nouvelle instance, faire avancer le LSN, puis démarrer la réplication pour créer une réplique logique.
  • Un article d'Instacart décrit ce processus.
  • L'article comporte peut-être une petite erreur, mais cette méthode a été utilisée avec succès à plusieurs reprises pour mettre à niveau des instances de taille TB.

• L'approche présentée ici est intéressante et bien documentée, mais il n'est pas d'accord avec la phrase « les clients modernes attendent une disponibilité à 100 % ».

  • D'après son expérience comme client ou fournisseur, la cohérence est bien plus importante que la disponibilité.
  • Quand un éditeur annonce une période d'indisponibilité, il y voit un signe rassurant qu'il traite les données avec soin.

• AWS prend désormais en charge les déploiements blue-green.

• Il a écrit un outil qui automatise la plupart des problèmes.

  • L'outil est partagé sur GitHub et peut être enrichi grâce aux retours ou aux idées.

• Chez hava.io, ils sont en train de migrer d'AWS RDS PostgreSQL 11.13 vers 15.5.

  • Ils ont choisi une réplication unidirectionnelle avec pglogical.
  • Cette méthode n'est pas rapide, mais elle permet de répliquer progressivement la base de données vers la nouvelle instance, ce qui peut prendre plusieurs jours.
  • Elle offre davantage de liberté pour modifier le type et la taille du stockage.

• Il remet en question l'idée qu'aucune indisponibilité ne soit acceptable pour le service Knock.

  • Les systèmes complexes connaissent des incidents et des temps d'arrêt.
  • Une indisponibilité annoncée à l'avance de 15 minutes ne pose pas de problème à la plupart des activités SaaS.
  • Investir du temps d'ingénierie dans le développement produit ou dans l'amélioration de la vitesse de l'équipe de développement pourrait apporter davantage de satisfaction aux utilisateurs.
  • Dans les migrations de bases de données, l'écart de charge de travail entre une migration « avec peu d'indisponibilité » et une migration « sans aucune indisponibilité » est important.

• Il se dit surpris qu'on ne puisse pas initialiser la réplication à partir d'une sauvegarde.

  • Cela aurait permis d'éviter la contrainte de devoir streamer le contenu déjà stable de la DB vers le nouveau serveur.
  • On parle de « zéro indisponibilité », mais en pratique il y a quand même quelques secondes d'arrêt au moment du basculement vers le nouveau serveur.
  • Il manque des détails sur la manière de préserver la cohérence.
  • Il n'est pas fait mention d'une option de rollback, alors que lorsqu'on effectue une opération ponctuelle de migration sur un grand volume de données, il faut toujours prévoir un plan de retour en arrière.

• Il demande s'il y aurait de l'intérêt pour un outil tout-en-un capable d'effectuer une mise à jour de Postgres sans indisponibilité en ne saisissant que les identifiants de la base de données.

• Le sujet de l'utilisation des séquences lui paraît intéressant.

  • Au lieu des séquences, il utilise principalement des UUID séquentiels ou l'algorithme HiLo.

• Il plaisante en disant que les problèmes qui surviennent dans les systèmes distribués peuvent être résolus avec un simple sleep(1000).

  • Postgres n'est pas un système très familier pour les DBA, mais la situation s'est améliorée par rapport à avant.