Migration de votre base de données PostgreSQL au moyen d’une image mémoire et de la restauration
S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible
Vous pouvez utiliser pg_dump pour extraire une base de données PostgreSQL dans un fichier de vidage. La méthode de restauration de la base de données dépend du format d’image mémoire que vous choisissez. Si votre image mémoire est prise avec le format brut (qui est la valeur par défaut -Fp
, donc aucune option spécifique ne doit être spécifiée), la seule option de restauration consiste à utiliser psql, car cela génère un fichier texte brut. Pour les trois autres méthodes d’image mémoire : méthode personnalisée, répertoire et tar, vous devez utiliser pg_restore.
Important
Les instructions et les commandes fournies dans cet article sont conçues pour être exécutées dans les terminaux Bash. Cela inclut des environnements tels que le Sous-système Windows pour Linux (WSL), Azure Cloud Shell et d’autres interfaces compatibles avec Bash. Veuillez vérifier que vous utilisez un terminal Bash pour suivre les étapes, puis exécuter les commandes détaillées dans ce guide. L’utilisation d’un autre type d’environnement de terminal ou d’interpréteur de commandes risque d’entraîner des différences de comportement de commande et de ne pas produire les résultats prévus.
Dans cet article, nous mettons l’accent sur les formats simples (par défaut) et de répertoire. Le format de répertoire est utile, car il vous permet d’utiliser plusieurs cœurs pour le traitement, ce qui peut améliorer considérablement l’efficacité, en particulier pour les bases de données volumineuses.
Le Portail Azure simplifie ce processus via le panneau Connecter en proposant des commandes préconfigurées adaptées à votre serveur, avec des valeurs remplacées par vos données utilisateur. Il est important de noter que le panneau Connecter est disponible uniquement pour le serveur flexible Azure Database pour PostgreSQL et non pour un serveur unique. Voici comment utiliser cette fonctionnalité :
Accéder au Portail Azure : tout d’abord, accédez au Portail Azure, puis choisissez le panneau Connecter.
Sélectionner votre base de données : dans le panneau Connecter, vous trouverez une liste déroulante de vos bases de données. Sélectionnez la base de données depuis laquelle vous souhaitez créer une image mémoire.
Choisir la méthode appropriée : selon la taille de votre base de données, vous pouvez choisir entre deux méthodes :
pg_dump
etpsql
à l’aide d’un fichier texte singulier : idéale pour les bases de données plus petites, cette option utilise un seul fichier texte pour le processus d’image mémoire et de restauration.pg_dump
etpg_restore
à l’aide de plusieurs cœurs : pour les bases de données plus volumineuses, cette méthode est plus efficace, car elle utilise plusieurs cœurs pour gérer le processus d’image mémoire et de restauration.
Copier et coller des commandes : le portail vous fournit les commandes prêtes à l’emploi
pg_dump
etpsql
oupg_restore
. Ces commandes sont fournies avec des valeurs déjà remplacées en fonction du serveur et de la base de données que vous avez choisis. Copiez et collez les commandes suivantes.
Prérequis
Si vous utilisez un serveur unique ou que vous n’avez pas accès au portail Serveur flexible, lisez cette page de documentation. Cette page contient des informations similaires à ce qui est présenté dans le panneau Connecter pour le serveur flexible sur le portail.
Remarque
Étant donné que les utilitaires pg_dump
, psql
, pg_restore
et pg_dumpall
reposent tous sur libpq, vous pouvez utiliser l’une des variables d’environnement prises en charge qu’il offre, ou vous pouvez utiliser le fichier de mot de passe pour éviter d’être invité à entrer le mot de passe chaque fois que vous exécutez l’une de ces commandes.
Pour parcourir ce guide pratique, vous avez besoin des éléments suivants :
- Un serveur Azure Database pour PostgreSQL avec des règles de pare-feu autorisant l’accès.
- pg_dump, psql, pg_restore et pg_dumpall dans le cas où vous souhaitez migrer avec des rôles et des autorisations, des utilitaires de ligne de commande installés.
- Décider de l’emplacement de l’image mémoire : choisissez l’emplacement depuis lequel vous souhaitez effectuer l’image mémoire. Vous pouvez effectuer cette action depuis différents emplacements, tels qu’une machine virtuelle distincte, Cloud Shell (où les utilitaires de ligne de commande sont déjà installés, mais ne sont peut-être pas dans la version appropriée ; vérifiez donc toujours la version à l’aide, par exemple,
psql --version
) ou votre propre ordinateur portable. Gardez toujours à l’esprit la distance et la latence entre le serveur PostgreSQL et l’emplacement depuis lequel vous exécutez l’image mémoire ou la restauration.
Important
Il est essentiel d’utiliser les utilitaires pg_dump
, psql
, pg_restore
et pg_dumpall
qui sont à la même version majeure que le serveur de base de données ou à une version majeure supérieure au serveur de base de données depuis lequel vous exportez des données ou vers lequel vous les importez. Sinon, cela peut entraîner une migration de données infructueuse. Si votre serveur cible a une version majeure supérieure à celle du serveur source, utilisez des utilitaires qui sont soit à la même version majeure, soit à une version majeure supérieure à celle du serveur cible.
Remarque
Il est important de se rappeler que pg_dump
ne peut exporter qu’une seule base de données à la fois. Cette limitation s’applique quelle que soit la méthode que vous avez choisie, qu’il s’agisse d’utiliser un fichier singulier ou plusieurs cœurs.
Image mémoire des utilisateurs et des rôles avec pg_dumpall -r
pg_dump
permet d’extraire une base de données PostgreSQL dans un fichier d’image mémoire. Toutefois, il est essentiel de comprendre que pg_dump
ne vide pas les rôles ou les définitions d’utilisateurs, car ils sont considérés comme des objets globaux dans l’environnement PostgreSQL. Pour une migration complète, y compris des utilisateurs et des rôles, vous devez utiliser pg_dumpall -r
.
Cette commande vous permet de capturer toutes les informations sur les rôles et les utilisateurs depuis votre environnement PostgreSQL. Si vous migrez au sein de bases de données sur le même serveur, n’hésitez pas à ignorer cette étape, puis à passer à la section Créer une base de données.
pg_dumpall -r -h <server name> -U <user name> > roles.sql
Par exemple, si vous avez un serveur nommé mydemoserver
et un utilisateur nommé myuser
, exécutez la commande suivante :
pg_dumpall -r -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql
Si vous utilisez un serveur unique, votre nom d’utilisateur inclut le composant de nom de serveur. Par conséquent, au lieu de myuser
, utilisez myuser@mydemoserver
.
Création d’une image mémoire des rôles depuis un serveur flexible
Dans un environnement de serveur flexible, les mesures de sécurité améliorées signifient que les utilisateurs n’ont pas accès à la table pg_authid, c’est-à-dire à l’emplacement de stockage des mots de passe de rôle. Cette restriction affecte la façon dont vous créez une image mémoire de rôles, car la commande standard pg_dumpall -r
tente d’accéder à cette table pour obtenir les mots de passe et échoue en raison d’un manque d’autorisation.
Lorsque vous créez une image mémoire de rôles depuis un serveur flexible, il est essentiel d’inclure l’option --no-role-passwords
dans votre commande pg_dumpall
. Cette option empêche pg_dumpall
de tenter d’accéder à la table pg_authid
, qu’elle ne peut pas lire en raison de restrictions de sécurité.
Pour créer une image mémoire des rôles depuis un serveur flexible, utilisez la commande suivante :
pg_dumpall -r --no-role-passwords -h <server name> -U <user name> > roles.sql
Par exemple, si vous avez un serveur nommé mydemoserver
et un utilisateur nommé myuser
, exécutez la commande suivante :
pg_dumpall -r --no-role-passwords -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql
Nettoyage de l’image mémoire des rôles
Lors de la migration, le fichier de sortie roles.sql
risque d’inclure certains rôles et attributs qui ne sont pas applicables ou admissibles dans le nouvel environnement. Voici ce que vous devez prendre en compte :
Suppression d’attributs qui ne peuvent être définis que par des superutilisateurs : si vous migrez vers un environnement où vous n’avez pas de privilèges de superutilisateur, supprimez des attributs tels que
NOSUPERUSER
etNOBYPASSRLS
de l’image mémoire des rôles.Exclusion d’utilisateurs spécifiques au service : excluez des utilisateurs de service à serveur unique, tels que
azure_superuser
ouazure_pg_admin
. Ces éléments sont spécifiques au service et seront créés automatiquement dans le nouvel environnement.
Exécutez la commande sed
suivante pour nettoyer vos rôles :
sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql
Cette commande supprime les lignes contenant azure_superuser
, azure_pg_admin
, azuresu
, les lignes commençant par CREATE ROLE replication
et ALTER ROLE replication
, puis supprime les attributs NOSUPERUSER
et NOBYPASSRLS
des instructions ALTER ROLE
.
Création d’un fichier de vidage qui contient les données à charger
Pour exporter votre base de données PostgreSQL existante en local ou dans une machine virtuelle vers un fichier de script sql, exécutez la commande suivante dans votre environnement existant :
- pg_dump et psql : utilisation d’un fichier texte singulier
- pg_dump et pg_restore : utilisation de plusieurs cœurs
pg_dump <database name> -h <server name> -U <user name> > <database name>_dump.sql
Par exemple, si vous avez un serveur nommé mydemoserver
, un utilisateur nommé myuser
et une base de données appelée testdb
, exécutez la commande suivante :
pg_dump testdb -h mydemoserver.postgres.database.azure.com -U myuser > testdb_dump.sql
Si vous utilisez un serveur unique, votre nom d’utilisateur inclut le composant de nom de serveur. Par conséquent, au lieu de myuser
, utilisez myuser@mydemoserver
.
Restaurer les données dans la base de données cible
Restaurer des rôles et des utilisateurs
Avant de restaurer vos objets de base de données, vérifiez que vous avez correctement créé une image mémoire des rôles, puis nettoyé les rôles. Si vous migrez au sein de bases de données sur le même serveur, il se peut que la création d’une image mémoire et la restauration des rôles ne soient pas nécessaires. Toutefois, pour les migrations sur plusieurs serveurs ou environnements, cette étape est cruciale.
Pour restaurer les rôles et les utilisateurs dans la base de données cible, utilisez la commande suivante :
psql -f roles.sql -h <server_name> -U <user_name>
Remplacez <server_name>
par le nom de votre serveur cible et <user_name>
par votre nom d’utilisateur. Cette commande utilise l’utilitaire psql
pour exécuter les commandes SQL contenues dans le fichier roles.sql
, en restaurant réellement les rôles et les utilisateurs dans votre base de données cible.
Par exemple, si vous avez un serveur nommé mydemoserver
et un utilisateur nommé myuser
, exécutez la commande suivante :
psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser
Si vous utilisez un serveur unique, votre nom d’utilisateur inclut le composant de nom de serveur. Par conséquent, au lieu de myuser
, utilisez myuser@mydemoserver
.
Remarque
Si vous avez déjà des utilisateurs portant les mêmes noms sur votre serveur unique ou sur votre serveur local depuis lequel vous migrez, et sur votre serveur cible, sachez que ce processus de restauration risque de modifier les mots de passe de ces rôles. Par conséquent, toutes les commandes suivantes que vous devez exécuter risquent de nécessiter les mots de passe mis à jour. Cela ne s’applique pas si votre serveur source est un serveur flexible, car le serveur flexible n’autorise pas la création d’images mémoires des mots de passe des utilisateurs en raison de mesures de sécurité améliorées.
Créer une base de données
Avant de restaurer votre base de données, vous devrez peut-être créer une base de données vide. Pour ce faire, votre utilisateur doit disposer de l’autorisation CREATEDB
. Voici deux méthodes couramment utilisées :
Utiliser l’utilitaire
createdb
Le programmecreatedb
permet la création de bases de données directement depuis la ligne de commande Bash, sans avoir à se connecter à PostgreSQL ou à quitter l’environnement du système d’exploitation. Exemple :createdb <new database name> -h <server name> -U <user name>
Par exemple, si vous avez un serveur nommé
mydemoserver
, un utilisateur nommémyuser
et que la base de données à créer esttestdb_copy
, exécutez la commande suivante :createdb testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser
Si vous utilisez un serveur unique, votre nom d’utilisateur inclut le composant de nom de serveur. Par conséquent, au lieu de
myuser
, utilisezmyuser@mydemoserver
.Utiliser une commande SQL Pour créer une base de données à l’aide d’une commande SQL, vous devez vous connecter à votre serveur PostgreSQL via une interface de ligne de commande ou un outil de gestion de base de données. Une fois connecté, vous pouvez utiliser la commande SQL suivante pour créer une base de données :
CREATE DATABASE <new database name>;
Remplacez <new database name>
par le nom que vous souhaitez donner à la nouvelle base de données. Par exemple, pour créer une base de données nommée testdb_copy
, la commande serait :
CREATE DATABASE testdb_copy;
Restauration de l’image mémoire
Après avoir créé la base de données cible, vous pouvez restaurer les données dans cette base de données cible depuis le fichier d’image mémoire. Pendant la restauration, consignez toutes les erreurs dans un fichier errors.log
, puis vérifiez son contenu après la restauration.
- pg_dump et psql : utilisation d’un fichier texte singulier
- pg_dump et pg_restore : utilisation de plusieurs cœurs
psql -f <database name>_dump.sql <new database name> -h <server name> -U <user name> 2> errors.log
Par exemple, si vous avez un serveur nommé mydemoserver
, un utilisateur nommé myuser
et une nouvelle base de données appelée testdb_copy
, exécutez la commande suivante :
psql -f testdb_dump.sql testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log
Vérification après la restauration
Une fois le processus de restauration terminé, il est important de vérifier le fichier errors.log
pour y rechercher toutes les erreurs qui se sont produites le cas échéant. Cette étape est essentielle pour garantir l’intégrité et l’exhaustivité des données restaurées. Résolvez tous les problèmes détectés dans le fichier journal pour maintenir la fiabilité de votre base de données.
Optimisation du processus de migration
Lorsque vous travaillez avec des bases de données volumineuses, le processus de création d’image mémoire et de restauration peut être long et nécessiter une optimisation pour garantir l’efficacité et la fiabilité. Il est important de connaître les différents facteurs qui peuvent avoir un impact sur les performances de ces opérations et de prendre des mesures pour les optimiser.
Pour obtenir une aide détaillée sur l’optimisation du processus de création d’image mémoire et de restauration, veuillez consulter l’article sur Meilleures pratiques pour pg_dump et pg_restore. Cette ressource fournit des informations et des stratégies complètes qui peuvent être utiles pour la gestion de bases de données volumineuses.
Étapes suivantes
- Meilleures pratiques pour pg_dump et pg_restore.
- Pour plus d’informations sur la migration de bases de données vers Azure Database pour PostgreSQL, consultez le Guide de migration des bases de données.