Mettre à niveau la version majeure du serveur d'un cluster

Cette page décrit le processus AlloyDB pour PostgreSQL permettant de mettre à jour les versions du serveur de base de données et explique comment migrer vos données vers un cluster compatible avec une version ultérieure de PostgreSQL.

Pour en savoir plus sur la création d'un cluster, consultez la section Créer un cluster et son instance principale.

Compatibilité des clusters et des versions PostgreSQL

Lorsque vous créez un cluster AlloyDB, vous choisissez la version majeure de PostgreSQL compatible avec les instances du cluster. Par défaut, cette valeur est de 15.

AlloyDB effectue des mises à niveau automatiques de versions mineures de la base de données lors de la maintenance périodique. Par exemple, si vous avez créé un cluster avec une compatibilité 15, AlloyDB maintient la mise à niveau des serveurs de base de données vers la dernière version mineure de 15.

Toutefois, une mise à niveau majeure de la version PostgreSQL vous oblige à planifier, tester et effectuer la mise à niveau vous-même.

Il existe plusieurs méthodes pour effectuer des mises à niveau majeures de votre cluster:

  1. Nous vous recommandons d'effectuer une mise à niveau de version majeure sur place.
  2. Migrer les données à l'aide d'une exportation de données basée sur des fichiers
  3. À l'aide de Database Migration Service

Chaque solution de migration présente des avantages et des inconvénients différents. Consultez le tableau suivant pour obtenir un bref comparatif qui vous aidera à choisir l'approche adaptée à votre scénario.

Mise à niveau de version majeure sur place Exportation de données basée sur des fichiers Migration avec Database Migration Service
Votre cluster, y compris les instances de lecture, est mis à niveau vers la version majeure supérieure choisie. Les exportations basées sur des fichiers déplacent un instantané ponctuel de vos bases de données. Database Migration Service offre des fonctionnalités de réplication continue pendant le processus de migration, ce qui réduit le risque de données manquantes dans votre nouveau cluster.
Vous pouvez continuer à travailler sur votre cluster pendant la phase de prémise à niveau. Votre application connaît un temps d'arrêt plus long qui commence lorsque vous exportez les données. Vous ne pouvez pas accepter les écritures de base de données dans votre cluster d'origine tant que le nouveau cluster n'est pas entièrement opérationnel. Votre application subit un temps d'arrêt plus court qui commence lorsque vous souhaitez la faire passer au nouveau cluster.
Selon votre schéma, le temps d'arrêt pendant le processus de mise à niveau peut être d'environ 20 minutes ou plus. Après la mise à niveau, vous pouvez accéder au cluster avec la même adresse IP. Vous pouvez contrôler plus précisément les données à inclure dans votre exportation et choisir de ne pas migrer certaines tables ou d'autres entités. Database Migration Service migre automatiquement toutes les bases de données présentes dans vos instances et toutes les instances de votre cluster. Vous ne pouvez pas choisir d'exclure certaines tables ou vues de vos données de migration.
Le mode d'application SSL peut être activé sur votre cluster. À des fins de migration, Database Migration Service nécessite que vous désactiviez le mode d'application SSL sur le cluster source.


La section suivante décrit la procédure de mise à niveau d'une version majeure, y compris la migration de vos données.

Mise à niveau de version majeure sur place

Vous bénéficiez ainsi d'une expérience de migration fluide, sans avoir à configurer de clusters supplémentaires. Pour en savoir plus, consultez Mettre à niveau la version majeure d'une base de données sur place.

Migrer à l'aide de l'exportation de données basée sur des fichiers

Pour utiliser un serveur de base de données compatible avec une version majeure supérieure de PostgreSQL, vous devez créer un cluster fonctionnellement identique dans la même région, puis y migrer vos données.

Procédez comme suit :

  1. Créez un cluster configuré avec la version majeure de compatibilité PostgreSQL que vous souhaitez utiliser. Créez le cluster dans la même région que votre cluster actuel.

  2. Configurez le nouveau cluster avec la nouvelle version majeure pour qu'il corresponde à la configuration du cluster actuel:

    1. Créez des instances de pool de lecture supplémentaires si nécessaire.

    2. Créez des clusters secondaires si nécessaire.

      Lorsque vous créez des clusters secondaires, vous n'avez pas besoin de spécifier de numéro de version majeure PostgreSQL. AlloyDB applique la version PostgreSQL du cluster principal à tous ses clusters secondaires.

    3. Mettez à jour les indicateurs de base de données du nouveau cluster pour qu'ils correspondent aux paramètres des indicateurs du cluster actuel.

    4. Activez toutes les extensions dont vos applications ont besoin.

  3. Exportez vos données de l'ancien cluster vers des fichiers à l'aide de psql ou pg_dump.

  4. Importez vos données à partir des fichiers dans le nouveau cluster.

Vos applications peuvent désormais se connecter aux instances du nouveau cluster à leurs nouvelles adresses IP.

Migrer à l'aide de Database Migration Service

Vous pouvez utiliser Database Migration Service pour déplacer des données de bases de données PostgreSQL vers des clusters AlloyDB. Database Migration Service ne fournit pas de configuration dédiée spécifiquement aux sources de données AlloyDB, mais AlloyDB est compatible avec PostgreSQL. Vous pouvez donc utiliser la configuration destinée aux sources PostgreSQL génériques.

Ce chemin de migration n'est pas une mise à niveau in situ et entraîne la création d'un nouveau cluster avec une adresse IP différente. Nous vous recommandons de commencer par cloner votre cluster et d'effectuer une migration de test pour vérifier si votre application est compatible avec cette approche.

Remarques importantes

Avant de vous préparer à migrer avec Database Migration Service, examinez attentivement les limites suivantes pour vous assurer que ce chemin de migration convient à votre scénario de mise à niveau.

Limites
  • Les connexions SSL doivent être désactivées sur votre cluster source.
  • Les instances AlloyDB configurées avec Private Service Connect ne sont pas compatibles.
  • Vous ne pouvez pas effectuer de mises à jour d'instance ni de requêtes de basculement sur le cluster source pendant la migration. Ces opérations peuvent entraîner l'échec de la tâche de migration.
  • Toutes les limites standards pour les migrations de PostgreSQL vers AlloyDB s'appliquent à ce scénario. Pour obtenir la liste complète des autres limites, consultez la section Limites connues de la documentation de Database Migration Service.
Fidélité des migrations
Certains types de données, tels que les grands objets, ne sont pas migrés. Pour obtenir la liste complète des données compatibles, consultez la section Fidélité de la migration dans la documentation de Database Migration Service.
Verrouillage et temps d'arrêt de la base de données source

Database Migration Service utilise des migrations continues pour déplacer des données vers des clusters AlloyDB. Ce type de migration entraîne un verrouillage court (moins de 10 secondes) sur les tables de la base de données source, une à la fois, lors de la création du vidage de données initial.

Une fois la migration terminée, vous devez arrêter toutes les écritures sur la base de données source avant de pouvoir migrer votre application vers le nouveau cluster. Cette procédure nécessite un temps d'arrêt. Pour en savoir plus, consultez la section Migrations continues dans la documentation de Database Migration Service.

Limites de réplication

Une fois que le job de migration passe à la phase de capture de données modifiées (CDC, Change Data Capture), Database Migration Service réplique en continu les nouvelles données écrites dans vos bases de données sources.

Pour les tables sans clé primaire, seules les instructions INSERT sont répliquées pendant la phase de CDC. Toutes les actions CREATE, UPDATE ou DELETE effectuées sur des tables qui ne possèdent pas de clés primaires pendant la phase de capture des données modifiées doivent être recréées manuellement dans la base de données de destination pour éviter toute perte de données.

Avant de commencer

  1. Enable the Database Migration Service API.

    Enable the API

  2. Make sure that you have the following role or roles on the project:

    • One of the following:
      • Cloud AlloyDB > Cloud AlloyDB admin
      • Basic > Owner
      • Basic > Editor
    • You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
    • Database Migration admin

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the project.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      Accéder à IAM
    2. Sélectionnez le projet.
    3. Cliquez sur Accorder l'accès.

    4. Dans le champ Nouveaux comptes principaux, saisissez votre identifiant utilisateur. Il s'agit généralement de l'adresse e-mail d'un compte Google.

    5. Dans la liste Sélectionner un rôle, sélectionnez un rôle.
    6. Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et ajoutez chaque rôle supplémentaire.
    7. Cliquez sur Enregistrer.
    8. Assurez-vous que le réseau VPC du projet Google Cloud que vous utilisez est configuré pour l'accès aux services privés à AlloyDB.
    9. Déterminez dans quelle région vous souhaitez créer votre cluster de destination. Toutes les entités Database Migration Service (profils de connexion, jobs de migration) doivent être créées dans la même région que votre cluster de destination.
    10. Préparez un utilisateur de base de données que vous souhaitez connecter à votre cluster et exécuter des instructions de migration sur vos bases de données sources. Cet utilisateur de base de données nécessite un ensemble spécifique d'autorisations et de rôles. Nous vous recommandons de créer un utilisateur de base de données et de le désigner spécifiquement pour effectuer la migration.

    Configurer vos instances sources

    Database Migration Service nécessite une configuration spécifique pour pouvoir se connecter et copier les données de votre cluster source vers le nouveau cluster de destination.

    Pour configurer vos instances sources AlloyDB, procédez comme suit:

    1. Configurez des indicateurs de base de données sur chaque instance de votre cluster source. Utilisez les valeurs suivantes :
      Option Valeur
      alloydb.logical_decoding Variable définie sur on.
      alloydb.enable_pglogical Variable définie sur on.
      max_replication_slots Cet indicateur définit le nombre maximal d'emplacements de réplication que l'instance source peut accepter. La valeur minimale pour cet indicateur est 50.

      Calculez la valeur minimale à l'aide de la formule suivante:

      (the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)

      Prenons l'exemple suivant:

      • Vous n'avez pas de réplicas en lecture dans votre source.
      • Vous disposez de 30 bases de données sur l'instance source principale.
      • Vous souhaitez créer deux tâches de migration pour le cluster source.
      • Vous souhaitez utiliser 10 emplacements pour la réplication de tables.
      Dans ce cas, le nombre de max_replication_slots doit être d'au moins 70, calculé comme 30 * 2 + 10 + 0.
      max_wal_senders Définissez cette option sur une valeur d'au moins 10 fois supérieure à la valeur max_replication_slots, plus le nombre d'expéditeurs déjà utilisés sur votre instance.

      Par exemple, si vous définissez max_replication_slots flag sur 70 et que vous utilisez déjà deux expéditeurs, max_wal_senders doit être d'au moins 82 (calculé comme 70 + 10 + 2 = 82).

      max_worker_processes Définissez cet indicateur sur un nombre au moins égal au nombre de bases de données de votre instance, plus le nombre d'max_worker_processes que vous utilisez déjà.

      Par exemple, si vous disposez de 30 bases de données sur votre instance source et que vous n'utilisez aucun processus de travail, définissez cet indicateur sur 30.
    2. Désactivez le mode d'application du protocole SSL sur chaque instance de votre cluster source.

    Configurer vos bases de données sources

    Vous devez installer l'extension pglogical et accorder les autorisations requises à l'utilisateur de base de données que vous désignez comme utilisateur de migration sur chaque base de données de vos instances.

    Pour configurer vos bases de données, procédez comme suit:

    1. Connectez-vous à la base de données postgres par défaut à l'aide du client psql.

    2. Installez l'extension pglogical en exécutant la commande suivante:

      CREATE EXTENSION IF NOT EXISTS pglogical;

    3. Accordez des autorisations à l'utilisateur de la base de données de migration sur tous les schémas à l'exception du schéma information et des schémas dont le nom commence par le préfixe pg_. Exécutez les instructions suivantes:

      GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;

      Remplacez les éléments suivants :

      • SCHEMA_NAME: nom d'un schéma présent dans votre base de données
      • USER_NAME: nom de l'utilisateur de la base de données que vous avez préparé dans la section Avant de commencer

      Répétez cette étape pour chaque schéma de votre base de données à l'exception du schéma information et des schémas dont le nom commence par le préfixe pg_. Vous pouvez lister tous les schémas de base de données à l'aide de la méta-commande \dn.

    4. Accordez les autorisations restantes requises. Exécutez les instructions suivantes:

      GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;

      Remplacez USER_NAME par le nom de l'utilisateur de la base de données que vous avez préparé dans la section Avant de commencer.

    5. Connectez-vous à toutes les autres bases de données de votre instance et répétez les étapes 2, 3 et 4.

      • Vous pouvez lister toutes les bases de données de votre instance à l'aide de la métacommande \list.

      • Vous pouvez passer à une autre base de données sans réinitialiser votre connexion client psql à l'aide de la commande \connect {database_name_here}.

    6. Répétez cette procédure pour chaque instance de votre cluster AlloyDB source.

    Exécuter la migration dans Database Migration Service

    Procédez comme suit :

    1. Créez un profil de connexion source pour votre cluster AlloyDB. Utilisez les valeurs suivantes :

      • Moteur de base de données: sélectionnez PostgreSQL.
      • Hostname/IP (Nom d'hôte/Adresse IP) : utilisez l'adresse IP de l'instance principale de votre cluster.
      • Nom d'utilisateur/mot de passe: saisissez les identifiants de l'utilisateur de la base de données que vous avez préparés dans la section Avant de commencer.
      • Port: saisissez 5432.
      • Région: sélectionnez la région dans laquelle se trouve votre cluster de destination.
      • Type de chiffrement: sélectionnez Aucun.

    2. Créez et exécutez la tâche de migration.

      Vous pouvez créer votre cluster AlloyDB à l'avance ou demander à Database Migration Service de le créer pour vous lors de la configuration du job de migration. Pour en savoir plus, consultez la section Présentation des tâches de migration dans la documentation de Database Migration Service.

      Si vous souhaitez que Database Migration Service crée le cluster de destination pour vous lors de la configuration du job de migration, suivez la procédure Créer un job de migration vers une nouvelle instance de destination.

      Si vous souhaitez créer le cluster de destination en dehors de Database Migration Service, suivez la procédure Créer un job de migration vers une instance de destination existante.

    3. Lorsque l'état de votre tâche de migration passe à CDC, promuvez la tâche de migration. Vous pouvez vérifier l'état de la tâche de migration sur la page "Vue d'ensemble de la migration". Consultez la section Examiner une tâche de migration dans la documentation de Database Migration Service.

      Cette action fait sortir votre cluster de destination du mode de démarrage (c'est-à-dire que votre cluster AlloyDB de destination n'est plus en lecture seule).

    4. (Facultatif) Recherchez les instructions manquantes dans les tables sans clé primaire.

      Si vos bases de données AlloyDB sources contiennent des tables sans clé primaire, vous devrez peut-être migrer manuellement les instructions UPDATE ou DELETE manquantes. Consultez la section Migrer les opérations UPDATE et DELETE pour les tables sans clé primaire dans la documentation de Database Migration Service.

    5. Déplacez votre application vers le nouveau cluster. Vos applications peuvent désormais se connecter aux instances du nouveau cluster à leurs nouvelles adresses IP.