Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

La mise à niveau de votre cluster AlloyDB pour PostgreSQL vers une version majeure ultérieure de PostgreSQL vous permet d'utiliser les dernières fonctionnalités de base de données, les améliorations de performances et les mises à jour de sécurité. Vous pouvez mettre à niveau la version majeure d'un cluster sur place ou en migrant vos données vers un cluster qui exécute une version ultérieure de PostgreSQL.

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

Compatibilité des clusters et des versions de 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 17.

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

Toutefois, une mise à niveau de version majeure de PostgreSQL nécessite que vous planifiez, testiez et effectuiez vous-même la mise à niveau.

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

Une mise à niveau de version majeure sur place, que nous vous recommandons d'utiliser.
Migrer les données avec une exportation de données basée sur des fichiers.
Utiliser Database Migration Service

Chaque solution de mise à niveau présente des avantages et des inconvénients différents. Consultez le tableau suivant pour obtenir une brève comparaison 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 subit 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 basculer l'application pour utiliser le nouveau cluster.
Vous pouvez vous attendre à une indisponibilité d'environ 20 minutes ou plus pendant le processus de mise à niveau, en fonction de votre schéma. Après la mise à niveau, vous pouvez accéder au cluster avec la même adresse IP.	Vous disposez d'un contrôle plus précis sur les données à inclure dans votre exportation et pouvez 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.	Le mode d'application SSL peut être activé sur votre cluster.	Pour la migration, Database Migration Service nécessite que vous désactiviez le mode d'application SSL sur le cluster source.

La section suivante détaille le processus de mise à niveau d'une version majeure, y compris la migration de vos données.

Mise à niveau de version majeure sur place

Une mise à niveau sur place met à jour votre cluster existant sans que vous ayez à 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 plus récente 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 :

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.
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 un numéro de version majeure de PostgreSQL. AlloyDB applique la version PostgreSQL du cluster principal à tous ses clusters secondaires.
3. Mettez à jour les options de base de données du nouveau cluster pour qu'elles correspondent aux paramètres d'options du cluster actuel.
4. Activez les extensions dont vos applications ont besoin.
Exportez les données de l'ancien cluster vers des fichiers à l'aide de psql ou pg_dump.
Importez les données des fichiers dans le nouveau cluster.

Vos applications peuvent 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 processus de migration n'est pas une mise à niveau sur place et entraîne la création d'un 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 préparer la migration avec Database Migration Service, tenez compte des limites suivantes pour vous assurer que ce chemin de migration correspond à votre scénario de mise à niveau.

Limites

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 du job de migration.
Toutes les limites standards des migrations de PostgreSQL vers AlloyDB s'appliquent à ce scénario. Pour obtenir la liste complète des autres limites, consultez Limites connues dans la documentation Database Migration Service.

Fidélité des migrations

Certains types de données, tels que les objets volumineux, ne sont pas migrés. Pour obtenir la liste complète des données compatibles, consultez 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 court verrouillage (moins de 10 secondes) sur les tables de la base de données source, une par une, 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 basculer votre application vers le nouveau cluster. Cette procédure nécessite un certain temps d'arrêt. Pour en savoir plus, consultez Migrations continues dans la documentation de Database Migration Service.

Limites de la réplication

Une fois que le job de migration passe à la phase de capture de données modifiées (CDC), 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 CDC doivent être recréées manuellement sur la base de données de destination pour éviter toute perte de données.

Avant de commencer

Activez l'API Database Migration Service si ce n'est pas déjà fait.
Rôles requis pour activer les API
Pour activer des API, vous devez disposer de l'autorisation serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation via le rôle Propriétaire (roles/owner). Sinon, vous pouvez l'obtenir via le rôle Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin). Découvrez comment attribuer des rôles.
Activer l'API

Assurez-vous de disposer des rôles suivants sur le projet :
- Choisissez l'une des options suivantes :
  - AlloyDB > Administrateur AlloyDB
  - Standard > Propriétaire
  - Standard > Éditeur
- Vous devez également disposer de l'autorisation compute.networks.list dans le projet Google Cloud que vous utilisez. Pour obtenir cette autorisation tout en respectant le principe du moindre privilège, demandez à votre administrateur de vous accorder le rôle Compute Engine > Utilisateur de réseau Compute (roles/compute.networkUser).
- Administrateur de migration de bases de données
Vérifier les rôles
1. Dans la console Google Cloud , accédez à la page IAM.
  Accéder à IAM
2. Sélectionnez le projet.
3. Dans la colonne Compte principal, recherchez toutes les lignes qui vous identifient ou identifient un groupe dont vous faites partie. Pour savoir à quels groupes vous appartenez, contactez votre administrateur.
4. Pour toutes les lignes qui vous spécifient ou vous incluent, consultez la colonne Rôle pour vous assurer que la liste inclut les rôles requis.
Attribuer les rôles
1. Dans la console Google Cloud , accédez à la page IAM.
  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. Cliquez sur Sélectionner un rôle, puis recherchez le rôle.
6. Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et ajoutez tous les rôles supplémentaires.
7. Cliquez sur Enregistrer.
Assurez-vous que le réseau cloud privé virtuel (VPC) du projet Google Cloud que vous utilisez est configuré pour l'accès aux services privés à AlloyDB.
Choisissez la région dans laquelle 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.
Préparez un utilisateur de base de données que vous souhaitez connecter à votre cluster et exécutez 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 :

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`	Cette option définit le nombre maximal d'emplacements de réplication que l'instance source peut accepter. La valeur minimale de cette option 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 that you use for your read replicas)` Prenons l'exemple suivant : Vous n'avez pas d'instances répliquées avec accès en lecture dans votre source. Vous disposez de 30 bases de données sur l'instance source principale. Vous souhaitez créer deux jobs de migration pour le cluster source. Vous souhaitez utiliser 10 emplacements pour la réplication de table. 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 supérieure d'au moins 10 à la valeur `max_replication_slots`, plus le nombre d'expéditeurs déjà utilisés sur votre instance. Par exemple, si vous définissez l'option `max_replication_slots` 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 ce flag sur une valeur au moins égale à la somme du nombre de bases de données de votre instance et du nombre de `max_worker_processes` que vous utilisez déjà. Par exemple, si vous avez 30 bases de données sur votre instance source et que vous n'utilisez aucun processus de calcul, définissez cette option sur `30`.

Désactivez le mode d'application 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 :

Connectez-vous à la base de données postgres par défaut à l'aide du client psql.
Installez l'extension pglogical en exécutant la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
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 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étacommande \dn.
Accordez les autres autorisations 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 base de données que vous avez préparé dans la section Avant de commencer.
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.
Répétez cette procédure pour chaque instance de votre cluster AlloyDB source.

Exécuter la migration dans Database Migration Service