Aggiornare il database PostgreSQL usando dump e ripristino

Articolo
05/24/2023

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

Nota

I concetti illustrati in questa documentazione sono applicabili sia a Database di Azure per PostgreSQL - Server singolo che a server singolo e Database di Azure per PostgreSQL - Server flessibile.

È possibile aggiornare il server PostgreSQL distribuito in Database di Azure per PostgreSQL eseguendo la migrazione dei database a un server di versione principale superiore usando i metodi seguenti.

Metodo offline con postgreSQL pg_dump e pg_restore che comporta tempi di inattività per la migrazione dei dati. Questo documento illustra questo metodo di aggiornamento/migrazione.
Metodo online con Servizio Migrazione del database (DMS). Questo metodo offre una migrazione con tempi di inattività ridotti e mantiene il database di destinazione sincronizzato con l'origine ed è possibile scegliere quando eseguire il cut-over. Esistono tuttavia alcuni prerequisiti e restrizioni da risolvere per l'uso del Servizio Migrazione del database. Per ulteriori informazioni, vedere la documentazione relativa al servizio Migrazione del database.
Metodo di aggiornamento della versione principale sul posto usando Database di Azure per PostgreSQL - Server flessibile. La funzionalità di aggiornamento della versione principale sul posto esegue l'aggiornamento della versione principale del server con un solo clic. Questo semplifica il processo di aggiornamento riducendo al minimo l'interruzione per gli utenti e le applicazioni che accedono al server. Gli aggiornamenti sul posto sono un modo più semplice per aggiornare la versione principale dell'istanza, perché mantengono il nome del server e altre impostazioni del server corrente dopo l'aggiornamento e non richiedono la migrazione dei dati o le modifiche all'applicazione stringa di connessione. Gli aggiornamenti sul posto sono più veloci e comportano tempi di inattività più brevi rispetto alla migrazione dei dati.

La tabella seguente fornisce alcune raccomandazioni basate su dimensioni e scenari del database.

Database/Scenario	Dump/ripristino (offline)	Servizio Migrazione del database (online)
Si dispone di un database di piccole dimensioni e si può permettere tempi di inattività per l'aggiornamento	X
Database di piccole dimensioni (< 10 GB)	X	X
DATABASE medi di piccole dimensioni (10 GB - 100 GB)	X	X
Database di grandi dimensioni (> 100 GB)		X
Può permettere tempi di inattività per l'aggiornamento (indipendentemente dalle dimensioni del database)	X
È possibile risolvere i prerequisiti del Servizio Migrazione del database, incluso un riavvio?		X
È possibile evitare DDLS e tabelle non registrate durante il processo di aggiornamento?		X

Questa guida fornisce alcune metodologie di migrazione offline ed esempi per illustrare come è possibile eseguire la migrazione dal server di origine al server di destinazione che esegue una versione successiva di PostgreSQL.

Nota

Il dump e il ripristino di PostgreSQL possono essere eseguiti in molti modi. È possibile scegliere di eseguire la migrazione usando uno dei metodi forniti in questa guida o scegliere eventuali modi alternativi per soddisfare le proprie esigenze. Per informazioni dettagliate sulla sintassi di dump e ripristino con parametri aggiuntivi, vedere gli articoli pg_dump e pg_restore.

Prerequisiti per l'uso di dump e ripristino con Database di Azure per PostgreSQL

Per eseguire questa guida pratica, è necessario:

Un server di database PostgreSQL di origine che esegue una versione precedente del motore da aggiornare.
Server di database PostgreSQL di destinazione con la versione principale desiderata Database di Azure per PostgreSQL server - Server singolo o Database di Azure per PostgreSQL - Server flessibile.
Un sistema client PostgreSQL per eseguire i comandi dump e ripristino. È consigliabile usare la versione del database più recente. Ad esempio, se si esegue l'aggiornamento da PostgreSQL versione 9.6 a 11, usare il client PostgreSQL versione 11.
- Può trattarsi di un client Linux o Windows con PostgreSQL installato e con le utilità della riga di comando pg_dump e pg_restore installate.
- In alternativa, è possibile usare Azure Cloud Shell o selezionando Azure Cloud Shell nella barra dei menu in alto a destra nella portale di Azure. Sarà necessario accedere all'account az login prima di eseguire i comandi di dump e ripristino.
Il client PostgreSQL è preferibilmente in esecuzione nella stessa area dei server di origine e di destinazione.

Dettagli e considerazioni aggiuntivi

È possibile trovare il stringa di connessione per i database di origine e di destinazione selezionando "stringhe di Connessione" dal portale.
È possibile che nel server siano in esecuzione più database. È possibile trovare l'elenco dei database connettendosi al server di origine ed eseguendo \l.
Creare database corrispondenti nel server di database di destinazione o aggiungere -C l'opzione pg_dump al comando che crea i database.
Non è necessario aggiornare azure_maintenance i database modello o . Se sono state apportate modifiche ai database modello, è possibile scegliere di eseguire la migrazione delle modifiche o apportare tali modifiche nel database di destinazione.
Fare riferimento alle tabelle precedenti per determinare che il database è adatto per questa modalità di migrazione.
Se si vuole usare Azure Cloud Shell, tenere presente che la sessione scade dopo 20 minuti. Se le dimensioni del database sono < pari a 10 GB, è possibile completare l'aggiornamento senza il timeout della sessione. In caso contrario, potrebbe essere necessario mantenere aperta la sessione con altri mezzi, ad esempio premendo un tasto qualsiasi una volta in 10-15 minuti.

Database di esempio usato in questa guida

In questa guida vengono usati i server di origine e di destinazione e i nomi di database seguenti per illustrare gli esempi.

Descrizione	valore
Server di origine (v9.5)	pg-95.postgres.database.azure.com
Database di origine	bench5gb
Dimensioni del database di origine	5 GB
Nome utente di origine	pg@pg-95
Server di destinazione (v11)	pg-11.postgres.database.azure.com
Database di destinazione	bench5gb
Nome utente di destinazione	pg@pg-11

Nota

Il server flessibile supporta PostgreSQL versione 11 e successive. Inoltre, il nome utente del server flessibile non richiede @dbservername.

Aggiornare i database usando i metodi di migrazione offline

È possibile scegliere di usare uno dei metodi descritti in questa sezione per gli aggiornamenti. È possibile usare i suggerimenti seguenti durante l'esecuzione delle attività.

Se si usa la stessa password per l'origine e il database di destinazione, è possibile impostare la PGPASSWORD=yourPassword variabile di ambiente. Non è quindi necessario specificare la password ogni volta che si eseguono comandi come psql, pg_dump e pg_restore. Analogamente, è possibile configurare variabili aggiuntive, ad PGUSEResempio e PGSSLMODE così via, vedere le variabili di ambiente PostgreSQL.
Se il server PostgreSQL richiede connessioni TLS/SSL (per impostazione predefinita nei server Database di Azure per PostgreSQL), impostare una variabile PGSSLMODE=require di ambiente in modo che lo strumento pg_restore si connetta con TLS. Senza TLS, l'errore potrebbe leggere FATAL: SSL connection is required. Please specify SSL options and retry.
Nella riga di comando di Windows, eseguire il comando SET PGSSLMODE=require prima di eseguire il comando pg_restore. Nella riga di comando di Linux o Bash, eseguire il comando export PGSSLMODE=require prima di eseguire il comando pg_restore.

Importante

I passaggi e i metodi forniti in questo documento forniscono alcuni esempi di comandi pg_dump/pg_restore e non rappresentano tutti i possibili modi per eseguire gli aggiornamenti. È consigliabile testare e convalidare i comandi in un ambiente di test prima di usarli nell'ambiente di produzione.

Eseguire la migrazione dei ruoli

I ruoli (utenti) sono oggetti globali e devono essere migrati separatamente nel nuovo cluster prima di ripristinare i database. È possibile usare pg_dumpall l'opzione binaria con -r (--roles-only) per eseguirne il dump. Per eseguire il dump di tutti i ruoli con password dal server singolo di origine:

pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql

Per eseguire il dump di tutti i nomi dei ruoli, senza password dal server flessibile di origine:

pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql

Importante

In Database di Azure per PostgreSQL - Gli utenti del server flessibile non possono accedere alla tabella pg_authid che contiene informazioni sugli identificatori di autorizzazione del database insieme alle password dell'utente. Non è quindi possibile recuperare le password per gli utenti. Prendere in considerazione l'uso di Azure Key Vault per archiviare in modo sicuro i segreti.

roles.sql Modificare e rimuovere i riferimenti di e NOBYPASSRLS prima di ripristinare il contenuto usando psql nel server di NOSUPERUSER destinazione:

psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres

Non è previsto che lo script di dump venga eseguito completamente senza errori. In particolare, poiché lo script genererà CREATE ROLE per ogni ruolo esistente nel cluster di origine, è certo che venga visualizzato un errore di "ruolo già esistente" per l'utente con privilegi avanzati bootstrap, ad esempio azure_pg_admin o azure_superuser. Questo errore è innocuo e può essere ignorato. È probabile che l'uso dell'opzione --clean generi messaggi di errore innocui aggiuntivi sugli oggetti inesistenti, anche se è possibile ridurre al minimo quelli aggiungendo --if-exists.

Metodo 1: uso di pg_dump e psql

Questo metodo prevede due passaggi. Per prima cosa, eseguire il dump di un file SQL dal server di origine usando pg_dump. Il secondo passaggio consiste nell'importare il file nel server di destinazione usando psql. Per informazioni dettagliate, vedere la documentazione Eseguire la migrazione usando l'esportazione e l'importazione .

Metodo 2: uso di pg_dump e pg_restore

In questo metodo di aggiornamento si crea prima di tutto un dump dal server di origine usando pg_dump. Quindi si ripristina il file di dump nel server di destinazione usando pg_restore. Per informazioni dettagliate, vedere la documentazione Eseguire la migrazione tramite dump e ripristino .

Metodo 3: Uso dello streaming dei dati di dump nel database di destinazione

Se non si ha un client PostgreSQL o si vuole usare Azure Cloud Shell, è possibile usare questo metodo. Il dump del database viene trasmesso direttamente al server di database di destinazione e non archivia il dump nel client. Di conseguenza, questo può essere usato con un client con archiviazione limitata e può anche essere eseguito da Azure Cloud Shell.

Verificare che il database esista nel server di destinazione usando \l il comando . Se il database non esiste, creare il database.

 psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"

postgres> \l   
postgres> create database myTargetDB;

Eseguire il dump e il ripristino come riga di comando singola usando una pipe.

pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore  --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB

ad esempio:

pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb

Al termine del processo di aggiornamento (migrazione), è possibile testare l'applicazione con il server di destinazione.
Ripetere questo processo per tutti i database all'interno del server.

Ad esempio, la tabella seguente illustra il tempo necessario per eseguire la migrazione usando il metodo di dump di streaming. I dati di esempio vengono popolati usando pgbench. Poiché il database può avere un numero diverso di oggetti con dimensioni diverse rispetto a tabelle e indici generati da pgbench, è consigliabile testare il dump e il ripristino del database per comprendere il tempo effettivo necessario per aggiornare il database.

Dimensioni database	Tempo approssimativo impiegato
1 GB	1-2 minuti
5 GB	8-10 minuti
10 GB	15-20 minuti
50 GB	1-1,5 ore
100 GB	2,5-3 ore

Metodo 4: Uso di dump e ripristino paralleli

È possibile prendere in considerazione questo metodo se nel database sono presenti poche tabelle di dimensioni maggiori e si vuole parallelizzare il processo di dump e ripristino per tale database. È anche necessario spazio di archiviazione sufficiente nel sistema client per supportare i dump di backup. Questo processo di dump e ripristino parallelo riduce il consumo di tempo per completare l'intera migrazione. Ad esempio, il database pgbench da 50 GB che ha richiesto 1-1,5 ore di migrazione è stato completato usando il metodo 1 e 2 richiede meno di 30 minuti usando questo metodo.

Per ogni database nel server di origine, creare un database corrispondente nel server di destinazione.

psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"

postgres> create database myDB;

ad esempio:

psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require"
psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres> create database bench5gb;
postgres> \q

Eseguire il comando pg_dump in un formato di directory con numero di processi = 4 (numero di tabelle nel database). Con un livello di calcolo più grande e con più tabelle, è possibile aumentarlo a un numero maggiore. Tale pg_dump creerà una directory per archiviare i file compressi per ogni processo.
```
pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory
```
ad esempio:
```
pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir
```

Ripristinare quindi il backup nel server di destinazione.

$ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDir

ad esempio:

$ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir

Suggerimento

Il processo indicato in questo documento può essere usato anche per aggiornare il server flessibile Database di Azure per PostgreSQL. La differenza principale è la stringa di connessione per la destinazione del server flessibile senza @dbName. Ad esempio, se il nome utente è pg, il nome utente del singolo server nella stringa di connessione sarà pg@pg-95, mentre con il server flessibile, è sufficiente usare pg.

Post-aggiornamento/migrazione

Al termine dell'aggiornamento della versione principale, è consigliabile eseguire il ANALYZE comando in ogni database per aggiornare la pg_statistic tabella. In caso contrario, è possibile che si verifichino problemi di prestazioni.

postgres=> analyze;
ANALYZE

Passaggi successivi

Dopo aver soddisfatto la funzione del database di destinazione, è possibile eliminare il server di database precedente.
Solo per Database di Azure per PostgreSQL - Server singolo. Se si vuole usare lo stesso endpoint di database del server di origine, dopo aver eliminato il server di database di origine precedente, è possibile creare una replica di lettura con il nome del server di database precedente. Dopo aver stabilito lo stato di replica stabile, è possibile arrestare la replica, che promuoverà il server di replica come server indipendente. Per ulteriori informazioni, vedere Replica.

Importante

È consigliabile testare la nuova versione aggiornata di PostgreSQL prima di usarla direttamente per la produzione. Ciò include il confronto dei parametri del server tra l'origine della versione di origine precedente e la destinazione della versione più recente. Assicurarsi che siano uguali e controllare eventuali nuovi parametri aggiunti nella nuova versione. Le differenze tra le versioni sono disponibili qui.

Condividi tramite

Aggiornare il database PostgreSQL usando dump e ripristino

Prerequisiti per l'uso di dump e ripristino con Database di Azure per PostgreSQL

Dettagli e considerazioni aggiuntivi

Database di esempio usato in questa guida

Aggiornare i database usando i metodi di migrazione offline

Eseguire la migrazione dei ruoli

Metodo 1: uso di pg_dump e psql

Metodo 2: uso di pg_dump e pg_restore

Metodo 3: Uso dello streaming dei dati di dump nel database di destinazione

Metodo 4: Uso di dump e ripristino paralleli

Post-aggiornamento/migrazione

Passaggi successivi

Risorse aggiuntive