sql >> Database >  >> RDS >> PostgreSQL

PostgreSQL migreren naar de cloud - oplossingen van Amazon, Google en Microsoft vergelijken

Vanuit een vogelperspectief lijkt het erop dat als het gaat om het migreren van de PostgreSQL-workloads naar de cloud, de keuze van de cloudprovider geen verschil zou moeten maken. Out-of-the-box maakt PostgreSQL het gemakkelijk om gegevens te repliceren, zonder downtime, via logische replicatie, hoewel met enkele beperkingen. Om hun serviceaanbod aantrekkelijker te maken, kunnen cloudproviders enkele van die beperkingen uitwerken. Als we beginnen na te denken over verschillen in de beschikbare PostgreSQL-versies, compatibiliteit, limieten, beperkingen en prestaties, wordt het duidelijk dat de migratieservices sleutelfactoren zijn in het algehele serviceaanbod. Het is niet langer een kwestie van "we bieden het aan, we migreren het". Het is meer geworden van "we bieden het aan, we migreren het, met de minste beperkingen".

Migratie is belangrijk voor zowel kleine als grote organisaties. Het gaat niet zozeer om de grootte van het PostgreSQL-cluster, maar om de acceptabele downtime en inspanning na de migratie.

Een strategie selecteren

De migratiestrategie moet rekening houden met de grootte van de database, de netwerkverbinding tussen de bron en het doel, evenals de migratietools die worden aangeboden door de cloudprovider.

Hardware of software?

Net zoals het versturen van USB-sleutels en dvd's in de begindagen van internet, in gevallen waar de netwerkbandbreedte niet voldoende is om gegevens met de gewenste snelheid over te dragen, bieden cloudproviders hardwareoplossingen die in staat zijn om tot honderden petabytes aan gegevens te vervoeren. Hieronder staan ​​de huidige oplossingen van elk van de grote drie:

Een handige tabel van Google met de beschikbare opties:

GCP-apparaat is Transfer Appliance

Een vergelijkbare aanbeveling van Azure op basis van de gegevensgrootte versus netwerkbandbreedte:

Azure-apparaat is databox

Tegen het einde van de pagina voor gegevensmigraties geeft AWS een glimp van wat we kunnen verwachten, samen met hun aanbeveling voor de oplossing:

In gevallen waarin de database groter is dan 100 GB en de netwerkbandbreedte beperkt is, suggereert AWS een hardware-oplossing.

AWS-apparaat is Snowball Edge

Gegevens exporteren/importeren

Organisaties die downtime tolereren, kunnen profiteren van de eenvoud van algemene tools die PostgreSQL uit de doos biedt. Let echter op de kosten voor uitgaand verkeer bij het migreren van gegevens van de ene cloud- (of hosting-)provider naar een andere cloudprovider.

AWS

Voor het testen van de migraties heb ik een lokale installatie van mijn Nextcloud-database gebruikt op een van mijn thuisnetwerkservers:

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)

Ik heb ook een PostgreSQL-gebruiker gemaakt voor gebruik door AWS DMS, de service van Amazon voor het importeren van PostgreSQL in Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

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

s9sdemo   |   | {nextcloud}

AWS DMS biedt veel voordelen, precies zoals we zouden verwachten van een beheerde oplossing in de cloud: 

  • automatisch schalen (alleen opslag, aangezien rekeninstantie de juiste grootte moet hebben)
  •  automatische registratie
  •  pay-as-you-go-model
  •  automatische failover

Het is echter de beste poging om de gegevensconsistentie voor een live database te behouden. Een consistentie van 100% wordt alleen bereikt als de database zich in de alleen-lezen modus bevindt - dat is een gevolg van de manier waarop tabelwijzigingen worden vastgelegd.

Met andere woorden, tabellen hebben een andere point-in-time cutover:

Net als bij alles in de cloud, zijn er kosten verbonden aan de migratieservice.

Om de migratieomgeving te maken, volgt u de handleiding Aan de slag om een ​​replicatie-instantie, een bron, een doeleindpunt en een of meer taken in te stellen.

Replicatie-instantie

Het maken van de replicatie-instantie is eenvoudig voor iedereen die bekend is met EC2-instanties op AWS:

De enige verandering ten opzichte van de standaardinstellingen was het selecteren van AWS DMS 3.3.0 of later omdat mijn lokale PostgreSQL-engine 11.5 is:

En hier is de lijst met momenteel beschikbare AWS DMS-versies:

Grote installaties moeten ook rekening houden met de AWS DMS-limieten:

Er is ook een reeks beperkingen die het gevolg zijn van logische PostgreSQL-replicatie beperkingen. AWS DMS migreert bijvoorbeeld geen secundaire objecten:

Het is vermeldenswaard dat in PostgreSQL alle indexen secundaire indexen zijn, en dat is geen slechte zaak, zoals opgemerkt in deze meer gedetailleerde discussie.

Bron eindpunt

Volg de wizard om het broneindpunt te maken:

In het setup-scenario Configuratie voor een netwerk naar een VPC Internet gebruiken thuisnetwerk had een paar aanpassingen nodig om het IP-adres van het broneindpunt toegang te geven tot mijn interne server. Eerst heb ik een poortdoorschakeling op de edge-router (173.180.222.170) gemaakt om verkeer op poort 30485 naar mijn interne gateway (10.11.11.241) op poort 5432 te sturen, waar ik de toegang kan verfijnen op basis van het bron-IP-adres via iptables-regels. Van daaruit stroomt het netwerkverkeer via een SSH-tunnel naar de webserver waarop de PostgreSQL-database draait. Met de beschreven configuratie zal de client_addr in de uitvoer van pg_stat_activity verschijnen als 127.0.0.1.

Voordat inkomend verkeer wordt toegestaan, tonen iptables-logs 12 pogingen van replicatie-instantie op 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

Zodra het IP-adres van het bron-eindpunt (3.227.167.58) is toegestaan, is de verbindingstest geslaagd en is de configuratie van het bron-eindpunt voltooid. We hebben ook een SSL-verbinding om het verkeer via openbare netwerken te versleutelen. Dit kan worden bevestigd op de PostgreSQL-server met behulp van de onderstaande query en in de AWS-console:

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)

...en kijk dan terwijl je de verbinding uitvoert vanaf de AWS-console. De resultaten zouden er ongeveer als volgt uit moeten zien:

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)

...terwijl de AWS-console een succes zou moeten melden:

Zoals aangegeven in de sectie vereisten, als we de migratieoptie kiezen Volledig laden , voortdurende replicatie, moeten we de machtigingen voor de PostgreSQL-gebruiker wijzigen. Deze migratieoptie vereist superuser-privileges, daarom heb ik de instellingen voor de PostgreSQL-gebruiker die eerder zijn gemaakt aangepast:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

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

s9sdemo   | Superuser  | {}

Hetzelfde document bevat instructies voor het wijzigen van postgresql.conf. Hier is een verschil met de originele:

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

Vergeet ten slotte niet de pg_hba.conf-instellingen aan te passen om SSL-verbinding vanaf het IP-adres van de replicatie-instantie toe te staan.

We zijn nu klaar voor de volgende stap.

Doel eindpunt

Volg de wizard om het doeleindpunt te maken:

Bij deze stap wordt ervan uitgegaan dat de RDS-instantie met het opgegeven eindpunt al bestaat, samen met de lege database nextcloud_awsdms. De database kan worden aangemaakt tijdens het instellen van de RDS-instantie.

Als het AWS-netwerk correct is ingesteld, zouden we nu klaar moeten zijn om de verbindingstest uit te voeren:

Als de omgeving aanwezig is, is het nu tijd om de migratietaak te maken :

Migratietaak

Zodra de wizard is voltooid, ziet de configuratie er als volgt uit:

...en het tweede deel van dezelfde weergave:

Zodra de taak is gestart, kunnen we de voortgang volgen — open de taak details en scrol omlaag naar Tabelstatistieken:

 AWS DMS gebruikt het in de cache opgeslagen schema om de databasetabellen te migreren. Terwijl de migratie vordert, kunnen we de zoekopdrachten in de brondatabase en het PostgreSQL-foutlogboek blijven "bekijken", naast de AWS-console:

In geval van fouten wordt de foutstatus weergegeven in de console:

Een plek om naar aanwijzingen te zoeken is CloudWatch, hoewel tijdens mijn tests de logs werd uiteindelijk niet gepubliceerd, wat waarschijnlijk gewoon een andere storing in de bètaversie van de AWS DMS 3.3.0 zou kunnen zijn, zoals tegen het einde van deze oefening bleek te zijn:

De voortgang van de migratie wordt mooi weergegeven in de AWS DMS-console:

Zodra de migratie is voltooid, controleert u nog een keer het PostgreSQL-foutlogboek , onthult een verrassende boodschap:

Wat lijkt te gebeuren, is dat in PostgreSQL 9.6, 10 de pg_class-tabel bevat de benoemde kolom relhaspkey, maar dat is niet het geval in 11. En dat is de glitch in de bètaversie van AWS DMS 3.3.0 waar ik eerder naar verwees.

GCP

De aanpak van Google is gebaseerd op de open source-tool PgBouncer. De opwinding was van korte duur, aangezien de officiële documentatie spreekt over het migreren van PostgreSQL naar een compute engine-omgeving.

Verdere pogingen om een ​​migratieoplossing naar Cloud SQL te vinden die lijkt op AWS DMS zijn mislukt. De databasemigratiestrategieën bevatten geen verwijzing naar PostgreSQL:

On-prem PostgreSQL-installaties kunnen worden gemigreerd naar Cloud SQL met behulp van de services van een van de Google Cloud-partners.

Een mogelijke oplossing is misschien PgBouncer naar Cloud SQL, maar dat valt buiten het bestek van deze blog.

Microsoft Cloud Services (Azure)

Om de migratie van PostgreSQL-workloads van on-prem naar de beheerde Azure Database for PostgreSQL te vergemakkelijken, biedt Microsoft Azure DMS dat volgens documentatie kan worden gebruikt om te migreren met minimale downtime. De tutorial PostgreSQL migreren naar Azure Database for PostgreSQL online met DMS beschrijft deze stappen in detail.

De Azure DMS-documentatie bespreekt tot in detail de problemen en beperkingen die gepaard gaan met het migreren van de PostgreSQL-workloads naar Azure.

Een opmerkelijk verschil met AWS DMS is de vereiste om het schema handmatig te maken:

Een demo hiervan zal het onderwerp zijn van een toekomstige blog. Blijf op de hoogte.


  1. Hoe de RIGHT()-functie werkt in SQL Server (T-SQL)

  2. Hoe meerdere databases te verbinden in PHP, MYSQLi &PDO

  3. Casestudy van SQL Server Database Server Hardware-upgrade

  4. Waarom komt de varchar-sorteervolgorde van Oracle niet overeen met het gedrag van varchar-vergelijking?