PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Мигриране на PostgreSQL към облака – Сравняване на решения от Amazon, Google и Microsoft

От птичи поглед изглежда, че когато става въпрос за мигриране на работните натоварвания на PostgreSQL в облака, изборът на доставчик на облак не трябва да има разлика. Извън кутията PostgreSQL улеснява репликирането на данни, без прекъсване, чрез логическа репликация, макар и с някои ограничения. За да направят своите услуги, предлагащи по-привлекателни облачни доставчици, може да изработят някои от тези ограничения. Когато започнем да мислим за разликите в наличните версии на PostgreSQL, съвместимост, ограничения, ограничения и производителност, става ясно, че услугите за миграция са ключови фактори в цялостното предлагане на услуги. Вече не става дума за „ние го предлагаме, ние го мигрираме“. Стана по-скоро като „ние го предлагаме, ние го мигрираме, с най-малко ограничения“.

Миграцията е важна както за малки, така и за големи организации. Не става дума толкова за размера на клъстера PostgreSQL, колкото за приемливото време на престой и усилията след миграция.

Избор на стратегия

Стратегията за миграция трябва да вземе предвид размера на базата данни, мрежовата връзка между източника и целта, както и инструментите за миграция, предлагани от доставчика на облака.

Хардуер или софтуер?

Точно както изпращането на USB ключове и DVD дискове в ранните дни на Интернет, в случаите, когато честотната лента на мрежата не е достатъчна за прехвърляне на данни с желаната скорост, доставчиците на облак предлагат хардуерни решения, способни за пренасяне на до стотици петабайта данни. По-долу са настоящите решения от всяко от големите три:

Удобна таблица, предоставена от Google, показваща наличните опции:

GCP устройство е Transfer Appliance

Подобна препоръка от Azure въз основа на размера на данните спрямо мрежовата честотна лента:

Уредът Azure е поле за данни

Към края на своята страница за мигриране на данни, AWS предоставя поглед върху това, което можем да очакваме, заедно с тяхната препоръка за решението:

В случаите, когато размерите на базата данни надвишават 100 GB и ограничена мрежова честотна лента AWS предлага хардуерно решение.

Уредът AWS е Snowball Edge

Експортиране/Импортиране на данни

Организациите, които толерират престой, могат да се възползват от простотата на обичайните инструменти, предоставени от PostgreSQL от кутията. Въпреки това, когато мигрирате данни от един доставчик на облак (или хостинг) към друг доставчик на облак, внимавайте за разходите за изход.

AWS

За тестване на миграциите използвах локална инсталация на моята база данни Nextcloud, работеща на един от сървърите на домашната ми мрежа:

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)

Също така създадох потребител на PostgreSQL, който да се използва от AWS DMS, която е услуга на Amazon за импортиране на PostgreSQL в Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

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

s9sdemo   |   | {nextcloud}

AWS DMS предоставя много предимства, точно както бихме очаквали от управлявано решение в облака: 

  • автоматично мащабиране (само за съхранение, тъй като изчислителният екземпляр трябва да е с правилния размер)
  •  автоматично предоставяне
  •  модел на разплащане
  •  автоматично преминаване при отказ

Въпреки това, поддържането на последователност на данните за жива база данни е най-доброто усилие. 100% последователност се постига само когато базата данни е в режим само за четене — това е следствие от това как се улавят промените в таблицата.

С други думи, таблиците имат различен преход към момента:

Точно както за всичко в облака, има разходи, свързани с миграционна служба.

За да създадете средата за мигриране, следвайте ръководството Първи стъпки, за да настроите екземпляр за репликация, източник, целева крайна точка и една или повече задачи.

Екземпляр на репликация

Създаването на екземпляр за репликация е лесно за всеки, запознат с EC2 екземпляри в AWS:

Единствената промяна от настройките по подразбиране беше при избора на AWS DMS 3.3.0 или по-късно, тъй като моят локален PostgreSQL двигател е 11.5:

И ето списъка с наличните в момента версии на AWS DMS:

Големите инсталации също трябва да вземат под внимание ограниченията на AWS DMS:

Има и набор от ограничения, които са следствие от логическа репликация на PostgreSQL ограничения. Например, AWS DMS няма да мигрира вторични обекти:

Заслужава да се спомене, че в PostgreSQL всички индекси са вторични индекси и че не е лошо нещо, както е отбелязано в тази по-подробна дискусия.

Крайна точка на източника

Следвайте съветника, за да създадете изходната крайна точка:

В сценария за настройка Конфигурация за мрежа към VPC Използване на интернет my домашната мрежа изисква няколко настройки, за да позволя на IP адреса на крайната точка на източника да има достъп до вътрешния ми сървър. Първо, създадох пренасочване на портове на граничния рутер (173.180.222.170), за да изпращам трафик на порт 30485 към моя вътрешен шлюз (10.11.11.241) на порт 5432, където мога да настроя фино достъпа въз основа на IP адреса на източника чрез правилата на iptables. Оттам мрежовият трафик преминава през SSH тунел към уеб сървъра, работещ с базата данни PostgreSQL. С описаната конфигурация client_addr в изхода на pg_stat_activity ще се покаже като 127.0.0.1.

Преди да разрешат входящия трафик, регистрационните файлове на iptables показват 12 опита от екземпляр на репликация при 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

След като разрешите IP адреса на крайната точка на източника (3.227.167.58), тестът на връзката е успешен и конфигурацията на крайната точка на източника е завършена. Имаме и SSL връзка, за да криптираме трафика през публични мрежи. Това може да се потвърди на сървъра на PostgreSQL с помощта на заявката по-долу, както и в конзолата на 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)

...и след това гледайте, докато изпълнявате връзката от конзолата на AWS. Резултатите трябва да изглеждат подобно на следното:

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)

...докато конзолата на AWS трябва да отчете успех:

Както е посочено в раздела с предпоставки, ако изберем опцията за мигриране Пълно натоварване , текуща репликация, ще трябва да променим разрешенията за потребителя на PostgreSQL. Тази опция за миграция изисква привилегии на суперпотребител, затова коригирах настройките за потребителя на PostgreSQL, създаден по-рано:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

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

s9sdemo   | Superuser  | {}

Същият документ съдържа инструкции за модифициране на postgresql.conf. Ето разлика от оригинала:

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

Накрая, не забравяйте да коригирате настройките на pg_hba.conf, за да разрешите SSL връзка от IP адреса на копие на копие.

Вече сме готови за следващата стъпка.

Целева крайна точка

Следвайте съветника, за да създадете целевата крайна точка:

Тази стъпка предполага, че RDS екземплярът с посочената крайна точка вече съществува заедно с празната база данни nextcloud_awsdms. Базата данни може да бъде създадена по време на настройката на RDS екземпляр.

В този момент, ако мрежата на AWS е настроена правилно, трябва да сме готови да изпълним теста на връзката:

С средата вече е време да създадете задачата за миграция :

Задача за мигриране

След като съветникът завърши конфигурацията изглежда така:

...и втората част от същия изглед:

След като задачата е стартирана, можем да наблюдаваме напредъка — отворете задачата подробности и превъртете надолу до Таблица Статистика:

 AWS DMS използва кешираната схема, за да мигрира таблиците на базата данни. Докато миграцията напредва, можем да продължим да „наблюдаваме“ заявките в изходната база данни и журнала за грешки на PostgreSQL, в допълнение към конзолата на AWS:

В случай на грешки, състоянието на грешка се показва в конзолата:

Едно място за търсене на улики е CloudWatch, въпреки че по време на моите тестове регистрационните файлове не беше публикуван, което вероятно може да е просто още един бъг в бета версията на AWS DMS 3.3.0, както се оказа към края на това упражнение:

Напредъкът на миграцията е добре показан в конзолата на AWS DMS:

След като миграцията приключи, прегледайте още веднъж, журнала за грешки на PostgreSQL , разкрива изненадващо съобщение:

Това, което изглежда се случва, е, че в PostgreSQL 9.6, 10 таблицата pg_class съдържа поименната колона relhaspkey, но това не е така в 11. И това е грешката в бета версията на AWS DMS 3.3.0, за която споменах по-рано.

GCP

Подходът на Google се основава на инструмента с отворен код PgBouncer. Вълнението беше краткотрайно, тъй като в официалната документация се говори за мигриране на PostgreSQL в среда на изчислителна машина.

По-нататъшни опити за намиране на решение за мигриране към Cloud SQL, което наподобява AWS DMS, не успяха. Стратегиите за миграция на база данни не съдържат препратка към PostgreSQL:

Постоянните инсталации на PostgreSQL могат да бъдат мигрирани към Cloud SQL с помощта на услугите на един от партньорите на Google Cloud.

Потенциално решение може да бъде PgBouncer към Cloud SQL, но това не е в обхвата на този блог.

Облачни услуги на Microsoft (Azure)

За да се улесни миграцията на натоварвания на PostgreSQL от on-prem към управляваната база данни Azure за PostgreSQL, Microsoft предоставя Azure DMS, който според документацията може да се използва за мигриране с минимално време на престой. Урокът Мигриране на PostgreSQL към Azure база данни за PostgreSQL онлайн с помощта на DMS описва тези стъпки подробно.

Документацията на Azure DMS обсъжда много подробно проблемите и ограниченията, свързани с мигрирането на работните натоварвания на PostgreSQL в Azure.

Една забележителна разлика от AWS DMS е изискването за ръчно създаване на схемата:

Демонстрация на това ще бъде тема на бъдещ блог. Останете на линия.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Опитвам се да копирам файл, но получавам съобщение за грешка

  2. Изтриване на PostgreSQL с вътрешно присъединяване

  3. CS50:LIKE оператор, заместване на променлива с % разширение

  4. Опции за аварийно възстановяване за PostgreSQL, разгърнат в хибриден облак

  5. Използвайте множество конфликт_цели в клауза ON CONFLICT