Eseguire la migrazione del database PostgreSQL usando dump e ripristino
SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile
È possibile usare pg_dump per estrarre un database PostgreSQL in un file dump. Il metodo per ripristinare il database dipende dal formato del dump scelto. Se il dump viene acquisito con il formato normale (ovvero l'opzione predefinita -Fp
, quindi non è necessario specificare alcuna opzione specifica), l'unica opzione per ripristinarla consiste nell'usare psql, perché restituisce un file di testo normale. Per gli altri tre metodi di dump: personalizzato, directory e tar, è necessario usare pg_restore .
Importante
Le istruzioni e i comandi forniti in questo articolo sono progettati per essere eseguiti nei terminali bash. Sono inclusi ambienti come sottosistema Windows per Linux (WSL), Azure Cloud Shell e altre interfacce compatibili con bash. Assicurarsi di usare un terminale bash per seguire i passaggi ed eseguire i comandi descritti in dettaglio in questa guida. L'uso di un tipo diverso di terminale o ambiente shell può comportare differenze nel comportamento dei comandi e potrebbe non produrre i risultati previsti.
In questo articolo ci concentriamo sui formati semplici (predefiniti) e di directory. Il formato di directory è utile perché consente di usare più core per l'elaborazione, che può migliorare significativamente l'efficienza, soprattutto per i database di grandi dimensioni.
Il portale di Azure semplifica questo processo tramite il pannello Connetti offrendo comandi preconfigurati personalizzati per il server, con valori sostituiti con i dati utente. È importante notare che il pannello Connetti è disponibile solo per Database di Azure per PostgreSQL - Server flessibile e non per server singolo. Ecco come usare questa funzionalità:
Accedere portale di Azure: passare prima alla portale di Azure e scegliere il pannello Connetti.
Selezionare il database: nel pannello Connetti è disponibile un elenco a discesa dei database. Selezionare il database da cui si vuole eseguire un dump.
Scegliere il metodo appropriato: a seconda delle dimensioni del database, è possibile scegliere tra due metodi:
pg_dump
&psql
- usando un file di testo singolare: ideale per i database più piccoli, questa opzione usa un singolo file di testo per il processo di dump e ripristino.pg_dump
&pg_restore
- Uso di più core: per i database di dimensioni maggiori, questo metodo è più efficiente perché usa più core per gestire il processo di dump e ripristino.
Copiare e incollare i comandi: il portale offre comandi e e
psql
pg_restore
pronti per l'usopg_dump
. Questi comandi sono disponibili con valori già sostituiti in base al server e al database scelto. Copiare e incollare questi comandi.
Prerequisiti
Se si usa un server singolo o non si ha accesso al portale server flessibile, leggere questa pagina della documentazione. Contiene informazioni simili a quanto presentato nel pannello Connetti per il server flessibile nel portale.
Nota
Poiché pg_dump
tutte le utilità , pg_restore
psql
e pg_dumpall
si basano su libpq, è possibile usare qualsiasi variabile di ambiente supportata offerta oppure usare il file della password per evitare di richiedere la password ogni volta che si esegue uno di questi comandi.
Per proseguire con questa guida, si richiedono:
- Un server Database di Azure per PostgreSQL, incluse le regole del firewall per consentire l'accesso.
- pg_dump, psql, pg_restore e pg_dumpall nel caso in cui si voglia eseguire la migrazione con ruoli e autorizzazioni, utilità della riga di comando installate.
- Decidere il percorso del dump: scegliere la posizione da cui si vuole eseguire il dump. Può essere eseguita da diverse posizioni, ad esempio una macchina virtuale separata, Cloud Shell (in cui le utilità della riga di comando sono già installate, ma potrebbero non trovarsi nella versione appropriata, quindi controllare sempre la versione usando, ad esempio ,
psql --version
) o il proprio portatile. Tenere sempre presente la distanza e la latenza tra il server PostgreSQL e il percorso da cui si esegue il dump o il ripristino.
Importante
È essenziale usare le pg_dump
utilità , psql
pg_restore
e pg_dumpall
che sono della stessa versione principale o di una versione principale successiva rispetto al server di database in cui si esportano dati o importano dati. In caso contrario, la migrazione dei dati potrebbe non riuscire. Se il server di destinazione ha una versione principale superiore rispetto al server di origine, usare le utilità che corrispondono alla stessa versione principale o successiva al server di destinazione.
Nota
È importante tenere presente che pg_dump
è possibile esportare un solo database alla volta. Questa limitazione si applica indipendentemente dal metodo scelto, indipendentemente dal fatto che usi un file singolare o più core.
Dump di utenti e ruoli con pg_dumpall -r
pg_dump
viene usato per estrarre un database PostgreSQL in un file di dump. Tuttavia, è fondamentale comprendere che pg_dump
non esegue il dump dei ruoli o delle definizioni degli utenti, poiché questi sono considerati oggetti globali all'interno dell'ambiente PostgreSQL. Per una migrazione completa, inclusi utenti e ruoli, è necessario usare pg_dumpall -r
.
Questo comando consente di acquisire tutte le informazioni sul ruolo e sull'utente dall'ambiente PostgreSQL. Se si esegue la migrazione all'interno di database nello stesso server, ignorare questo passaggio e passare alla sezione Creare un nuovo database .
pg_dumpall -r -h <server name> -U <user name> > roles.sql
Ad esempio, se si dispone di un server denominato mydemoserver
e un utente denominato myuser
eseguire il comando seguente:
pg_dumpall -r -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql
Se si usa un server singolo, il nome utente include il componente del nome del server. Pertanto, invece di myuser
, usare myuser@mydemoserver
.
Dump dei ruoli da un server flessibile
In un ambiente server flessibile, le misure di sicurezza avanzate indicano che gli utenti non hanno accesso alla tabella pg_authid, che è la posizione in cui vengono archiviate le password dei ruoli. Questa restrizione influisce sul modo in cui si esegue un dump dei ruoli, perché il comando standard pg_dumpall -r
tenta di accedere a questa tabella per le password e non riesce a causa della mancanza di autorizzazione.
Quando si esegue il dump dei ruoli da un server flessibile, è fondamentale includere l'opzione --no-role-passwords
nel pg_dumpall
comando. Questa opzione impedisce pg_dumpall
di tentare di accedere pg_authid
alla tabella, che non può leggere a causa di restrizioni di sicurezza.
Per eseguire correttamente il dump dei ruoli da un server flessibile, usare il comando seguente:
pg_dumpall -r --no-role-passwords -h <server name> -U <user name> > roles.sql
Ad esempio, se si dispone di un server denominato mydemoserver
, un utente denominato myuser
, eseguire il comando seguente:
pg_dumpall -r --no-role-passwords -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql
Pulizia del dump dei ruoli
Quando si esegue la migrazione del file roles.sql
di output, alcuni ruoli e attributi non applicabili o consentiti nel nuovo ambiente. Ecco cosa è necessario considerare:
Rimozione degli attributi che possono essere impostati solo dagli utenti con privilegi avanzati: se si esegue la migrazione a un ambiente in cui non si hanno privilegi con privilegi avanzati, rimuovere attributi come
NOSUPERUSER
eNOBYPASSRLS
dal dump dei ruoli.Esclusione di utenti specifici del servizio: escludere gli utenti del servizio server singolo, ad esempio
azure_superuser
oazure_pg_admin
. Questi elementi sono specifici del servizio e verranno creati automaticamente nel nuovo ambiente.
Usare il comando seguente sed
per pulire il dump dei ruoli:
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
Questo comando elimina le righe contenenti azure_superuser
, azure_pg_admin
, azuresu
a partire da CREATE ROLE replication
e ALTER ROLE replication
e rimuove gli NOSUPERUSER
attributi e NOBYPASSRLS
dalle ALTER ROLE
istruzioni .
Creare un file di dump contenente i dati da caricare
Per esportare il database PostgreSQL esistente in locale o in una macchina virtuale in un file di script SQL, eseguire il comando seguente nell'ambiente esistente:
pg_dump <database name> -h <server name> -U <user name> > <database name>_dump.sql
Ad esempio, se si dispone di un server denominato mydemoserver
, un utente denominato myuser
e un database denominato testdb
, eseguire il comando seguente:
pg_dump testdb -h mydemoserver.postgres.database.azure.com -U myuser > testdb_dump.sql
Se si usa un server singolo, il nome utente include il componente del nome del server. Pertanto, invece di myuser
, usare myuser@mydemoserver
.
Ripristinare i dati nel database di destinazione
Ripristinare ruoli e utenti
Prima di ripristinare gli oggetti di database, assicurarsi di avere eseguito correttamente il dump e la pulizia dei ruoli. Se si esegue la migrazione all'interno di database nello stesso server, il dump dei ruoli e il ripristino potrebbero non essere necessari. Tuttavia, per le migrazioni tra server o ambienti diversi, questo passaggio è fondamentale.
Per ripristinare i ruoli e gli utenti nel database di destinazione, usare il comando seguente:
psql -f roles.sql -h <server_name> -U <user_name>
Sostituire <server_name>
con il nome del server di destinazione e <user_name>
con il nome utente. Questo comando usa l'utilità psql
per eseguire i comandi SQL contenuti nel roles.sql
file, ripristinando in modo efficace i ruoli e gli utenti nel database di destinazione.
Ad esempio, se si dispone di un server denominato mydemoserver
, un utente denominato myuser
, eseguire il comando seguente:
psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser
Se si usa un server singolo, il nome utente include il componente del nome del server. Pertanto, invece di myuser
, usare myuser@mydemoserver
.
Nota
Se si dispone già di utenti con gli stessi nomi nel server singolo o nel server locale da cui si esegue la migrazione e il server di destinazione, tenere presente che questo processo di ripristino potrebbe modificare le password per questi ruoli. Di conseguenza, tutti i comandi successivi da eseguire potrebbero richiedere le password aggiornate. Ciò non si applica se il server di origine è un server flessibile, perché il server flessibile non consente il dump delle password per gli utenti a causa di misure di sicurezza avanzate.
Creare un nuovo database
Prima di ripristinare il database, potrebbe essere necessario creare un nuovo database vuoto. A tale scopo, l'utente che si sta usando deve disporre dell'autorizzazione CREATEDB
. Ecco due metodi comunemente usati:
Uso dell'utilità
createdb
Ilcreatedb
programma consente la creazione di database direttamente dalla riga di comando bash, senza dover accedere a PostgreSQL o lasciare l'ambiente del sistema operativo. Ad esempio:createdb <new database name> -h <server name> -U <user name>
Ad esempio, se si dispone di un server denominato
mydemoserver
, un utente denominatomyuser
e il nuovo database che si vuole creare ètestdb_copy
, eseguire il comando seguente:createdb testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser
Se si usa un server singolo, il nome utente include il componente del nome del server. Pertanto, invece di
myuser
, usaremyuser@mydemoserver
.Usando il comando SQL Per creare un database usando un comando SQL, è necessario connettersi al server PostgreSQL tramite un'interfaccia della riga di comando o uno strumento di gestione del database. Dopo la connessione, è possibile usare il comando SQL seguente per creare un nuovo database:
CREATE DATABASE <new database name>;
Sostituire <new database name>
con il nome da assegnare al nuovo database. Ad esempio, per creare un database denominato testdb_copy
, il comando sarà:
CREATE DATABASE testdb_copy;
Ripristino del dump
Dopo aver creato il database di destinazione, è possibile ripristinare i dati in questo database dal file di dump. Durante il ripristino, registrare eventuali errori in un errors.log
file e controllarne la presenza di eventuali errori al termine del ripristino.
psql -f <database name>_dump.sql <new database name> -h <server name> -U <user name> 2> errors.log
Ad esempio, se si dispone di un server denominato mydemoserver
, un utente denominato myuser
e un nuovo database denominato testdb_copy
, eseguire il comando seguente:
psql -f testdb_dump.sql testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log
Controllo post-ripristino
Al termine del processo di ripristino, è importante esaminare il errors.log
file per eventuali errori che potrebbero essersi verificati. Questo passaggio è fondamentale per garantire l'integrità e la completezza dei dati ripristinati. Risolvere eventuali problemi rilevati nel file di log per mantenere l'affidabilità del database.
Ottimizzare il processo di migrazione
Quando si lavora con database di grandi dimensioni, il processo di dump e ripristino può essere lungo e può richiedere l'ottimizzazione per garantire efficienza e affidabilità. È importante essere consapevoli dei vari fattori che possono influire sulle prestazioni di queste operazioni e di adottare misure per ottimizzarle.
Per indicazioni dettagliate sull'ottimizzazione del processo di dump e ripristino, vedere l'articolo Procedure consigliate per pg_dump e pg_restore . Questa risorsa fornisce informazioni e strategie complete che possono essere utili per la gestione di database di grandi dimensioni.
Passaggi successivi
- Procedure consigliate per pg_dump e pg_restore.
- Per altre informazioni sulla migrazione dei database in Database di Azure per PostgreSQL, vedere Database Migration Guide (Guida alla migrazione di database).