Share via

Uw PostgreSQL-database upgraden met behulp van dump en herstel

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - enkele server

Belangrijk

Azure Database for PostgreSQL - Enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om een upgrade uit te voeren naar Azure Database for PostgreSQL - Flexible Server. Zie Wat gebeurt er met Azure Database for PostgreSQL Enkele server voor meer informatie over migreren naar Azure Database for PostgreSQL - Flexible Server.

Notitie

De concepten die in deze documentatie worden uitgelegd, zijn van toepassing op zowel Azure Database for PostgreSQL - Enkele server als Azure Database for PostgreSQL - Flexible Server.

U kunt uw PostgreSQL-server upgraden die is geïmplementeerd in Azure Database for PostgreSQL door uw databases te migreren naar een hogere primaire versieserver met behulp van de volgende methoden.

  • Offlinemethode met postgreSQL-pg_dump en pg_restore die downtime in rekening gebracht voor het migreren van de gegevens. In dit document wordt deze methode van upgrade/migratie aangepakt.
  • Onlinemethode met behulp van Database Migration Service (DMS). Deze methode biedt een verminderde downtimemigratie en houdt de doeldatabase synchroon met de bron en u kunt kiezen wanneer u wilt knippen. Er zijn echter enkele vereisten en beperkingen die moeten worden afgehandeld om DMS te kunnen gebruiken. Raadpleeg de DMS-documentatie voor de details.
  • In-place methode voor het upgraden van primaire versies met behulp van Azure Database for PostgreSQL - Flexible Server. In-place primaire versie upgrade functie voert primaire versie upgrade van de server met slechts een klik. Dit vereenvoudigt het upgradeproces waardoor de onderbreking voor gebruikers en toepassingen die toegang hebben tot de server, wordt geminimaliseerd. In-place upgrades zijn een eenvoudigere manier om de primaire versie van het exemplaar bij te werken, omdat ze de servernaam en andere instellingen van de huidige server na de upgrade behouden en geen gegevensmigratie of wijzigingen in de toepassing verbindingsreeks s vereisen. In-place upgrades zijn sneller en hebben een kortere downtime dan gegevensmigratie.

De volgende tabel bevat enkele aanbevelingen op basis van databasegrootten en scenario's.

Database/scenario Dump/herstel (offline) DMS (online)
U hebt een kleine database en u kunt downtime betalen om een upgrade uit te voeren X
Kleine databases (< 10 GB) X X
Kleine middelgrote DB's (10 GB – 100 GB) X X
Grote databases (> 100 GB) X
Kan uitvaltijd veroorloven om een upgrade uit te voeren (ongeacht de databasegrootte) X
Kunt u voldoen aan DMS-vereisten, inclusief opnieuw opstarten? X
Kunt u DDLs en niet-geregistreerde tabellen voorkomen tijdens het upgradeproces? X

Deze handleiding bevat enkele offlinemigratiemethodologieën en voorbeelden om te laten zien hoe u kunt migreren van uw bronserver naar de doelserver waarop een hogere versie van PostgreSQL wordt uitgevoerd.

Notitie

PostgreSQL-dump en -herstel kunnen op veel manieren worden uitgevoerd. U kunt ervoor kiezen om te migreren met behulp van een van de methoden in deze handleiding of kies een andere manier om aan uw behoeften te voldoen. Zie de artikelen pg_dump en pg_restore voor gedetailleerde dump- en herstelsyntaxis met aanvullende parameters.

Vereisten voor het gebruik van dump en herstel met Azure Database for PostgreSQL

Als u deze handleiding wilt doorlopen, hebt u het volgende nodig:

  • Een postgreSQL-brondatabaseserver met een lagere versie van de engine die u wilt upgraden.
  • Een postgreSQL-doeldatabaseserver met de gewenste primaire versie van Azure Database for PostgreSQL-server - Enkele server of Azure Database for PostgreSQL - Flexibele server.
  • Een PostgreSQL-clientsysteem voor het uitvoeren van de dump- en herstelopdrachten. Het is raadzaam om de hogere databaseversie te gebruiken. Als u bijvoorbeeld een upgrade uitvoert van PostgreSQL versie 9.6 naar 11, gebruikt u de PostgreSQL-client versie 11.
    • Het kan een Linux- of Windows-client zijn waarop PostgreSQL is geïnstalleerd en waarop de pg_dump en pg_restore opdrachtregelprogramma's zijn geïnstalleerd.
    • U kunt ook Azure Cloud Shell gebruiken of door de Azure Cloud Shell te selecteren in de menubalk rechtsboven in Azure Portal. U moet zich aanmelden bij uw account az login voordat u de dump- en herstelopdrachten uitvoert.
  • Uw PostgreSQL-client wordt bij voorkeur uitgevoerd in dezelfde regio als de bron- en doelservers.

Aanvullende details en overwegingen

  • U vindt de verbindingsreeks naar de bron- en doeldatabases door in de portal de 'Verbinding maken ion Strings' te selecteren.
  • Mogelijk voert u meer dan één database uit op uw server. U vindt de lijst met databases door verbinding te maken met uw bronserver en uit te voeren \l.
  • Maak bijbehorende databases op de doeldatabaseserver of voeg een optie toe -C aan de pg_dump opdracht waarmee de databases worden gemaakt.
  • U mag geen upgrade uitvoeren azure_maintenance of sjabloondatabases. Als u wijzigingen hebt aangebracht in sjabloondatabases, kunt u ervoor kiezen om de wijzigingen te migreren of deze wijzigingen aan te brengen in de doeldatabase.
  • Raadpleeg de bovenstaande tabellen om te bepalen of de database geschikt is voor deze migratiemodus.
  • Als u Azure Cloud Shell wilt gebruiken, moet u er rekening mee houden dat er na 20 minuten een time-out optreedt voor de sessie. Als uw databasegrootte 10 GB is < , kunt u de upgrade mogelijk voltooien zonder dat er een time-out optreedt voor de sessie. Anders moet u de sessie mogelijk op een andere manier openhouden, zoals eenmaal in 10-15 minuten op een toets drukken.

Voorbeelddatabase die in deze handleiding wordt gebruikt

In deze handleiding worden de volgende bron- en doelservers en databasenamen gebruikt om voorbeelden te illustreren.

Beschrijving Value
Bronserver (v9.5) pg-95.postgres.database.azure.com
Brondatabase bench5gb
Grootte van brondatabase 5 GB
Gebruikersnaam van bron pg@pg-95
Doelserver (v11) pg-11.postgres.database.azure.com
Doeldatabase bench5gb
Doelgebruikersnaam pg@pg-11

Notitie

Flexibele server ondersteunt PostgreSQL versie 11 en hoger. Daarnaast is de gebruikersnaam van de flexibele server niet vereist @dbservername.

Uw databases upgraden met behulp van offlinemigratiemethoden

U kunt ervoor kiezen om een van de methoden te gebruiken die in deze sectie worden beschreven voor uw upgrades. U kunt de volgende tips gebruiken tijdens het uitvoeren van de taken.

  • Als u hetzelfde wachtwoord gebruikt voor de bron- en doeldatabase, kunt u de PGPASSWORD=yourPassword omgevingsvariabele instellen. Vervolgens hoeft u niet telkens een wachtwoord op te geven wanneer u opdrachten uitvoert, zoals psql, pg_dump en pg_restore. Op dezelfde manier kunt u aanvullende variabelen zoals PGUSER, PGSSLMODE enzovoort, instellen voor Omgevingsvariabelen van PostgreSQL.

  • Als voor uw PostgreSQL-server TLS/SSL-verbindingen zijn vereist (standaard ingeschakeld in Azure Database for PostgreSQL-servers), stelt u een omgevingsvariabele PGSSLMODE=require in zodat het hulpprogramma pg_restore verbinding maakt met TLS. Zonder TLS kan de fout worden gelezen FATAL: SSL connection is required. Please specify SSL options and retry.

  • Voer in de Windows-opdrachtregel de opdracht SET PGSSLMODE=require uit voordat u de pg_restore opdracht uitvoert. Voer in Linux of Bash de opdracht export PGSSLMODE=require uit voordat u de opdracht pg_restore uitvoert.

Belangrijk

De stappen en methoden in dit document zijn om enkele voorbeelden te geven van pg_dump/pg_restore opdrachten en zijn niet alle mogelijke manieren om upgrades uit te voeren. Het is raadzaam om de opdrachten in een testomgeving te testen en te valideren voordat u ze in productie gebruikt.

De rollen migreren

Rollen (gebruikers) zijn globale objecten en moeten afzonderlijk naar het nieuwe cluster worden gemigreerd voordat de database(s) worden hersteld. U kunt binair met de optie -r (--roles-only) gebruiken pg_dumpall om ze te dumpen. Als u alle rollen met wachtwoorden van de bronserver met één server wilt dumpen:

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

Als u alle rollennamen wilt dumpen, zonder wachtwoorden van de flexibele bronserver: 

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

Belangrijk

In Azure Database for PostgreSQL - Flexible Server-gebruikers hebben geen toegang tot pg_authid tabel die informatie bevat over databaseautorisatie-id's samen met de wachtwoorden van de gebruiker. Het ophalen van wachtwoorden voor gebruikers is daarom niet mogelijk. Overweeg om Azure Key Vault te gebruiken om uw geheimen veilig op te slaan.

Bewerk de roles.sql verwijzingen van en NOBYPASSRLS verwijder deze voordat u de inhoud herstelt met behulp van NOSUPERUSER psql op de doelserver:

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

Het dumpscript mag niet volledig zonder fouten worden uitgevoerd. Met name omdat het script CREATE ROLE uitgeeft voor elke rol die in het broncluster bestaat, is het zeker dat er een fout 'rol bestaat' voor de bootstrap-supergebruiker, zoals azure_pg_admin of azure_superuser. Deze fout is ongevaarlijk en kan worden genegeerd. Het gebruik van de --clean optie produceert waarschijnlijk extra ongevaarlijke foutberichten over niet-bestaande objecten, hoewel u deze kunt minimaliseren door toe te voegen --if-exists.

Methode 1: pg_dump en psql gebruiken

Deze methode bestaat uit twee stappen. Eerst moet u een SQL-bestand dumpen vanaf de bronserver met behulp van pg_dump. De tweede stap is het importeren van het bestand naar de doelserver met behulp van psql. Raadpleeg de documentatie voor migreren met behulp van export en import voor meer informatie.

Methode 2: pg_dump en pg_restore gebruiken

In deze upgrademethode maakt u eerst een dump van de bronserver met behulp van pg_dump. Vervolgens herstelt u dat dumpbestand naar de doelserver met behulp van pg_restore. Raadpleeg de documentatie voor migreren met behulp van dump en herstel voor meer informatie.

Methode 3: de dumpgegevens streamen naar de doeldatabase

Als u geen PostgreSQL-client hebt of als u Azure Cloud Shell wilt gebruiken, kunt u deze methode gebruiken. De databasedump wordt rechtstreeks naar de doeldatabaseserver gestreamd en slaat de dump niet op in de client. Dit kan daarom worden gebruikt met een client met beperkte opslag en kan zelfs worden uitgevoerd vanuit De Azure Cloud Shell.

  1. Zorg ervoor dat de database bestaat op de doelserver met behulp van \l de opdracht. Als de database niet bestaat, maakt u de database.

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

    postgres> \l   
postgres> create database myTargetDB;

  2. Voer de dump en herstel uit als één opdrachtregel met behulp van een pipe.

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

    Voorbeeld:

    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

  3. Zodra het upgradeproces (migratie) is voltooid, kunt u uw toepassing testen met de doelserver.

  4. Herhaal dit proces voor alle databases op de server.

In de volgende tabel ziet u bijvoorbeeld de tijd die nodig was om te migreren met behulp van de streamingdumpmethode. De voorbeeldgegevens worden gevuld met pgbench. Omdat uw database een ander aantal objecten kan hebben met verschillende grootten dan door pgbench gegenereerde tabellen en indexen, is het raadzaam om dump en herstel van uw database te testen om inzicht te krijgen in de werkelijke tijd die nodig is om uw database bij te werken.

Databasegrootte Ca. tijd die nodig is
1 GB 1-2 minuten
5 GB 8-10 minuten
10 GB 15-20 minuten
50 GB 1-1,5 uur
100 GB 2,5-3 uur

Methode 4: Parallelle dump en herstel gebruiken

U kunt deze methode overwegen als u enkele grotere tabellen in uw database hebt en u het dump- en herstelproces voor die database wilt parallelliseren. U hebt ook voldoende opslag in uw clientsysteem nodig om back-updumps te kunnen gebruiken. Dit parallelle dump- en herstelproces vermindert het tijdsverbruik om de hele migratie te voltooien. De pgbench-database van 50 GB die 1-1,5 uur duurde om te migreren, is bijvoorbeeld voltooid met methode 1 en 2 duurde minder dan 30 minuten met behulp van deze methode.

  1. Maak voor elke database op de bronserver een bijbehorende database op de doelserver.

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

    postgres> create database myDB;

    Voorbeeld:

    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

  2. Voer de opdracht pg_dump uit in een mapindeling met het aantal taken = 4 (aantal tabellen in de database). Met een grotere rekenlaag en met meer tabellen kunt u deze verhogen naar een hoger getal. Deze pg_dump maakt een map voor het opslaan van gecomprimeerde bestanden voor elke taak.

    pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory

    Voorbeeld:

    pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir

  3. Herstel vervolgens de back-up op de doelserver.

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

    Voorbeeld:

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

Tip

Het proces dat in dit document wordt genoemd, kan ook worden gebruikt om uw Azure Database for PostgreSQL - Flexible-server te upgraden. Het belangrijkste verschil is de verbindingsreeks voor het flexibele serverdoel is zonder .@dbName Als de gebruikersnaam bijvoorbeeld is pg, is pg@pg-95de gebruikersnaam van de enkele server in de verbindingsreeks, terwijl u met flexibele server gewoon kunt gebruiken pg.

Na de upgrade/migratie

Nadat de upgrade van de primaire versie is voltooid, raden we u aan de ANALYZE opdracht in elke database uit te voeren om de pg_statistic tabel te vernieuwen. Anders kunnen er prestatieproblemen optreden.

postgres=> analyze;
ANALYZE

Volgende stappen

  • Nadat u tevreden bent met de doeldatabasefunctie, kunt u de oude databaseserver verwijderen.
  • Alleen voor Azure Database for PostgreSQL - Enkele server. Als u hetzelfde database-eindpunt als de bronserver wilt gebruiken, kunt u, nadat u de oude brondatabaseserver hebt verwijderd, een leesreplica maken met de naam van de oude databaseserver. Zodra de gestage replicatiestatus tot stand is gebracht, kunt u de replica stoppen, waardoor de replicaserver een onafhankelijke server wordt. Zie Replicatie voor meer informatie.

Belangrijk

Het wordt ten zeerste aanbevolen om de nieuwe bijgewerkte versie van PostgreSQL te testen voordat u deze rechtstreeks voor productie gebruikt. Dit omvat het vergelijken van serverparameters tussen de bronbron van de oudere bronversie en het nieuwere versiedoel. Zorg ervoor dat ze hetzelfde zijn en controleer op eventuele nieuwe parameters die zijn toegevoegd in de nieuwe versie. Verschillen tussen versies vindt u hier.