Migrer en ligne, à partir d’une machine virtuelle Azure ou d’un serveur PostgreSQL local vers Azure Database pour PostgreSQL, avec le service de migration

Cet article vous montre comment migrer, à l’aide du Portail Azure, votre base de données PostgreSQL à partir d’une machine virtuelle Azure ou d’un serveur PostgreSQL local vers une instance d’Azure Database 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 sa scalabilité et de ses puissantes fonctionnalités.

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 pour suivre une série d'onglets guidée par un assistant afin d'effectuer une migration vers un serveur flexible depuis une machine virtuelle sur site ou Azure.

   Remarque

   La première fois que vous utilisez le service de migration, une grille vide s’affiche avec une invite pour commencer 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. Aucune migration vers la même cible de serveur flexible ne peut avoir le même nom.

• Type de serveur source : selon votre source PostgreSQL, vous pouvez sélectionner une machine virtuelle Azure ou un serveur local.

• 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 la préparation de votre serveur et de votre base de données 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 en savoir plus sur la validation avant migration, consultez la page de prémigration.

• Le mode de migration vous permet de choisir le mode de la migration. Hors connexion est l’option par défaut. Dans ce cas, nous allons le remplacer par Online.

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 pour être annulé. Vous ne pouvez pas annuler une validation ou une migration dans l’état Réussite ou Échec .

L’annulation d’une validation arrête toute activité de validation supplémentaire et la validation passe à un état Annulé .

L’annulation d’une migration arrête l’activité de migration supplémentaire sur votre serveur cible et passe à un état Annulé . Elle n’annule ni ne restaure aucune modification sur votre serveur cible. Veillez à supprimer les bases de données de votre serveur cible impliqué dans une migration annulée.

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 instance d’Azure Database 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 suivant les étapes décrites dans cet article, vous pouvez transférer en toute transparence votre base de données vers Azure et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.

Pour en savoir plus sur Azure CLI avec le service de migration, consultez Guide pratique pour configurer Azure CLI pour le service de migration.

Une fois l’interface 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": "OnPremises",
        "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>
  

Pour l’option Valider et migrer , l’exécution de la migration en ligne nécessite que l’utilisateur effectue une étape supplémentaire, qui consiste à déclencher l’action de basculement. Une fois la copie ou le clonage des données de base terminées, la migration passe à l’état Waiting for user action et au Waiting for cutover trigger sous-état. Dans cet état, l’utilisateur peut déclencher le basculement à partir du portail en sélectionnant la migration.

Avant de lancer le basculement, il est important de s’assurer que :

• Les écritures vers la source sont arrêtées : la valeur de latency est 0 ou proche de 0. Les informations latency peuvent être obtenues à partir de l’écran des détails de la migration, comme indiqué ci-dessous :
• La valeur de latency diminue à 0 ou proche de 0
• La valeur de latency indique quand la cible a été synchronisée pour la dernière fois avec la source. Les écritures vers la source peuvent alors être arrêtées et le basculement peut être lancé. Si le trafic est important au niveau de la source, nous vous recommandons d’arrêter d’abord les écritures afin que latency puisse atteindre une valeur proche de 0, puis de lancer le basculement.

L’opération de basculement applique toutes les modifications en attente du serveur source au serveur cible et termine la migration. Si vous déclenchez une bascule, même avec une valeur latency non nulle, la réplication s'arrête jusqu'à ce moment précis. Toutes les données de la source jusqu’au point de basculement sont ensuite appliquées à la cible. Si vous rencontrez une latence de 15 minutes au point de basculement, toutes les modifications apportées aux données au cours des 15 dernières minutes sont appliquées à la cible.

Le temps nécessaire dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, il est recommandé que la latence passe à zéro ou près de zéro avant de déclencher le basculement.

• La migration passe à l'état Succeeded suivant lorsque le sous-état Migrating data ou la bascule (dans le cas d'une migration en ligne) se termine avec succès. S’il existe un problème au niveau du Migrating data sous-état, la migration passe à un Failed état.

Pour l’option Valider et migrer , l’exécution de la migration en ligne nécessite que l’utilisateur effectue une étape supplémentaire, qui consiste à déclencher l’action de basculement. Une fois la copie ou le clonage des données de base terminées, la migration passe à l’état Waiting for user action et au Waiting for cutover trigger sous-état. Dans cet état, l’utilisateur peut déclencher le basculement via l’interface CLI à l’aide de la commande ci-dessous. Le basculement peut également être déclenché à partir du portail en sélectionnant le nom de la migration dans la grille de migration.

Avant de lancer le basculement, il est important de s’assurer que :

• Les écritures vers la source sont arrêtées : la valeur de latency est 0 ou proche de 0. Les informations latency peuvent être obtenues à partir de l’écran des détails de la migration, comme indiqué ci-dessous :
• La valeur de latency diminue à 0 ou proche de 0
• La valeur de latency indique quand la cible a été synchronisée pour la dernière fois avec la source. Les écritures vers la source peuvent alors être arrêtées et le basculement peut être lancé. Si le trafic est important au niveau de la source, nous vous recommandons d’arrêter d’abord les écritures afin que latency puisse atteindre une valeur proche de 0, puis de lancer le basculement.

L’opération de basculement applique toutes les modifications en attente du serveur source au serveur cible et termine la migration. Si vous déclenchez une bascule, même avec une valeur latency non nulle, la réplication s'arrête jusqu'à ce moment précis. Toutes les données de la source jusqu’au point de basculement sont ensuite appliquées à la cible. Si vous rencontrez une latence de 15 minutes au point de basculement, toutes les modifications apportées aux données au cours des 15 dernières minutes sont appliquées à la cible.

Le temps nécessaire dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, il est recommandé que la latence passe à zéro ou près de zéro avant de déclencher le basculement.

• La migration passe à l'état Succeeded suivant lorsque le sous-état Migrating data ou la bascule (dans le cas d'une migration en ligne) se termine avec succès. S’il existe un problème au niveau du Migrating data sous-état, la migration passe à un Failed état.

Pour déclencher le basculement, utilisez la commande suivante :

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