sql >> Databasteknik >  >> RDS >> PostgreSQL

Migrera PostgreSQL till molnet - Jämföra lösningar från Amazon, Google och Microsoft

Från ett fågelperspektiv verkar det som när det gäller att migrera PostgreSQL-arbetsbelastningarna till molnet, bör valet av molnleverantör inte göra någon skillnad. PostgreSQL gör det enkelt att replikera data, utan driftstopp, via logisk replikering, men med vissa begränsningar. För att göra sitt tjänsteutbud mer attraktivt kan molnleverantörer komma över några av dessa begränsningar. När vi börjar tänka på skillnader i tillgängliga PostgreSQL-versioner, kompatibilitet, begränsningar, begränsningar och prestanda, blir det tydligt att migreringstjänsterna är nyckelfaktorer i det övergripande tjänsteutbudet. Det är inte längre ett fall av "vi erbjuder det, vi migrerar det". Det har blivit mer som "vi erbjuder det, vi migrerar det, med minsta möjliga begränsningar".

Migrering är viktigt för både små och stora organisationer. Det handlar inte lika mycket om storleken på PostgreSQL-klustret, som det handlar om acceptabel driftstopp och ansträngning efter migrering.

Välja en strategi

Migreringsstrategin bör ta hänsyn till databasens storlek, nätverkslänken mellan källan och målet, samt migreringsverktygen som erbjuds av molnleverantören.

Hårdvara eller programvara?

Precis som att skicka USB-nycklar och DVD-skivor från början av internet, i de fall där nätverkets bandbredd inte räcker till för att överföra data med önskad hastighet, erbjuder molnleverantörer hårdvarulösningar som kan att bära upp till hundratals petabyte data. Nedan är de aktuella lösningarna från var och en av de tre stora:

En praktisk tabell från Google som visar de tillgängliga alternativen:

GCP-verktyget är Transfer Appliance

En liknande rekommendation från Azure baserat på datastorleken kontra nätverkets bandbredd:

Azure-enheten är databox

Mot slutet av sin datamigreringssida ger AWS en glimt av vad vi kan förvänta oss, tillsammans med deras rekommendation av lösningen:

I fall där databasstorlekarna överstiger 100 GB och begränsad nätverksbandbredd föreslår AWS en hårdvarulösning.

AWS-apparaten är Snowball Edge

Dataexport/Import

Organisationer som tolererar driftstopp kan dra nytta av enkelheten hos vanliga verktyg som PostgreSQL tillhandahåller direkt. Men när du migrerar data från en moln (eller värd) leverantör till en annan moln leverantör, akta dig för utgående kostnad.

AWS

För att testa migreringarna använde jag en lokal installation av min Nextcloud-databas som kördes på en av mina hemnätverksservrar:

postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));

pg_size_pretty

----------------

58 MB

(1 row)



nextcloud_prod=# \dt

                     List of relations

Schema |             Name | Type  | Owner

--------+-------------------------------+-------+-----------

public | awsdms_ddl_audit              | table | s9sdemo

public | oc_accounts                   | table | nextcloud

public | oc_activity                   | table | nextcloud

public | oc_activity_mq                | table | nextcloud

public | oc_addressbookchanges         | table | nextcloud

public | oc_addressbooks               | table | nextcloud

public | oc_appconfig                  | table | nextcloud

public | oc_authtoken                  | table | nextcloud

public | oc_bruteforce_attempts        | table | nextcloud

public | oc_calendar_invitations       | table | nextcloud

public | oc_calendar_reminders         | table | nextcloud

public | oc_calendar_resources         | table | nextcloud

public | oc_calendar_resources_md      | table | nextcloud

public | oc_calendar_rooms             | table | nextcloud

public | oc_calendar_rooms_md          | table | nextcloud

...

public | oc_termsofservice_terms       | table | nextcloud

public | oc_text_documents             | table | nextcloud

public | oc_text_sessions              | table | nextcloud

public | oc_text_steps                 | table | nextcloud

public | oc_trusted_servers            | table | nextcloud

public | oc_twofactor_backupcodes      | table | nextcloud

public | oc_twofactor_providers        | table | nextcloud

public | oc_users                      | table | nextcloud

public | oc_vcategory                  | table | nextcloud

public | oc_vcategory_to_object        | table | nextcloud

public | oc_whats_new                  | table | nextcloud

(84 rows)

The database is running PostgreSQL version 11.5:

postgres=# select version();

                                                version

------------------------------------------------------------------------------------------------------------

PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit

(1 row)

Jag har också skapat en PostgreSQL-användare som ska användas av AWS DMS som är Amazons tjänst för att importera PostgreSQL till Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

-----------+------------+-------------

s9sdemo   |   | {nextcloud}

AWS DMS ger många fördelar, precis som vi kan förvänta oss av en hanterad lösning i molnet: 

  • automatisk skalning (endast lagring, eftersom beräkningsinstansen måste ha rätt storlek)
  •  automatisk administration
  •  pay-by-you-go-modell
  •  automatisk failover

Men att upprätthålla datakonsistens för en livedatabas är det bästa försöket. En 100 % konsekvens uppnås endast när databasen är i skrivskyddat läge – det är en konsekvens av hur tabelländringar fångas upp.

Med andra ord har tabeller en annan tidsgräns:

Precis som med allt i molnet är det en kostnad förknippad med migreringstjänst.

För att skapa migreringsmiljön, följ guiden Komma igång för att ställa in en replikeringsinstans, en källa, en målslutpunkt och en eller flera uppgifter.

replikeringsinstans

Att skapa replikeringsinstansen är enkel för alla som är bekanta med EC2-instanser på AWS:

Den enda ändringen från standardinställningarna var att välja AWS DMS 3.3.0 eller senare på grund av att min lokala PostgreSQL-motor är 11.5:

Och här är listan över tillgängliga AWS DMS-versioner:

Stora installationer bör också ta hänsyn till AWS DMS-gränserna:

Det finns också en uppsättning begränsningar som är en konsekvens av PostgreSQL logisk replikering restriktioner. Till exempel kommer AWS DMS inte att migrera sekundära objekt:

Det är värt att nämna att i PostgreSQL är alla index sekundära index, och att är inte en dålig sak, som noterats i denna mer detaljerade diskussion.

Källslutpunkt

Följ guiden för att skapa Source Endpoint:

I installationsscenariot Konfiguration för ett nätverk till en VPC Använda Internet my hemnätverket krävde några justeringar för att tillåta källans slutpunkts IP-adress att komma åt min interna server. Först skapade jag en portvidarebefordran på edge-routern (173.180.222.170) för att skicka trafik på port 30485 till min interna gateway (10.11.11.241) på port 5432 där jag kan finjustera åtkomsten baserat på käll-IP-adressen via iptables-regler. Därifrån flyter nätverkstrafik genom en SSH-tunnel till webbservern som kör PostgreSQL-databasen. Med den beskrivna konfigurationen kommer client_addr i utgången av pg_stat_activity att visas som 127.0.0.1.

Innan inkommande trafik tillåts visar iptables-loggar 12 försök från replikeringsinstansen vid ip=3.227.167.58):

Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

När du har tillåtit källändpunktens IP-adress (3.227.167.58) lyckas anslutningstestet och konfigurationen av källändpunkten är klar. Vi har även en SSL-anslutning för att kryptera trafiken genom publika nätverk. Detta kan bekräftas på PostgreSQL-servern med hjälp av frågan nedan samt i AWS-konsolen:

postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';

datname | usename | client_addr | ssl | cipher | query | query_start

---------+---------+-------------+-----+--------+-------+-------------

(0 rows)

...och titta sedan på medan du kör anslutningen från AWS-konsolen. Resultaten bör se ut som följande:

postgres=# \watch



                                                                           Sun 19 Jan 2020 06:50:51 PM PST (every 2s)



    datname     | usename | client_addr | ssl |           cipher |                 query | query_start

----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------

 nextcloud_prod | s9sdemo | 127.0.0.1   | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08

(1 row)

...medan AWS-konsolen borde rapportera en framgång:

Som anges i avsnittet förutsättningar, om vi väljer migreringsalternativet Full load , pågående replikering, kommer vi att behöva ändra behörigheterna för PostgreSQL-användaren. Det här migreringsalternativet kräver superanvändarprivilegier, därför justerade jag inställningarna för PostgreSQL-användaren som skapades tidigare:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

-----------+------------+-----------

s9sdemo   | Superuser  | {}

Samma dokument innehåller instruktioner för att ändra postgresql.conf. Här är en skillnad från den ursprungliga:

--- a/var/lib/pgsql/data/postgresql.conf

+++ b/var/lib/pgsql/data/postgresql.conf

@@ -95,7 +95,7 @@ max_connections = 100                 # (change requires restart)



# - SSL -



-#ssl = off

+ssl = on

#ssl_ca_file = ''

#ssl_cert_file = 'server.crt'

#ssl_crl_file = ''

@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix  # the default is the first option



# - Settings -



+wal_level = logical

#wal_level = replica                   # minimal, replica, or logical

                                       # (change requires restart)

#fsync = on                            # flush data to disk for crash safety

@@ -239,6 +240,7 @@ min_wal_size = 80MB

#max_wal_senders = 10          # max number of walsender processes

                              # (change requires restart)

#wal_keep_segments = 0         # in logfile segments; 0 disables

+wal_sender_timeout = 0

#wal_sender_timeout = 60s      # in milliseconds; 0 disables



#max_replication_slots = 10    # max number of replication slots

@@ -451,6 +453,7 @@ log_rotation_size = 0                       # Automatic rotation of logfiles will

#log_duration = off

#log_error_verbosity = default         # terse, default, or verbose messages

Sistligen, glöm inte att justera inställningarna för pg_hba.conf för att tillåta SSL-anslutning från replikeringsinstansens IP-adress.

Vi är nu redo för nästa steg.

Målslutpunkt

Följ guiden för att skapa målslutpunkten:

Det här steget förutsätter att RDS-instansen med den angivna slutpunkten redan existerar tillsammans med den tomma databasen nextcloud_awsdms. Databasen kan skapas under installationen av RDS-instansen.

Vid det här laget, om AWS-nätverket är korrekt konfigurerat, bör vi vara redo att köra anslutningstestet:

Med miljön på plats är det nu dags att skapa migreringsuppgiften :

Migreringsuppgift

När guiden är klar ser konfigurationen ut så här:

...och den andra delen av samma vy:

När uppgiften har startat kan vi övervaka framstegen — öppna upp uppgiften detaljer och scrolla ned till Tabellstatistik:

 AWS DMS använder det cachade schemat för att migrera databastabellerna. Medan migreringen fortskrider kan vi fortsätta att "bevaka" frågorna i källdatabasen och PostgreSQL-felloggen, förutom AWS-konsolen:

I händelse av fel visas feltillståndet i konsolen:

En plats att leta efter ledtrådar på är CloudWatch, även om loggarna under mina tester slutade inte med att publiceras, vilket sannolikt bara kan vara ännu ett fel i betaversionen av AWS DMS 3.3.0 som det visade sig vara mot slutet av den här övningen:

Migreringsförloppet visas snyggt i AWS DMS-konsolen:

När migreringen är klar, granska en gång till, PostgreSQL-felloggen , avslöjar ett överraskande meddelande:

Vad som verkar hända är att i PostgreSQL 9.6, 10 tabellen pg_class innehåller den namngivna kolumnen relhaspkey, men det är inte fallet i 11. Och det är felet i betaversionen av AWS DMS 3.3.0 som jag syftade på tidigare.

GCP

Googles tillvägagångssätt är baserat på verktyget PgBouncer med öppen källkod. Spänningen var kortvarig, eftersom den officiella dokumentationen talar om att migrera PostgreSQL till en datormiljö.

Ytterligare försök att hitta en migreringslösning till Cloud SQL som liknar AWS DMS misslyckades. Databasmigreringsstrategierna innehåller ingen hänvisning till PostgreSQL:

På plats PostgreSQL-installationer kan migreras till Cloud SQL genom att använda tjänsterna från en av Google Cloud-partnerna.

En potentiell lösning kan vara PgBouncer till Cloud SQL, men det är inte inom ramen för denna blogg.

Microsoft Cloud Services (Azure)

För att underlätta migreringen av PostgreSQL-arbetsbelastningar från on-prem till den hanterade Azure-databasen för PostgreSQL tillhandahåller Microsoft Azure DMS som enligt dokumentation kan användas för att migrera med minimal driftstopp. Handledningen Migrera PostgreSQL till Azure Database for PostgreSQL online med DMS beskriver dessa steg i detalj.

Azure DMS-dokumentationen diskuterar mycket detaljerat de problem och begränsningar som är förknippade med att migrera PostgreSQL-arbetsbelastningarna till Azure.

En anmärkningsvärd skillnad mot AWS DMS är kravet att manuellt skapa schemat:

En demo av detta kommer att bli ämnet för en framtida blogg. Håll utkik.


  1. PARSE() vs TRY_PARSE() i SQL Server:Vad är skillnaden?

  2. Microsoft SQL Server 2005/2008:XML vs text/varchar datatyp

  3. Fråga jämföra datum i SQL

  4. Att lägga till en kolumn som en främmande nyckel ger ERROR kolumn som refereras i främmande nyckel begränsning existerar inte