Di chuyển PostgreSQL sang Đám mây - So sánh các giải pháp từ Amazon, Google và Microsoft

Từ cái nhìn tổng quan, có vẻ như khi chuyển khối lượng công việc PostgreSQL vào đám mây, lựa chọn nhà cung cấp đám mây sẽ không có gì khác biệt. Ngoài ra, PostgreSQL giúp dễ dàng sao chép dữ liệu, không có thời gian chết, thông qua Logical Replication, mặc dù có một số hạn chế. Để làm cho dịch vụ của họ cung cấp hấp dẫn hơn, các nhà cung cấp dịch vụ đám mây có thể giải quyết một số hạn chế đó. Khi chúng tôi bắt đầu suy nghĩ về sự khác biệt trong các phiên bản PostgreSQL có sẵn, khả năng tương thích, giới hạn, hạn chế và hiệu suất, rõ ràng là các dịch vụ di chuyển là yếu tố chính trong việc cung cấp dịch vụ tổng thể. Nó không còn là trường hợp "chúng tôi cung cấp nó, chúng tôi di chuyển nó". Nó giống như “chúng tôi cung cấp nó, chúng tôi di chuyển nó, với ít hạn chế nhất”.

Di chuyển rất quan trọng đối với các tổ chức lớn và nhỏ. Nó không liên quan nhiều đến kích thước của cụm PostgreSQL, vì nó là về thời gian ngừng hoạt động có thể chấp nhận được và nỗ lực sau khi di chuyển.

Chọn Chiến lược

Chiến lược di chuyển nên xem xét kích thước của cơ sở dữ liệu, liên kết mạng giữa nguồn và đích cũng như các công cụ di chuyển do nhà cung cấp đám mây cung cấp.

Phần cứng hay Phần mềm?

Cũng giống như việc gửi các khóa USB và DVD qua thư từ những ngày đầu của Internet, trong trường hợp băng thông mạng không đủ để truyền dữ liệu ở tốc độ mong muốn, các nhà cung cấp dịch vụ đám mây đang cung cấp các giải pháp phần cứng, có thể để mang đến hàng trăm petabyte dữ liệu. Dưới đây là các giải pháp hiện tại từ ba giải pháp lớn:

Một bảng tiện dụng do Google cung cấp hiển thị các tùy chọn có sẵn:

Thiết bị GCP là Công cụ chuyển

Một đề xuất tương tự từ Azure dựa trên kích thước dữ liệu so với băng thông mạng:

Công cụ Azure là Hộp dữ liệu

Đến cuối trang di chuyển dữ liệu, AWS cung cấp một cái nhìn sơ lược về những gì chúng ta có thể mong đợi, cùng với đề xuất của họ về giải pháp:

Trong trường hợp kích thước cơ sở dữ liệu vượt quá 100GB và băng thông mạng hạn chế, AWS đề xuất giải pháp phần cứng.

Thiết bị AWS là Snowball Edge

Xuất / Nhập dữ liệu

Các tổ chức chịu được thời gian chết có thể hưởng lợi từ sự đơn giản của các công cụ phổ biến do PostgreSQL cung cấp. Tuy nhiên, khi di chuyển dữ liệu từ một nhà cung cấp dịch vụ đám mây (hoặc lưu trữ) sang nhà cung cấp dịch vụ đám mây khác, hãy cẩn thận với chi phí đầu ra.

AWS

Để kiểm tra quá trình di chuyển, tôi đã sử dụng cài đặt cục bộ của cơ sở dữ liệu Nextcloud đang chạy trên một trong các máy chủ mạng gia đình của tôi:

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)

Tôi cũng đã tạo một người dùng PostgreSQL để AWS DMS sử dụng, là dịch vụ của Amazon để nhập PostgreSQL vào Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

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

s9sdemo   |   | {nextcloud}

AWS DMS cung cấp nhiều lợi thế, giống như chúng tôi mong đợi từ một giải pháp được quản lý trên đám mây:

tự động điều chỉnh tỷ lệ (chỉ bộ nhớ, vì phiên bản máy tính phải có kích thước phù hợp)
cấp phép tự động
mô hình thanh toán khi bạn di chuyển
chuyển đổi dự phòng tự động

Tuy nhiên, việc duy trì tính nhất quán của dữ liệu cho cơ sở dữ liệu trực tiếp là nỗ lực tốt nhất. Tính nhất quán 100% chỉ đạt được khi cơ sở dữ liệu ở chế độ chỉ đọc - đó là hệ quả của cách ghi lại các thay đổi trong bảng.

Nói cách khác, các bảng có sự khác nhau giữa các thời điểm:

Cũng giống như mọi thứ trong đám mây, có một chi phí liên quan đến dịch vụ di chuyển.

Để tạo môi trường di chuyển, hãy làm theo hướng dẫn Bắt đầu để thiết lập phiên bản sao chép, nguồn, điểm cuối đích và một hoặc nhiều tác vụ.

Bản sao

Việc tạo bản sao rất đơn giản đối với bất kỳ ai quen thuộc với bản sao EC2 trên AWS:

Thay đổi duy nhất so với mặc định là chọn AWS DMS 3.3.0 hoặc muộn hơn do công cụ PostgreSQL cục bộ của tôi là 11.5:

Và đây là danh sách các phiên bản AWS DMS hiện có:

Các cài đặt lớn cũng cần lưu ý Giới hạn AWS DMS:

Ngoài ra còn có một số hạn chế là hệ quả của việc sao chép logic PostgreSQL những hạn chế. Ví dụ:AWS DMS sẽ không di chuyển các đối tượng phụ:

Điều đáng nói là trong PostgreSQL tất cả các chỉ mục đều là chỉ mục phụ và không phải là một điều xấu, như đã lưu ý trong cuộc thảo luận chi tiết hơn này.

Điểm cuối nguồn

Làm theo trình hướng dẫn để tạo Điểm cuối Nguồn:

Trong kịch bản thiết lập Cấu hình cho Mạng tới VPC Sử dụng Internet của tôi mạng gia đình yêu cầu một vài chỉnh sửa để cho phép địa chỉ IP của điểm cuối nguồn truy cập vào máy chủ nội bộ của tôi. Đầu tiên, tôi đã tạo một cổng chuyển tiếp trên bộ định tuyến biên (173.180.222.170) để gửi lưu lượng trên cổng 30485 đến cổng nội bộ của tôi (10.11.11.241) trên cổng 5432, nơi tôi có thể tinh chỉnh quyền truy cập dựa trên địa chỉ IP nguồn thông qua quy tắc iptables. Từ đó, lưu lượng mạng chảy qua một đường hầm SSH đến máy chủ web chạy cơ sở dữ liệu PostgreSQL. Với cấu hình được mô tả, client_addr trong đầu ra của pg_stat_activity sẽ hiển thị là 127.0.0.1.

Trước khi cho phép lưu lượng đến, nhật ký iptables hiển thị 12 lần thử từ phiên bản sao chép tại 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

Sau khi cho phép địa chỉ IP điểm cuối nguồn (3.227.167.58), kiểm tra kết nối thành công và cấu hình điểm cuối nguồn hoàn tất. Chúng tôi cũng có kết nối SSL để mã hóa lưu lượng truy cập qua các mạng công cộng. Điều này có thể được xác nhận trên máy chủ PostgreSQL bằng cách sử dụng truy vấn bên dưới cũng như trong bảng điều khiển 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)

… rồi xem trong khi chạy kết nối từ bảng điều khiển AWS. Kết quả sẽ tương tự như sau:

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)

… trong khi bảng điều khiển AWS sẽ báo cáo thành công:

Như đã nêu trong phần điều kiện tiên quyết, nếu chúng tôi chọn tùy chọn di chuyển Toàn tải , đang sao chép, chúng tôi sẽ cần thay đổi các quyền cho người dùng PostgreSQL. Tùy chọn di chuyển này yêu cầu đặc quyền siêu người dùng, do đó tôi đã điều chỉnh cài đặt cho người dùng PostgreSQL đã tạo trước đó:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

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

s9sdemo   | Superuser  | {}

Tài liệu tương tự chứa hướng dẫn sửa đổi postgresql.conf. Đây là một điểm khác so với bản gốc:

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

Cuối cùng, đừng quên điều chỉnh cài đặt pg_hba.conf để cho phép kết nối SSL từ địa chỉ IP bản sao.

Chúng tôi hiện đã sẵn sàng cho bước tiếp theo.

Điểm Cuối Mục tiêu

Làm theo trình hướng dẫn để tạo Điểm cuối đích:

Bước này giả định rằng phiên bản RDS với điểm cuối được chỉ định đã tồn tại cùng với cơ sở dữ liệu trống nextcloud_awsdms. Cơ sở dữ liệu có thể được tạo trong quá trình thiết lập phiên bản RDS.

Tại thời điểm này, nếu mạng AWS được thiết lập chính xác, chúng tôi sẽ sẵn sàng chạy kiểm tra kết nối:

Với môi trường tại chỗ, bây giờ là lúc tạo tác vụ di chuyển :

Nhiệm vụ Di chuyển

Sau khi trình hướng dẫn hoàn thành, cấu hình sẽ giống như sau:

... và phần thứ hai của cùng một chế độ xem:

Sau khi tác vụ được bắt đầu, chúng tôi có thể theo dõi tiến trình — mở tác vụ chi tiết và cuộn xuống Bảng thống kê:

AWS DMS đang sử dụng lược đồ được lưu trong bộ nhớ cache để di chuyển các bảng cơ sở dữ liệu. Trong khi quá trình di chuyển diễn ra, chúng tôi có thể tiếp tục “xem” các truy vấn trên cơ sở dữ liệu nguồn và nhật ký lỗi PostgreSQL, ngoài bảng điều khiển AWS:

Trong trường hợp có lỗi, trạng thái lỗi được hiển thị trong bảng điều khiển:

Một nơi để tìm manh mối là CloudWatch, mặc dù trong quá trình kiểm tra nhật ký của tôi cuối cùng đã không được xuất bản, đó có thể chỉ là một trục trặc khác trong phiên bản beta của AWS DMS 3.3.0 vì nó hóa ra là vào cuối bài tập này:

Tiến trình di chuyển được hiển thị độc đáo trong bảng điều khiển AWS DMS:

Khi quá trình di chuyển hoàn tất, xem lại một lần nữa, nhật ký lỗi PostgreSQL , tiết lộ một thông điệp đáng ngạc nhiên:

Điều dường như sẽ xảy ra, đó là trong PostgreSQL 9.6, 10 bảng pg_class có chứa khóa relhaspkey cột được đặt tên, nhưng đó không phải là trường hợp trong 11. Và đó là trục trặc trong phiên bản beta của AWS DMS 3.3.0 mà tôi đã đề cập trước đó.

GCP

Phương pháp của Google dựa trên công cụ nguồn mở PgBouncer. Sự phấn khích chỉ tồn tại trong thời gian ngắn, khi tài liệu chính thức nói về việc chuyển PostgreSQL vào môi trường máy tính.

Các nỗ lực khác để tìm giải pháp di chuyển sang Cloud SQL tương tự AWS DMS đã không thành công. Các chiến lược di chuyển Cơ sở dữ liệu không chứa tham chiếu đến PostgreSQL:

Các bản cài đặt PostgreSQL tại chỗ có thể được chuyển sang Cloud SQL bằng cách sử dụng các dịch vụ của một trong những đối tác của Google Cloud.

Một giải pháp tiềm năng có thể là PgBouncer cho Cloud SQL, nhưng điều đó không nằm trong phạm vi của blog này.

Dịch vụ đám mây của Microsoft (Azure)

Để tạo điều kiện thuận lợi cho việc di chuyển khối lượng công việc PostgreSQL từ tại chỗ sang Cơ sở dữ liệu Azure được quản lý cho PostgreSQL, Microsoft cung cấp Azure DMS mà theo tài liệu có thể được sử dụng để di chuyển với thời gian ngừng hoạt động tối thiểu. Hướng dẫn Di chuyển PostgreSQL sang Cơ sở dữ liệu Azure cho PostgreSQL trực tuyến bằng DMS mô tả chi tiết các bước này.

Tài liệu Azure DMS thảo luận rất chi tiết về các vấn đề và hạn chế liên quan đến việc di chuyển khối lượng công việc PostgreSQL sang Azure.

Một điểm khác biệt đáng chú ý so với AWS DMS là yêu cầu tạo lược đồ theo cách thủ công:

Bản demo về điều này sẽ là chủ đề của một blog trong tương lai. Hãy theo dõi.