Migrer hors connexion, à partir d’un SQL Google Cloud pour PostgreSQL vers Azure Database pour PostgreSQL, avec le service de migration

Cet article vous guide dans la migration d’une instance Google Cloud SQL pour PostgreSQL vers un serveur flexible Azure Database pour PostgreSQL en mode hors connexion.

Le service de migration dans Azure Database pour PostgreSQL est un service complètement managé intégré au Portail Azure et à Azure CLI. Il est conçu pour simplifier votre parcours de migration vers le serveur flexible Azure Database pour PostgreSQL.

• Prérequis
• Effectuer la migration
• Surveiller la migration
• Vérifier la migration une fois terminée

Prérequis

Pour achever la migration, vous devez satisfaire les conditions préalables suivantes :

Avant d’entreprendre la migration avec le service Azure Database for PostgreSQL, il est essentiel de respecter les conditions préalables suivantes, spécialement établies pour les scénarios de migration hors ligne.

• Redondance périodique du stockage des sauvegardes
• Configurer la configuration cible
• Configurer la mise en réseau
• Activer les extensions
• Vérifier les paramètres du serveur
• Vérifier les utilisateurs et les rôles
• Désactiver la haute disponibilité (fiabilité) et les répliques en lecture dans la cible

Vérifier la version source

La version du serveur PostgreSQL source doit être au minimum 9.5.

Si la version du serveur PostgreSQL source est inférieure à 9.5, mettez-la à niveau vers la version 9.5 ou ultérieure avant de commencer la migration.

Définir la configuration cible

Avant d’entamer la migration, vous devez configurer une base de données Azure pour PostgreSQL dans Azure.

La référence SKU sélectionnée pour la base de données Azure pour PostgreSQL doit correspondre aux caractéristiques de la base de données source afin d’assurer une compatibilité et des performances conformes aux attentes.

Lors de la migration entre les versions de PostgreSQL (majeures ou mineures), assurez-vous de la compatibilité entre votre base de données et votre application en recherchant dans les notes de publication de potentiels changements cassants.

Définir la configuration réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne. Veillez à ce que le serveur PostgreSQL source puisse communiquer avec le serveur Azure Database for PostgreSQL cible. Les paramètres réseau ci-dessous sont indispensables pour garantir le bon déroulement de la migration.

Pour plus d’informations sur la configuration réseau, consultez le Guide réseau pour le service de migration.

Considérations supplémentaires relatives à la mise en réseau

Pour faciliter la connectivité entre les instances PostgreSQL source et cible, il est essentiel de vérifier et de modifier potentiellement le fichier pg_hba.conf du serveur source. Ce fichier inclut l’authentification du client et doit être configuré pour permettre à la cible PostgreSQL de se connecter à la source. Les modifications apportées au fichier pg_hba.conf nécessitent généralement un redémarrage de l’instance PostgreSQL source pour prendre effet.

Le fichier pg_hba.conf se trouve dans le répertoire de données de l’installation PostgreSQL. Ce fichier doit être vérifié et configuré, si la base de données source est un serveur PostgreSQL local ou un serveur PostgreSQL hébergé sur une machine virtuelle Azure.

Activer les extensions

Pour assurer une migration réussie via le service de migration dans Azure Database for PostgreSQL, il peut être nécessaire d’examiner les extensions de votre instance PostgreSQL source. Les extensions offrent des capacités et des fonctionnalités susceptibles d’être requises par votre application. Veillez à vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

Dans l’instance cible du serveur flexible Azure Database pour PostgreSQL, activez les extensions prises en charge identifiées dans l’instance PostgreSQL source.

Pour plus d’informations, consultez Extensions et modules.

Vérifier les paramètres de serveur

Ces paramètres ne sont pas automatiquement migrés vers l’environnement cible et doivent être configurés manuellement.

• Faire correspondre les valeurs des paramètres du serveur de la base de données PostgreSQL source à Azure Database pour PostgreSQL en accédant à la page paramètres du serveur dans le portail Azure et en mettant à jour manuellement les valeurs en conséquence.

• Enregistrez les modifications du paramètre et redémarrez Azure Database pour PostgreSQL pour appliquer la nouvelle configuration, si nécessaire.

Vérifier les utilisateurs et les rôles

Lors de la migration vers Azure Database pour PostgreSQL, il est essentiel de traiter séparément la migration des utilisateurs et des rôles, car une intervention manuelle est nécessaire :

• Migration manuelle des utilisateurs et des rôles : les utilisateurs et les rôles doivent être migrés manuellement vers Azure Database pour PostgreSQL. Pour faciliter ce processus, vous pouvez utiliser l’utilitaire avec l’indicateur pg_dumpall--globals-only pour exporter des objets globaux, tels que des rôles et des utilisateurs. Exécutez la commande suivante, en remplaçant <<username>> par le nom d’utilisateur réel et <<filename>> par le nom de fichier de sortie souhaité :

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• Restriction sur les rôles de superutilisateur : Azure Database pour PostgreSQL ne prend pas en charge les rôles de superutilisateur. Par conséquent, les privilèges de superutilisateur accordés aux utilisateurs doivent être supprimés avant la migration. Veillez à adapter les permissions et les rôles en conséquence.

En appliquant ces mesures, vous vous assurez que les comptes utilisateurs et les rôles sont transférés correctement vers Azure Database for PostgreSQL sans rencontrer de difficultés liées aux restrictions imposées aux superutilisateurs.

Désactiver la haute disponibilité (fiabilité) et les réplicas de lecture dans la cible

• Il est essentiel de désactiver les réplicas de haute disponibilité (fiabilité) et de lecture dans l’environnement cible. Ces fonctionnalités ne doivent être activées qu’une fois la migration terminée.

• En suivant ces recommandations, vous contribuerez à garantir un processus de migration sans heurts, sans les variables supplémentaires introduites par la haute disponibilité et les réplicas en lecture. Une fois la migration achevée et la base de données stabilisée, vous pouvez activer ces fonctionnalités afin d’améliorer la disponibilité et l’évolutivité de votre environnement de base de données dans Azure.

Effectuer la migration

Vous pouvez migrer à l’aide du portail Azure ou d’Azure CLI.

Portail

Cet article vous guide à l’aide du portail Azure pour migrer votre base de données PostgreSQL à partir d’un serveur Google Cloud SQL pour PostgreSQL vers une base de données Azure pour PostgreSQL. Le portail Azure vous permet d’effectuer différentes tâches, notamment la migration de base de données. En suivant les étapes décrites dans ce tutoriel, vous pouvez transférer en toute transparence votre base de données vers Azure et tirer parti de ses puissantes fonctionnalités et scalabilité.

Configurer la tâche de migration

Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure.

Utilisation du portail Azure :

1. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL.

2. Dans le menu des ressources, sélectionnez Migration.

   

3. Sélectionnez Créer afin de suivre une suite d’onglets pilotés par un assistant pour mener une migration vers un serveur flexible depuis Google Cloud SQL pour PostgreSQL.

   Remarque

   Lors de votre première utilisation du service de migration, une grille vide apparaît, accompagnée d’une invite vous proposant de lancer votre première migration.

   Si des migrations vers votre cible de serveur flexible ont déjà été créées, la grille contient désormais des informations sur les tentatives de migration.

   

Programme d’installation

Vous devez fournir plusieurs détails liés à la migration, comme le nom de la migration, le type de serveur source, l’option et le mode.

• Le nom de la migration est l’identificateur unique de chaque migration vers cette cible de serveur flexible. Ce champ accepte uniquement les caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du trait d’union (-). Le nom ne peut pas commencer par un trait d’union et doit être unique pour un serveur cible. Deux migrations vers la même cible de serveur flexible ne peuvent pas avoir le même nom.

• Type de serveur source : selon votre source PostgreSQL, vous pouvez sélectionner Google Cloud SQL pour PostgreSQL.

• Option de migration : vous permet d’effectuer des validations avant de déclencher une migration. Vous pouvez choisir l’une des options suivantes :

  • Valider – Vérifie que votre serveur et votre base de données sont prêts pour la migration vers la cible.
  • Valider et migrer : effectue la validation avant de déclencher une migration. En l’absence d’échecs de validation, la migration est lancée.

Le choix de l’option Valider ou Valider et migrer est toujours une bonne pratique pour effectuer des validations de prémigration avant d’exécuter la migration.

Pour obtenir davantage d’informations sur la validation précédant la migration, consultez la page premigration.

• Le mode de migration vous permet de choisir le mode de migration. L’option par défaut est « Hors ligne ». Dans ce cas, nous allons utiliser la valeur par défaut.

Sélectionnez Suivant : Serveur d’exécution.

Serveur d’exécution

Le serveur runtime de migration est une fonctionnalité spécialisée dans le service de migration dans Azure Database pour PostgreSQL, conçue pour agir en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance de serveur flexible Azure Database pour PostgreSQL distincte qui n’est pas le serveur cible, mais utilisée pour faciliter la migration des bases de données à partir d’un environnement source accessible uniquement via un réseau privé.

Pour plus d’informations sur le serveur d’exécution, visitez le serveur runtime de migration.

Serveur source

L’onglet Serveur source vous invite à fournir des détails relatifs à la source sélectionnée dans l’onglet Installation , qui est la source des bases de données.

• Nom du serveur : indiquez le nom de l’hôte ou l’adresse IP du serveur PostgreSQL source.
• Port : numéro de port du serveur source.
• Connexion administrateur : nom de l’utilisateur administrateur du serveur PostgreSQL source.
• Mot de passe : mot de passe de la connexion administrateur fournie pour se connecter au serveur PostgreSQL source.
• Mode SSL - Les valeurs prises en charge sont preferred et required. Lorsque le protocole SSL sur le serveur PostgreSQL source est OFF, utilisez prefer. Si le protocole SSL sur le serveur source est ON, utilisez le require. Les valeurs SSL peuvent être déterminées dans le fichier postgresql.conf du serveur source.
• Tester la connexion : effectue le test de connectivité entre la cible et la source. Une fois la connexion établie, vous pouvez passer à l’onglet suivant. Ces tests visent à identifier les problèmes de connectivité qui peuvent exister entre les serveurs cibles et sources, notamment la vérification de l’authentification à l’aide des informations d’identification fournies. L’établissement d’une connexion de test prend quelques secondes.

Une fois la connexion testée réussie, sélectionnez Suivant : Serveur cible.

Serveur cible

L’onglet Serveur cible affiche les métadonnées de la cible de serveur flexible, comme le nom de l’abonnement, le groupe de ressources, le nom du serveur, l’emplacement et la version postgreSQL.

• Connexion administrateur : nom de l’utilisateur administrateur du serveur PostgreSQL cible.
• Mot de passe : mot de passe de la connexion administrateur fournie pour se connecter au serveur PostgreSQL cible.
• Nom de domaine complet personnalisé ou adresse IP : le champ DQDN personnalisé ou adresse IP est facultatif et peut être utilisé lorsque la cible se trouve derrière un serveur DNS personnalisé ou possède des espaces de noms DNS personnalisés, ce qui le rend accessible uniquement via des noms de domaine complets ou des adresses IP spécifiques. Par exemple, cela peut inclure des entrées telles que production-flexible-server.example.com, 198.1.0.2ou un nom de domaine complet PostgreSQL tel que production-flexible-server.postgres.database.azure.com, si le serveur DNS personnalisé contient la zone postgres.database.azure.com DNS ou transfère les requêtes pour cette zone vers 168.63.129.16, où le nom de domaine complet est résolu dans la zone DNS publique ou privée Azure.
• Tester la connexion : effectue le test de connectivité entre la source et la cible. Une fois la connexion établie, vous pouvez passer à l’onglet suivant. Ce test vise à identifier les problèmes de connectivité qui peuvent exister entre les serveurs source et cible, notamment la vérification de l’authentification à l’aide des informations d’identification fournies. L’établissement d’une connexion de test prend quelques secondes.

Une fois la connexion de test réussie, sélectionnez Suivant : Bases de données à valider ou à migrer

Bases de données à valider ou migrer

Sous l’onglet Bases de données à valider ou migrer , vous pouvez choisir une liste de bases de données utilisateur à migrer à partir de votre serveur PostgreSQL source.

Après avoir sélectionné les bases de données, sélectionnez Suivant : Résumé.

Résumé

L’onglet Résumé récapitule toutes les informations de la source et de la cible pour la création de la validation ou de la migration. Passez en revue les détails et sélectionnez Démarrer la validation et la migration.

Annuler la validation ou la migration

Vous pouvez annuler toutes les validations ou migrations en cours. Le flux de travail doit être dans l’état En cours afin qu’il puisse être annulé. Vous ne pouvez pas annuler une validation ou une migration dans l’état Réussi ou Échec .

• L’annulation d’une validation arrête une activité de validation supplémentaire et la validation passe à un état annulé .
• L’annulation d’une migration interrompt toute opération de migration en cours sur votre serveur cible et l’état passe à Annulé. L’action d’annulation retourne toutes les modifications apportées par le service de migration sur votre serveur cible.

CLI

Cet article explore l’utilisation d’Azure CLI pour migrer votre base de données PostgreSQL à partir d’une machine virtuelle Azure ou d’une instance PostgreSQL locale vers une base de données Azure pour PostgreSQL. Azure CLI fournit une interface de ligne de commande puissante et flexible qui vous permet d’effectuer différentes tâches, notamment la migration de base de données. En appliquant les étapes décrites dans cet article, vous pouvez déplacer votre base de données vers Azure en toute fluidité et bénéficier de ses capacités étendues et de son évolutivité.

Pour en savoir davantage sur l’utilisation de l’interface Azure CLI avec le service de migration, consultez Comment configurer l’interface Azure CLI pour le service de migration.

Une fois l’interface Azure CLI installée, ouvrez l’invite de commandes et connectez-vous à votre compte Azure à l’aide de la commande ci-dessous.

az login

Configurer la tâche de migration

Pour commencer la migration, créez un fichier JSON avec les détails de la migration. Le fichier JSON contient les informations suivantes :

• Modifiez les espaces réservés << >> ci-dessous dans les lignes JSON et stockez-les sur l’ordinateur local en tant que <<filename>>.json où l’interface CLI est appelée. Dans ce tutoriel, nous avons enregistré le fichier dans c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "AWS_AURORA",
        "sslMode": "Prefer"
    }
}

• Exécutez la commande suivante pour vérifier si des migrations sont en cours d’exécution. Le nom de la migration est unique dans les migrations au sein du serveur flexible Azure Database pour PostgreSQL cible.

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• Dans les étapes ci-dessus, aucune migration n’est effectuée. Nous commençons donc par la nouvelle migration en exécutant la commande suivante.

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• Exécutez la commande suivante pour afficher l’état de la migration lancée à l’étape précédente. Vous pouvez vérifier l’état de la migration en fournissant le nom de la migration.

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• La progression et l’état de la migration sont affichés dans Azure CLI.

• Vous pouvez également voir la progression et l’état dans le portail Azure.

• Vous pouvez annuler toutes les tentatives de migration en cours à l’aide de la commande cancel. Cette commande arrête la tentative de migration particulière et restaure toutes les modifications qu’il aurait pu apporter sur votre serveur cible. Voici la commande CLI pour annuler la migration qui a un état « En cours ».

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Surveiller la migration

Une fois que vous avez sélectionné le bouton Démarrer la validation et la migration , une notification s’affiche, en quelques secondes, pour indiquer que la création de la validation ou de la migration réussit. Vous êtes automatiquement redirigé vers la page Migration du serveur flexible. L’entrée affiche l’état comme en cours. Le flux de travail prend 2 à 3 minutes pour configurer l’infrastructure de migration et vérifier les connexions réseau.

La grille qui affiche les migrations comporte les colonnes suivantes : Nom, État, Mode Migration, Type de migration, Serveur source, Type de serveur source, Bases de données, Durée et Heure de début. Les entrées sont triées par heure de début dans l’ordre décroissant, avec l’entrée la plus récente en haut. Vous pouvez utiliser le bouton Actualiser dans la barre d’outils pour actualiser l’état de la validation ou de l’exécution de la migration.

Détails de la migration

Sélectionnez le nom de la migration dans la grille pour afficher les informations associées.

N’oubliez pas que lors de la création de cette migration, vous avez configuré l’option de migration en tant que Validation et migration. Dans ce scénario, les validations sont effectuées en premier avant le démarrage de la migration. Une fois le sous-état Effectuer les étapes préalables terminé, le flux de travail passe à l'état de validation en cours.

• Si la validation présente des erreurs, la migration passe à l’état Échec.

• Si la validation est terminée sans erreur, la migration démarre et le flux de travail passe dans la sous-état de migration des données.

Les informations de validation sont accessibles au niveau de l’instance et de la base de données.

• Détails de validation pour l’instance
  • Contient la validation liée à la vérification de la connectivité, à la version source, autrement dit, à la version >PostgreSQL = 9.5 et à la vérification des paramètres de serveur, si les extensions sont activées dans les paramètres de serveur du serveur flexible Azure Database pour PostgreSQL.
• Détails de validation et de migration pour les bases de données
  • Il contient la validation des bases de données individuelles relatives à la prise en charge des extensions et des classements dans un serveur flexible Azure Database pour PostgreSQL.

Vous pouvez voir l’état de validation et l’état de migration dans la page détails de la migration.

Certains états de migration possibles :

État de la migration

Statut	Description
En cours	L’infrastructure de migration est en cours de configuration, ou la migration des données est en cours.
Annulé	La migration est annulée ou supprimée.
Échec	La migration a échoué.
Échec de la validation	La validation a échoué.
Réussi	La migration a réussi et est terminée.

Sous-états de migration

Sous-état	Description
Exécution des étapes requises	L’infrastructure est en cours de configuration pour la migration des données.
Validation en cours	La validation est en cours.
Migration de données	La migration des données est en cours.
Fin de la migration	La migration est en phase finale.
Terminé	La migration est terminée.
Échec	La migration a échoué.

Sous-états de validation

Sous-état	Description
Échec	La validation a échoué.
Réussi	La validation se termine avec succès.
Avertissement	La validation présente un avertissement.

Vérifier la migration une fois terminée

Une fois les bases de données terminées, vous devez valider manuellement les données entre la source et la cible et vérifier que tous les objets de la base de données cible sont correctement créés.

Après la migration, vous pouvez effectuer les tâches suivantes :

• Vérifiez les données sur votre serveur flexible et confirmez qu’elles reproduisent fidèlement celles de l’instance source.

• Après la vérification, activez l’option de haute disponibilité sur votre serveur flexible si nécessaire.

• Changez la référence SKU du serveur flexible en fonction des besoins d’applications. Cette modification nécessite un redémarrage du serveur de base de données.

• Si vous ajustez les paramètres par défaut du serveur dans l’instance source, reportez ces valeurs dans le serveur flexible.

• Reportez les autres paramètres du serveur, tels que les balises, les alertes et les règles de pare-feu (le cas échéant), de l’instance source vers le serveur flexible.

• Modifiez votre application afin que les chaînes de connexion ciblent un serveur flexible.

• Surveillez de près le niveau de performance des bases de données pour déterminer s’il est nécessaire de l’ajuster.

Contenu connexe

• Migrer en ligne depuis Google Cloud SQL pour PostgreSQL
• Service de migration
• Problèmes connus et limitations