sql >> Database teknologi >  >> RDS >> PostgreSQL

Migrering af PostgreSQL til skyen - Sammenligning af løsninger fra Amazon, Google og Microsoft

Fra et fugleperspektiv ser det ud til, at når det kommer til at migrere PostgreSQL-arbejdsbelastningerne til skyen, burde valget af cloud-udbyder ikke gøre nogen forskel. Ud af boksen gør PostgreSQL det nemt at replikere data, uden nedetid, via logisk replikering, dog med nogle begrænsninger. For at gøre deres servicetilbud mere attraktive kan cloududbydere finde ud af nogle af disse begrænsninger. Når vi begynder at tænke på forskelle i de tilgængelige PostgreSQL-versioner, kompatibilitet, begrænsninger, begrænsninger og ydeevne, bliver det klart, at migreringstjenesterne er nøglefaktorer i det overordnede serviceudbud. Det er ikke længere et tilfælde af "vi tilbyder det, vi migrerer det". Det er blevet mere som "vi tilbyder det, vi migrerer det, med de mindste begrænsninger".

Migration er vigtig for både små og store organisationer. Det handler ikke så meget om størrelsen af ​​PostgreSQL-klyngen, som det handler om den acceptable nedetid og post-migreringsindsats.

Valg af en strategi

Migreringsstrategien bør tage højde for størrelsen af ​​databasen, netværksforbindelsen mellem kilden og målet, samt de migreringsværktøjer, som skyudbyderen tilbyder.

Hardware eller software?

Ligesom at sende USB-nøgler og DVD'er tilbage i de tidlige dage af internettet, i tilfælde, hvor netværksbåndbredden ikke er nok til at overføre data med den ønskede hastighed, tilbyder cloud-udbydere hardwareløsninger, der kan at bære op til hundredvis af petabyte data. Nedenfor er de aktuelle løsninger fra hver af de tre store:

En praktisk tabel leveret af Google, der viser de tilgængelige muligheder:

GCP-enhed er Transfer Appliance

En lignende anbefaling fra Azure baseret på datastørrelsen i forhold til netværksbåndbredden:

Azure-enheden er databoks

Mod slutningen af ​​sin datamigreringsside giver AWS et glimt af, hvad vi kan forvente, sammen med deres anbefaling af løsningen:

I tilfælde, hvor databasestørrelserne overstiger 100 GB og begrænset netværksbåndbredde, foreslår AWS en hardwareløsning.

AWS-apparatet er Snowball Edge

Dataeksport/import

Organisationer, der tolererer nedetid, kan drage fordel af enkelheden ved almindelige værktøjer leveret af PostgreSQL ud af boksen. Men når du migrerer data fra en cloud- (eller hosting)-udbyder til en anden cloud-udbyder, skal du være opmærksom på omkostningerne ved udgang.

AWS

Til at teste migreringerne brugte jeg en lokal installation af min Nextcloud-database, der kørte på en af ​​mine hjemmenetværksservere:

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)

Jeg har også oprettet en PostgreSQL-bruger, der skal bruges af AWS DMS, som er Amazons service til at importere PostgreSQL til Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

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

s9sdemo   |   | {nextcloud}

AWS DMS giver mange fordele, ligesom vi ville forvente af en administreret løsning i skyen: 

  • automatisk skalering (kun lagring, da computerforekomst skal have den rigtige størrelse)
  •  automatisk klargøring
  •  pay-as-you-go-model
  •  automatisk failover

Men det er bedst at opretholde datakonsistens for en live database. En 100 % konsistens opnås kun, når databasen er i skrivebeskyttet tilstand - det er en konsekvens af, hvordan tabelændringer fanges.

Med andre ord, tabeller har en anden tidsgrænse:

Ligesom med alt i skyen er der en omkostning forbundet med migrationstjeneste.

For at oprette migreringsmiljøet skal du følge vejledningen Kom godt i gang for at konfigurere en replikeringsinstans, en kilde, et målslutpunkt og en eller flere opgaver.

replikeringsinstans

Oprettelse af replikeringsforekomsten er ligetil for alle, der er bekendt med EC2-forekomster på AWS:

Den eneste ændring fra standardindstillingerne var at vælge AWS DMS 3.3.0 eller senere på grund af at min lokale PostgreSQL-motor er 11.5:

Og her er listen over tilgængelige AWS DMS-versioner:

Store installationer bør også være opmærksomme på AWS DMS-grænserne:

Der er også et sæt begrænsninger, der er en konsekvens af PostgreSQL logiske replikering restriktioner. For eksempel vil AWS DMS ikke migrere sekundære objekter:

Det er værd at nævne, at i PostgreSQL er alle indekser sekundære indekser, og at er ikke en dårlig ting, som nævnt i denne mere detaljerede diskussion.

Kildeslutpunkt

Følg guiden for at oprette kildeslutpunktet:

I opsætningsscenariet Konfiguration for et netværk til en VPC Brug af internettet min hjemmenetværket krævede et par justeringer for at give kildeslutpunktets IP-adresse adgang til min interne server. Først oprettede jeg en port forwarding på edge-routeren (173.180.222.170) for at sende trafik på port 30485 til min interne gateway (10.11.11.241) på port 5432, hvor jeg kan finjustere adgangen baseret på kildens IP-adresse via iptables regler. Derfra strømmer netværkstrafik gennem en SSH-tunnel til webserveren, der kører PostgreSQL-databasen. Med den beskrevne konfiguration vil client_addr i outputtet af pg_stat_activity vises som 127.0.0.1.

Før indgående trafik tillades, viser iptables-logfiler 12 forsøg fra replikeringsforekomst på 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 tilladt kildeslutpunktets IP-adresse (3.227.167.58), lykkes forbindelsestesten, og kildeslutpunktets konfiguration er fuldført. Vi har også en SSL-forbindelse for at kryptere trafikken gennem offentlige netværk. Dette kan bekræftes på PostgreSQL-serveren ved hjælp af forespørgslen nedenfor samt i AWS-konsollen:

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)

...og se derefter, mens du kører forbindelsen fra AWS-konsollen. Resultaterne skulle ligne følgende:

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)

...mens AWS-konsollen skulle rapportere en succes:

Som angivet i forudsætningssektionen, hvis vi vælger migreringsindstillingen Fuld load , løbende replikering, bliver vi nødt til at ændre tilladelserne for PostgreSQL-brugeren. Denne migreringsindstilling kræver superbrugerrettigheder, derfor har jeg justeret indstillingerne for PostgreSQL-brugeren, der blev oprettet tidligere:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

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

s9sdemo   | Superuser  | {}

Det samme dokument indeholder instruktioner til ændring af postgresql.conf. Her er en forskel fra den originale:

--- 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

Glem endelig ikke at justere pg_hba.conf-indstillingerne for at tillade SSL-forbindelse fra replikeringsinstansens IP-adresse.

Vi er nu klar til næste trin.

Målendepunkt

Følg guiden for at oprette målendepunktet:

Dette trin antager, at RDS-instansen med det angivne slutpunkt allerede eksisterer sammen med den tomme database nextcloud_awsdms. Databasen kan oprettes under opsætningen af ​​RDS-instansen.

På dette tidspunkt, hvis AWS-netværket er korrekt opsat, skulle vi være klar til at køre forbindelsestesten:

Med miljøet på plads er det nu tid til at oprette migreringsopgaven :

Migreringsopgave

Når guiden er færdig, ser konfigurationen sådan ud:

...og den anden del af samme visning:

Når opgaven er startet, kan vi overvåge fremskridtene — åbn opgaven detaljer og rul ned til Tabelstatistik:

 AWS DMS bruger det cachelagrede skema til at migrere databasetabellerne. Mens migreringen skrider frem, kan vi fortsætte med at "se" forespørgslerne på kildedatabasen og PostgreSQL-fejlloggen ud over AWS-konsollen:

I tilfælde af fejl vises fejltilstanden i konsollen:

Et sted at lede efter spor er CloudWatch, selvom logfilerne under mine tests endte ikke med at blive offentliggjort, hvilket sandsynligvis bare kunne være endnu en fejl i betaversionen af ​​AWS DMS 3.3.0, som det viste sig at være mod slutningen af ​​denne øvelse:

Migreringsforløbet vises pænt i AWS DMS-konsollen:

Når migreringen er fuldført, gennemgår PostgreSQL-fejlloggen en gang mere , afslører en overraskende besked:

Det, der ser ud til at ske, er, at i PostgreSQL 9.6, 10 tabellen pg_class indeholder den navngivne kolonne relhaspkey, men det er ikke tilfældet i 11. Og det er fejlen i betaversionen af ​​AWS DMS 3.3.0, som jeg henviste til tidligere.

GCP

Googles tilgang er baseret på open source-værktøjet PgBouncer. Spændingen varede kort, da den officielle dokumentation taler om migrering af PostgreSQL til et computermiljø.

Yderligere forsøg på at finde en migreringsløsning til Cloud SQL, der ligner AWS DMS, mislykkedes. Databasemigreringsstrategierne indeholder ingen henvisning til PostgreSQL:

On-prem PostgreSQL-installationer kan migreres til Cloud SQL ved at bruge tjenesterne fra en af ​​Google Cloud-partnerne.

En potentiel løsning kan være PgBouncer til Cloud SQL, men det er ikke inden for denne blogs rammer.

Microsoft Cloud Services (Azure)

For at lette migreringen af ​​PostgreSQL-arbejdsbelastninger fra on-prem til den administrerede Azure-database for PostgreSQL leverer Microsoft Azure DMS, som ifølge dokumentationen kan bruges til at migrere med minimal nedetid. Selvstudiet Migrer PostgreSQL til Azure Database for PostgreSQL online ved hjælp af DMS beskriver disse trin i detaljer.

Azure DMS-dokumentationen diskuterer meget detaljeret de problemer og begrænsninger, der er forbundet med migrering af PostgreSQL-arbejdsbelastninger til Azure.

En bemærkelsesværdig forskel fra AWS DMS er kravet om manuelt at oprette skemaet:

En demo af dette vil være emnet for en fremtidig blog. Følg med.


  1. Inkrementel statistik indsamling i 11g

  2. Android Room - Sådan nulstiller du automatisk genereret tabel primær nøgle ved hver appkørsel

  3. Forståelse af transaktioner i SQL

  4. Oracle Slet rækker, der matcher flere værdier