sql >> Databáze >  >> RDS >> PostgreSQL

Migrace PostgreSQL do cloudu – porovnání řešení od Amazonu, Google a Microsoftu

Z ptačí perspektivy by se zdálo, že pokud jde o migraci zátěže PostgreSQL do cloudu, na výběru poskytovatele cloudu by neměl být žádný rozdíl. PostgreSQL po vybalení usnadňuje replikaci dat bez prostojů prostřednictvím logické replikace, i když s určitými omezeními. Aby byla nabídka jejich služeb atraktivnější, poskytovatelé cloudu mohou některá z těchto omezení vyřešit. Když začneme přemýšlet o rozdílech v dostupných verzích PostgreSQL, kompatibilitě, limitech, omezeních a výkonu, je jasné, že migrační služby jsou klíčovými faktory v celkové nabídce služeb. Už to není případ „nabízíme to, migrujeme to“. Stává se to spíše jako „nabízíme to, migrujeme to s nejmenšími omezeními“.

Migrace je důležitá pro malé i velké organizace. Nejde ani tak o velikost clusteru PostgreSQL, jako o přijatelné prostoje a úsilí po migraci.

Výběr strategie

Strategie migrace by měla brát v úvahu velikost databáze, síťové propojení mezi zdrojem a cílem a také migrační nástroje nabízené poskytovatelem cloudu.

Hardware nebo software?

Stejně jako zasílání USB klíčů a DVD v počátcích internetu, v případech, kdy šířka pásma sítě nestačí pro přenos dat požadovanou rychlostí, nabízejí poskytovatelé cloudu hardwarová řešení, která přenášet až stovky petabajtů dat. Níže jsou uvedena aktuální řešení z každé z velkých tří:

Praktická tabulka od společnosti Google s dostupnými možnostmi:

Zařízení GCP je přenosové zařízení

Podobné doporučení od Azure na základě velikosti dat vs. šířka pásma sítě:

Zařízení Azure je datová schránka

Na konci své stránky migrace dat poskytuje AWS letmý pohled na to, co můžeme očekávat, spolu s doporučením řešení:

V případech, kdy velikost databáze přesahuje 100 GB a omezená šířka pásma sítě, doporučuje AWS hardwarové řešení.

Zařízení AWS je Snowball Edge

Export/import dat

Organizace, které tolerují prostoje, mohou těžit z jednoduchosti běžných nástrojů poskytovaných PostgreSQL ihned po vybalení. Při migraci dat od jednoho cloudového (nebo hostingového) poskytovatele k jinému cloudovému poskytovateli si však dejte pozor na výstupní náklady.

AWS

Pro testování migrací jsem použil místní instalaci databáze Nextcloud běžící na jednom z mých serverů domácí sítě:

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)

Vytvořil jsem také uživatele PostgreSQL, kterého bude používat AWS DMS, což je služba Amazonu pro import PostgreSQL do Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

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

s9sdemo   |   | {nextcloud}

AWS DMS poskytuje mnoho výhod, stejně jako bychom očekávali od spravovaného řešení v cloudu: 

  • automatické škálování (pouze úložiště, protože instance výpočtu musí mít správnou velikost)
  •  automatické zajišťování
  •  model s průběžnými platbami
  •  automatické převzetí služeb při selhání

Nejlepším úsilím je však zachování konzistence dat pro živou databázi. 100% konzistence je dosaženo pouze tehdy, když je databáze v režimu pouze pro čtení – to je důsledek toho, jak jsou zaznamenávány změny v tabulce.

Jinými slovy, tabulky mají jiný časový úsek:

Stejně jako se vším v cloudu existují náklady spojené s migrační službu.

Chcete-li vytvořit prostředí migrace, postupujte podle příručky Začínáme a nastavte instanci replikace, zdroj, cílový koncový bod a jednu nebo více úloh.

Instance replikace

Vytvoření instance replikace je snadné pro každého, kdo zná instance EC2 na AWS:

Jediná změna oproti výchozímu nastavení byla ve výběru AWS DMS 3.3.0 resp. později kvůli mému místnímu PostgreSQL enginu 11.5:

A zde je seznam aktuálně dostupných verzí AWS DMS:

Velké instalace by také měly brát na vědomí limity AWS DMS:

Existuje také soubor omezení, která jsou důsledkem logické replikace PostgreSQL omezení. Například AWS DMS nebude migrovat sekundární objekty:

Za zmínku stojí, že v PostgreSQL jsou všechny indexy sekundárními indexy, a to není špatná věc, jak je uvedeno v této podrobnější diskusi.

Koncový bod zdroje

Podle průvodce vytvořte zdrojový koncový bod:

Ve scénáři nastavení Konfigurace pro síť na VPC pomocí internetu domácí síť vyžadovala několik vylepšení, aby IP adresa zdrojového koncového bodu mohla přistupovat k mému internímu serveru. Nejprve jsem vytvořil přesměrování portů na okrajovém routeru (173.180.222.170), abych posílal provoz na portu 30485 na mou interní bránu (10.11.11.241) na port 5432, kde mohu doladit přístup na základě zdrojové IP adresy pomocí pravidel iptables. Odtud síťový provoz proudí tunelem SSH na webový server, na kterém běží databáze PostgreSQL. S popsanou konfigurací se client_addr ve výstupu pg_stat_activity zobrazí jako 127.0.0.1.

Před povolením příchozího provozu vykazují protokoly iptables 12 pokusů z instance replikace na adrese 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

Jakmile povolíte IP adresu zdrojového koncového bodu (3.227.167.58), bude test připojení úspěšný a konfigurace zdrojového koncového bodu je dokončena. Máme také připojení SSL, abychom šifrovali provoz přes veřejné sítě. To lze potvrdit na serveru PostgreSQL pomocí níže uvedeného dotazu a také v konzole AWS:

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)

…a pak se dívejte, zatímco spouštíte připojení z konzoly AWS. Výsledky by měly vypadat podobně jako následující:

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)

…zatímco konzole AWS by měla hlásit úspěch:

Jak je uvedeno v části předpoklady, pokud zvolíme možnost migrace Plné zatížení , probíhající replikace, budeme muset změnit oprávnění pro uživatele PostgreSQL. Tato možnost migrace vyžaduje oprávnění superuživatele, proto jsem upravil nastavení pro uživatele PostgreSQL vytvořeného dříve:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

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

s9sdemo   | Superuser  | {}

Stejný dokument obsahuje pokyny pro úpravu postgresql.conf. Zde je rozdíl od původního:

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

Nezapomeňte upravit nastavení pg_hba.conf, abyste povolili připojení SSL z IP adresy instance replikace.

Nyní jsme připraveni na další krok.

Cílový koncový bod

Vytvořte cílový koncový bod podle průvodce:

Tento krok předpokládá, že instance RDS se zadaným koncovým bodem již existuje spolu s prázdnou databázi nextcloud_awsdms. Databázi lze vytvořit během instalace instance RDS.

Pokud je v tuto chvíli síť AWS správně nastavena, měli bychom být připraveni spustit test připojení:

S připraveným prostředím je nyní čas vytvořit úlohu migrace :

Úkol migrace

Jakmile průvodce dokončí konfiguraci, vypadá takto:

...a druhá část stejného zobrazení:

Jakmile je úloha spuštěna, můžeme sledovat její průběh — otevřít úlohu podrobnosti a přejděte dolů na Statistiku tabulky:

 AWS DMS používá k migraci databázových tabulek schéma uložené v mezipaměti. Zatímco migrace pokračuje, můžeme kromě konzole AWS pokračovat ve „sledování“ dotazů ve zdrojové databázi a protokolu chyb PostgreSQL:

V případě chyb se stav selhání zobrazí v konzole:

Jedno místo, kde hledat vodítka, je CloudWatch, i když během mých testů protokoly neskončilo zveřejnění, což by pravděpodobně mohla být jen další závada v beta verzi AWS DMS 3.3.0, jak se ukázalo ke konci tohoto cvičení:

Průběh migrace je pěkně zobrazen v konzole AWS DMS:

Po dokončení migrace ještě jednou zkontrolujte protokol chyb PostgreSQL , odhaluje překvapivou zprávu:

Zdá se, že se v PostgreSQL 9.6, 10 stane tabulka pg_class obsahuje pojmenovaný sloupec relhaspkey, ale to není případ 11. A to je chyba v beta verzi AWS DMS 3.3.0, na kterou jsem odkazoval dříve.

GCP

Přístup společnosti Google je založen na open source nástroji PgBouncer. Nadšení mělo krátké trvání, protože oficiální dokumentace hovoří o migraci PostgreSQL do prostředí výpočetního enginu.

Další pokusy o nalezení řešení migrace na Cloud SQL, které se podobá AWS DMS, se nezdařily. Strategie migrace databáze neobsahují žádný odkaz na PostgreSQL:

Vlastní instalace PostgreSQL lze migrovat na Cloud SQL pomocí služeb jednoho z partnerů Google Cloud.

Potenciálním řešením může být PgBouncer to Cloud SQL, ale to nespadá do rozsahu tohoto blogu.

Microsoft Cloud Services (Azure)

Aby se usnadnila migrace úloh PostgreSQL z on-prem do spravované Azure Database for PostgreSQL, Microsoft poskytuje Azure DMS, který lze podle dokumentace použít k migraci s minimálními prostoji. Tyto kroky podrobně popisuje výukový program Migrace PostgreSQL do Azure Database for PostgreSQL online pomocí DMS.

Dokumentace Azure DMS velmi podrobně popisuje problémy a omezení spojená s migrací úloh PostgreSQL do Azure.

Jeden významný rozdíl oproti AWS DMS je požadavek na ruční vytvoření schématu:

Ukázka tohoto bude tématem budoucího blogu. Zůstaňte naladěni.


  1. Udělit výběr u všech stolů vlastněných konkrétním uživatelem

  2. Jak snadno vytvořit jednoduchý CRUD pomocí PHP a MySQL

  3. Získání čísla týdne z data v MS SQL Server 2005?

  4. Přidejte interval k časové značce pomocí Ecto fragmentů