Cette page a été traduite par l'API Cloud Translation.

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. Elle explique également 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 Créer un cluster et son instance principale.

Compatibilité entre les clusters et la version 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 définie sur 16.

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é 16, AlloyDB maintient les serveurs de base de données à jour avec la dernière version mineure de 16.

Toutefois, une mise à niveau de version majeure de PostgreSQL nécessite que vous planifiiez, 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 à l'aide d'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 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 transfèrent 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 perte de données 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 que l'application utilise le nouveau cluster.
Vous pouvez vous attendre à un temps d'arrêt d'environ 20 minutes ou plus pendant le processus de mise à niveau, en fonction de votre schéma. Une fois la mise à niveau effectuée, 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 autres entités.	Database Migration Service migre automatiquement toutes les bases de données présentes dans vos instances, ainsi que 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.	Pour la migration, Database Migration Service vous demande de désactiver le mode d'application SSL sur le cluster source.

La section suivante décrit en détail 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

Cela permet une mise à niveau fluide 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ées 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 :

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 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 d'indicateurs du cluster actuel.
4. Activez les extensions dont vos applications ont besoin.
Exportez vos données de l'ancien cluster dans des fichiers à l'aide de psql ou pg_dump.
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 transférer des données de bases de données PostgreSQL vers des clusters AlloyDB. Database Migration Service ne fournit pas de configuration spécifiquement dédiée aux sources de données AlloyDB, mais AlloyDB est compatible avec PostgreSQL. Vous pouvez donc utiliser la configuration prévue pour les sources PostgreSQL génériques.

Ce chemin de migration n'est pas une mise à niveau sur place et entraîne la création d'un nouveau cluster avec une adresse IP différente. Nous vous recommandons de cloner votre cluster et d'effectuer une migration 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 correspond à 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'instances ni de demandes 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 pour les migrations de PostgreSQL vers AlloyDB s'appliquent à ce scénario. Pour obtenir la liste complète des autres limites, consultez la section Limitations connues de 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 Database Migration Service.

Indisponibilité et verrouillage de la base de données source

Database Migration Service utilise des migrations continues pour transférer des données vers des clusters AlloyDB. Ce type de migration entraîne un bref verrouillage (moins de 10 secondes) des 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 basculer votre application vers le nouveau cluster. Cette procédure nécessite un certain temps d'arrêt. Pour obtenir une présentation plus détaillée, consultez Migrations continues dans la documentation Database Migration Service.

Limites de la réplication

Une fois le job de migration passé à 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. Toute action CREATE, UPDATE ou DELETE effectuée sur des tables sans clé primaire pendant la phase CDC doit être recréée manuellement dans la base de données de destination pour éviter toute perte de données.

Avant de commencer

Enable the Database Migration Service API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API

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 tous les rôles supplémentaires.
7. Cliquez sur Enregistrer.
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.
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 les 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`	Ce flag définit le nombre maximal d'emplacements de réplication que l'instance source peut accepter. La valeur minimale de 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 : Votre source ne contient pas d'instances répliquées avec accès en lecture. 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 tables. Dans ce cas, le nombre de `max_replication_slots` doit être au moins égal à `70`, calculé comme suit : `30 * 2 + 10 + 0`.
`max_wal_senders`	Définissez cette option sur une valeur au moins égale à 10 de plus que 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 au moins égal à `82` (calculé comme `70 + 10 + 2 = 82`).
`max_worker_processes`	Définissez cette option sur un nombre au moins égal à 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 nœud de calcul, définissez ce flag 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 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.
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 la base de données que vous avez préparé dans la section Avant de commencer.
Connectez-vous à chaque autre base 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éta-commande \list.
- Vous pouvez passer à une autre base de données sans réinitialiser la connexion de votre client psql à l'aide de la commande \connect {database_name_here}.
Répétez cette procédure pour chaque instance de votre cluster AlloyDB source.

Exécuter la migration dans Database Migration Service