Migration d’une base de données PostgreSQL terminée avec 11 secondes d’indisponibilité

Comment migrer une base de données PostgreSQL

• GOV.UK Notify est en train de déplacer toute son infrastructure vers son propre compte AWS, car le PaaS actuellement utilisé est abandonné.
• Cet article explique comment l’équipe a migré une base de données PostgreSQL avec un minimum d’indisponibilité.

Migration de la base de données

• L’équipe utilise une base de données AWS RDS PostgreSQL fournie par le PaaS et doit la transférer vers une nouvelle base de données dans son propre compte AWS.
• Le principal défi consiste à configurer une nouvelle base de données PostgreSQL et à faire en sorte que toutes les applications communiquent avec elle.

Informations complémentaires sur la base de données source

• La base de données source pèse environ 400 Go et contient 130 millions de lignes, 85 tables, 185 index et 120 clés étrangères.
• En semaine, elle enregistre environ 1 000 insertions ou mises à jour par seconde, et GOV.UK Notify envoie chaque jour des millions de notifications importantes et urgentes.

AWS Database Migration Service

• L’équipe utilise AWS Database Migration Service (DMS) pour transférer les données de la base source vers la base cible.
• DMS copie toutes les données jusqu’à un instant donné via une tâche de « full load » et, en mode réplication, veille à ce que toutes les nouvelles transactions de la base source soient répercutées sur la base cible.

Processus de migration de la base de données

Configuration de l’instance DMS

• Une instance DMS est créée dans le compte AWS source, avec des identifiants PostgreSQL lui donnant accès à la fois à la base source et à la base cible.

Configuration de la base cible

• Une instance RDS cible est créée dans leur propre compte AWS, avec une mise à niveau vers PostgreSQL 15.
• Le schéma de la base source est exporté avec pg_dump, puis les déclarations de tables sont appliquées à la base cible.

Full load

• Une fois les tables créées dans la base cible, la tâche DMS de full load est lancée et se termine en environ 6 heures.
• Une fois cette étape terminée, les index et les contraintes de clés sont ajoutés.

Réplication

• Après la fin du full load, une tâche de réplication continue DMS (capture des changements de données) est démarrée afin de synchroniser la base source et la base cible.

Préparation de la migration du trafic

• L’équipe planifie le processus permettant aux applications d’arrêter de communiquer avec la base source pour passer à la base cible.

Arrêt du trafic vers la base source

• Un script est utilisé pour interrompre tout le trafic vers la base de données source.

Vérification de la réplication

• L’équipe vérifie que la base cible est complètement synchronisée.

Bascule fluide du trafic

• Les applications reçoivent via des variables d’environnement l’emplacement, le nom d’utilisateur et le mot de passe nécessaires pour se connecter à la base, et le changement de base s’effectue rapidement via une modification DNS.

Ce qui s’est passé le jour de la migration

• Le script de migration a été exécuté avec succès, permettant aux applications d’arrêter de communiquer avec la base source pour utiliser la nouvelle base cible.
• Une courte indisponibilité d’environ 11 secondes s’est produite pendant la migration.

Enseignements tirés

• L’équipe a choisi DMS parce qu’il était bien pris en charge sur GOV.UK PaaS et qu’elle pouvait également bénéficier du support d’AWS.
• Si elle devait refaire une migration de base de données entre instances PostgreSQL à l’avenir, elle investirait davantage de temps dans l’essai d’autres outils comme pglogical.

Prochaine étape de la migration de GOV.UK Notify vers AWS

• Une fois la migration de la base de données terminée, l’équipe prévoit de déplacer l’application vers AWS Elastic Container Service (ECS).

Opinion de GN⁺ :

• Le point le plus important de cet article est que l’équipe de GOV.UK Notify a réussi à migrer sa base de données PostgreSQL à l’aide d’AWS Database Migration Service (DMS).
• L’article fournit des indications utiles, fondées sur un cas réel, pour les professionnels techniques qui planifient une migration de base de données.
• Il offre des éclairages sur les moyens de minimiser l’indisponibilité pendant la migration et sur les stratégies permettant de préserver la cohérence des données, ce qui peut aider d’autres organisations ou personnes confrontées à une situation similaire.

[GN⁺]

Avis sur Hacker News

• Quelqu’un remet en question l’usage d’AWS par les administrations, en avançant que la mise en place d’un cloud public ou une approche on-prem pourrait réduire le gaspillage d’argent public à long terme.

  « Je m’interroge sur l’utilisation d’AWS par les administrations. Mettre en place un cloud public ou adopter une approche on-prem pourrait permettre d’économiser l’argent du contribuable à long terme. »

• Une personne partage son expérience d’une migration de base de données réussie avec environ 20 secondes d’interruption grâce au déploiement blue-green d’AWS RDS.

  « Retour d’expérience sur une migration de base de données réussie avec environ 20 secondes d’interruption via le déploiement blue-green d’AWS RDS. »

• Différentes méthodes pour suspendre temporairement les requêtes PostgreSQL sont évoquées, avec l’idée de réduire l’interruption en retardant les requêtes jusqu’à ce que la réplication rattrape son retard.

  « Il est possible de réduire l’interruption en suspendant les requêtes PostgreSQL jusqu’à ce que la réplication ait rattrapé son retard. »

• Une personne décrit la migration d’une base PostgreSQL auto-hébergée de la version 12 à 16 et indique qu’un problème imprévu a entraîné environ 30 minutes d’interruption.

  « Lors de la migration d’une base PostgreSQL de la version 12 à 16, un problème imprévu a provoqué environ 30 minutes d’interruption. »

• Quelqu’un explique qu’accepter 11 secondes d’interruption en utilisant AWS Database Migration Service et en remplaçant une entrée DNS permet d’éviter davantage de complexité.

  « Utiliser AWS Database Migration Service et remplacer une entrée DNS en acceptant 11 secondes d’interruption est une manière d’éviter une complexité supplémentaire. »

• Il est souligné que les requêtes très longues sont l’ennemi des migrations à faible interruption, avec des difficultés particulières pour les gérer.

  « Les requêtes à très longue durée d’exécution compliquent fortement les migrations à faible interruption. »

• Une personne partage son processus de migration de PostgreSQL 14 vers 16 et indique que, la prochaine fois, elle prévoit d’utiliser le déploiement blue-green d’AWS pour éviter l’interruption.

  « Partage d’un processus de migration de PostgreSQL 14 vers 16, avec l’intention d’utiliser la prochaine fois le déploiement blue-green d’AWS pour éviter l’interruption. »

• Il est expliqué comment un script de migration de base de données met à jour le poids des enregistrements DNS dans AWS Route53, puis attend l’expiration d’un TTL d’une seconde.

  « Description d’une méthode où un script de migration met à jour le poids des enregistrements DNS dans AWS Route53, puis attend l’expiration d’un TTL d’une seconde. »

• Quelqu’un plaisante en disant qu’il attend qu’Amazon lance un produit « government-as-a-service ».

  « Plaisanterie sur l’attente d’un produit “government-as-a-service” lancé par Amazon. »

• Une personne partage son expérience de migration d’un jeu de données d’AWS RDS MySQL vers RDS PostgreSQL avec AWS DMS, et déconseille l’utilisation de l’outil de conversion de schéma.

  « Retour d’expérience sur une migration d’un jeu de données d’AWS RDS MySQL vers RDS PostgreSQL avec AWS DMS, avec une recommandation de ne pas utiliser l’outil de conversion de schéma. »