AWS Study Group

Các phương pháp tốt nhất để xử lý tác vụ AWS DMS trong quá trình nâng cấp PostgreSQL

Tác giả: Veeramani A và Manoj Ponnurangam

Ngày đăng: 21/04/2025

Chủ đề: Nâng cao (300), Dịch vụ Di chuyển Cơ sở dữ liệu AWS, Phương pháp Tốt nhất

Dịch vụ Di chuyển Cơ sở dữ liệu AWS (AWS DMS) cung cấp một giải pháp được quản lý để di chuyển và sao chép cơ sở dữ liệu sang Amazon Web Services (AWS), đồng thời đảm bảo an toàn dữ liệu và tính toàn vẹn dữ liệu. AWS DMS hỗ trợ cả di chuyển đồng nhất (homogeneous migration), nơi cơ sở dữ liệu nguồn và đích sử dụng cùng công cụ cơ sở dữ liệu, và di chuyển không đồng nhất  (heterogeneous migration) giữa các môi trường cơ sở dữ liệu khác nhau.

AWS DMS hỗ trợ di chuyển dữ liệu từ cơ sở dữ liệu PostgreSQL sang bất kỳ đích được hỗ trợ  nào và cũng cho phép di chuyển từ bất kỳ nguồn được hỗ trợ nào sang cơ sở dữ liệu PostgreSQL, cung cấp một lộ trình mạnh mẽ để các doanh nghiệp chuyển đổi hạ tầng dữ liệu của họ lên đám mây.

Tổng quan về giải pháp

PostgreSQL mã nguồn mở thỉnh thoảng phát hành các phiên bản nhỏ và lớn  mới, bao gồm các bản sửa lỗi cho các lỗi thường gặp, vấn đề bảo mật và sự cố hỏng dữ liệu. Thông thường, Amazon RDS sẽ hỗ trợ các phiên bản công cụ mới trong vòng năm tháng kể từ khi chúng được phát hành. Bạn cần nâng cấp các phiên bản PostgreSQL của mình khi một phiên bản cụ thể không còn được hỗ trợ, hoặc bạn có thể quyết định nâng cấp cơ sở dữ liệu PostgreSQL để giải quyết một vấn đề, cải thiện hiệu suất, hoặc để duy trì tuân thủ và bảo vệ dữ liệu.

Khi bạn quyết định nâng cấp cơ sở dữ liệu PostgreSQL được cấu hình làm nguồn hoặc đích cho một tác vụ AWS DMS đang hoạt động, việc lập kế hoạch nâng cấp cần tính đến yếu tố này.

Trong bài viết này, chúng tôi thảo luận về các phương pháp tốt nhất để xử lý các tác vụ AWS DMS trong quá trình nâng cấp phiên bản nhỏ hoặc lớn của PostgreSQL.

Điều kiện tiên quyết

Để thử nghiệm giải pháp trong bài viết này, bạn cần các tài nguyên sau:

Hiểu về nâng cấp phiên bản trong PostgreSQL

Trước khi tìm hiểu cách nâng cấp PostgreSQL ảnh hưởng đến các tác vụ AWS DMS, chúng ta cần hiểu rõ về nâng cấp phiên bản nhỏ và lớn trong PostgreSQL.

Phiên bản nhỏ (Minor versions)

Các phiên bản nhỏ sửa chữa các lỗ hổng bảo mật, khắc phục lỗi và thường không thêm chức năng mới. Các bản phát hành nhỏ không thay đổi định dạng lưu trữ nội bộ và luôn tương thích với các phiên bản nhỏ trước và sau của cùng số phiên bản lớn. Ví dụ, phiên bản 14.10 tương thích với phiên bản 14.9 và 14.16.

Phiên bản lớn (Major versions)

Đối với các bản phát hành lớn của PostgreSQL, định dạng nội bộ của các bảng hệ thống, tệp dữ liệu và định dạng lưu trữ dữ liệu nội bộ có thể thay đổi. RDS cho PostgreSQL sử dụng tiện ích pg_upgrade để nâng cấp phiên bản lớn. Để biết thêm thông tin về nâng cấp, xem Nâng cấp công cụ cơ sở dữ liệu PostgreSQL cho Amazon RDS.

Cả nâng cấp phiên bản nhỏ và lớn đều gây ra thời gian ngừng hoạt động và nên được thực hiện trong khoảng thời gian bảo trì định sẵn . Chúng tôi khuyến nghị bạn lập kế hoạch cho một khoảng thời gian bảo trì khi cơ sở dữ liệu ít được truy vấn nhất.

Tương tác của AWS DMS với PostgreSQL

Giả sử bạn đang sử dụng AWS DMS để di chuyển dữ liệu từ một cơ sở dữ liệu PostgreSQL nguồn sang một cơ sở dữ liệu PostgreSQL đích.

Trong quá trình tải toàn bộ dữ liệu (full load), AWS DMS kết nối với cơ sở dữ liệu PostgreSQL nguồn và thực hiện lệnh SELECT * trên các bảng được định nghĩa trong ánh xạ bảng (table mappings) để lấy dữ liệu. Dữ liệu được lấy từ nguồn sẽ được ghi vào tệp CSV trong phiên bản sao chép cho các đích PostgreSQL. Đối với đích PostgreSQL, AWS DMS sử dụng lệnh COPY để tải dữ liệu từ tệp CSV vào các bảng PostgreSQL đích.

Để ghi lại các thay đổi liên tục trong quá trình di chuyển, AWS DMS tạo một khe sao chép logic (logical replication slot) trên cơ sở dữ liệu PostgreSQL nguồn. Khe này đại diện cho một luồng thay đổi có thể được phát lại cho một máy khách theo thứ tự thực hiện trên cơ sở dữ liệu nguồn. AWS DMS sử dụng plugin test_decoding hoặc pglogical để giải mã logic các thay đổi từ khe sao chép. Nếu plugin pglogical có sẵn trên cơ sở dữ liệu PostgreSQL nguồn, DMS sẽ sử dụng pglogical để tạo khe sao chép; nếu không, plugin test_decoding được sử dụng. Các thay đổi được đọc từ nguồn sẽ được chuyển đến thành phần sorter trên phiên bản sao chép. Thành phần sorter sắp xếp các giao dịch theo thứ tự cam kết (commit order), sau đó áp dụng các thay đổi này vào cơ sở dữ liệu đích, theo chế độ tuần tự hoặc hàng loạt dựa trên cấu hình tác vụ DMS.

Khe sao chép đóng vai trò quan trọng trong các tác vụ tải toàn bộ + CDC (Change Data Capture) và chỉ CDC. Nó chịu trách nhiệm giữ lại các tệp nhật ký ghi trước (WAL – Write Ahead Log) cần thiết trên cơ sở dữ liệu PostgreSQL nguồn. Nếu khe sao chép bị xóa trên cơ sở dữ liệu nguồn, DMS sẽ không thể xử lý các thay đổi liên tục từ nguồn.

Ảnh hưởng của nâng cấp PostgreSQL đến các tác vụ AWS DMS

Trong các phần sau, chúng tôi thảo luận cách xử lý các tác vụ DMS trong quá trình nâng cấp phiên bản nhỏ hoặc lớn của cơ sở dữ liệu PostgreSQL nguồn hoặc đích.

Khi cơ sở dữ liệu PostgreSQL nguồn được nâng cấp

Tác vụ chỉ tải toàn bộ (Full load-only)

Các tác vụ chỉ tải toàn bộ được thiết kế cho các di chuyển dữ liệu một lần. Các tác vụ này có thể được khởi động lại an toàn sau khi nâng cấp phiên bản nhỏ hoặc lớn của cơ sở dữ liệu PostgreSQL nguồn.

Tác vụ tải toàn bộ + CDC và chỉ CDC

Các tác vụ tải toàn bộ + CDC và chỉ CDC sao chép các thay đổi liên tục sang cơ sở dữ liệu đích. Hãy làm theo các phương pháp tốt nhất trong các phần sau để xử lý các tác vụ này trong quá trình nâng cấp PostgreSQL.

Nâng cấp phiên bản nhỏ
  • Dừng các tác vụ sao chép AWS DMS đang hoạt động trước khi nâng cấp phiên bản nhỏ.
  • Sau khi nâng cấp phiên bản nhỏ hoàn tất, bạn có thể tiếp tục tác vụ DMS.
Nâng cấp phiên bản lớn

Tại thời điểm viết bài, AWS DMS hỗ trợ PostgreSQL phiên bản 9.4 trở lên (cho các phiên bản 9.x), 10.x, 11.x, 12.x, 13.x, 14.x, 15.x và 16.x. Khi thực hiện nâng cấp phiên bản lớn, hãy đảm bảo rằng phiên bản sao chép của bạn hỗ trợ phiên bản PostgreSQL mới.

Để tiến hành nâng cấp phiên bản lớn bằng pg_upgrade, các khe sao chép trên cơ sở dữ liệu PostgreSQL nguồn cần được xóa. Nếu không xóa các khe này, quá trình nâng cấp có thể bị ảnh hưởng. Nếu bạn cố gắng nâng cấp mà không xóa khe sao chép, quá trình nâng cấp sẽ thất bại với thông báo trong tệp pg_upgrade_precheck.log cho biết phiên bản không thể nâng cấp do bị chặn bởi một hoặc nhiều khe sao chép logic. Tuy nhiên, việc xóa khe sao chép sẽ làm vô hiệu hóa các tác vụ AWS DMS đang hoạt động và bạn sẽ không thể tiếp tục các tác vụ sao chép đang chạy.

Để giải quyết vấn đề này và quản lý các tác vụ sao chép liên tục trong quá trình nâng cấp phiên bản lớn, hãy làm theo các bước sau:

1. Dừng tất cả kết nối ứng dụng đến cơ sở dữ liệu PostgreSQL. Theo dõi các kết nối đang hoạt động bằng:


SELECT * FROM pg_stat_activity WHERE datname = ‘database_name’;

 Nếu cần, chấm dứt các kết nối còn lại bằng:


SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = ‘database_name’ AND pid <> pg_backend_pid();

2. Theo dõi số liệu tác vụ AWS DMS để xác minh rằng cả CDCLatencySource và CDCLatencyTarget gần bằng 0. Điều này xác nhận rằng các tác vụ DMS đang sao chép các thay đổi mà không bị chậm trễ. Bạn cũng có thể sử dụng awsdms_txn_state trong đích để kiểm tra trạng thái tác vụ (có thể kích hoạt bằng cài đặt nhiệm vụ TaskRecoveryTableEnabled = True). Hình ảnh sau đây cho thấy các số liệu CloudWatch của CDClatenCySource và CdClatencyTarget.

3. Khi độ trễ gần bằng 0, dừng tất cả các tác vụ sao chép DMS đang hoạt động.

4. Xóa các khe sao chép hiện có khỏi cơ sở dữ liệu PostgreSQL nguồn.
postgres=> select * from pg_replication_slots;

slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size

—————–+————-+———–+——–+———-+———–+——–+————+——+————-+————-+——————-+————+—————

bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde | test_decoding | logical | 14405 | postgres | f | f | | | 898 | 0/5936F798 | 0/5F1A3440 | reserved |

(1 row)

postgres=> SELECT pg_drop_replication_slot(‘bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde’); 

 pg_drop_replication_slot 

————————–

(1 row)

5.  Kiểm tra việc xóa khe sao chép:


postgres=> select * from pg_replication_slots;

slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size

———–+——–+———–+——–+———-+———–+——–+————+——+————-+————-+——————-+————+—————

(0 rows)

6. Hoàn tất nâng cấp tại chỗ trên cơ sở dữ liệu PostgreSQL.

7. Xác nhận nâng cấp thành công. Thực hiện các kiểm tra cấp cơ sở dữ liệu để đảm bảo cơ sở dữ liệu hoạt động như mong đợi sau khi nâng cấp.

8. Tạo một tác vụ chỉ CDC mới. Trong phần cài đặt tác vụ, tại mục “CDC start mode for source transactions” (Chế độ khởi động CDC cho giao dịch nguồn), hãy chọn tùy chọn “Disable custom CDC start mode” (Tắt chế độ khởi động CDC tùy chỉnh).

Sau khi nhiệm vụ đã được tạo, hãy bắt đầu nhiệm vụ chỉ CDC. Nó sẽ tạo ra một khe sao chép mới trên cơ sở dữ liệu PostgreSQL nguồn của bạn và bắt đầu di chuyển các thay đổi từ thời điểm khe sao chép được tạo.

9. Ngoài ra, bạn có thể tạo thủ công khe sao chép trên cơ sở dữ liệu PostgreSQL nguồn của mình, sử dụng tác vụ chỉ DMS CDC bắt đầu từ Số trình tự nhật ký được chỉ định (LSN). Tạo khe sao chép trong nguồn và lưu ý xuống confirmed_flush_lsn.

confirmed_flush_lsn đại diện cho LSN cuối cùng mà người tiêu dùng khe logic đã xác nhận nhận dữ liệu cho động cơ PostgreSQL. Dữ liệu tương ứng với các giao dịch được thực hiện trước khi LSN này không còn nữa.

a.. Sửa đổi cài đặt endpoint nguồn, thêm tham số SlotName với giá trị là tên của slot bạn vừa tạo.

b. Chọn “Enable custom CDC start mode” (Bật chế độ khởi động CDC tùy chỉnh), sau đó chọn “Specify a log sequence number” (Chỉ định số thứ tự log) và nhập giá trị LSN bạn đã ghi lại từ confirmed_flush_lsn.

10. Bắt đầu tác vụ DMS của bạn và xác minh rằng các thay đổi đang được di chuyển sang cơ sở dữ liệu đích mà không có vấn đề.

11. Bắt đầu các ứng dụng của bạn và giám sát bản sao DMS CDC của bạn.

Khi cơ sở dữ liệu PostgreSQL đích được nâng cấp

CDC của AWS DMS không bị ảnh hưởng bởi nâng cấp phiên bản nhỏ của cơ sở dữ liệu PostgreSQL đích. Trước khi nâng cấp cơ sở dữ liệu PostgreSQL được cấu hình làm đích cho DMS, hãy dừng tác vụ DMS và tiếp tục sau khi nâng cấp phiên bản nhỏ thành công.

Khi thực hiện nâng cấp phiên bản lớn trên cơ sở dữ liệu PostgreSQL được cấu hình làm đích cho DMS:

  • Xác nhận rằng phiên bản công cụ phiên bản sao chép hiện tại hỗ trợ phiên bản PostgreSQL mới.
  • Nếu phiên bản công cụ mới được hỗ trợ bởi phiên bản sao chép hiện tại, bạn có thể dừng tác vụ AWS DMS, hoàn tất nâng cấp phiên bản lớn, sau đó tiếp tục tác vụ DMS.
  • Nếu phiên bản công cụ mới không được hỗ trợ bởi phiên bản sao chép hiện tại, bạn cần dừng tác vụ DMS, hoàn tất nâng cấp phiên bản lớn trên cơ sở dữ liệu PostgreSQL đích, và nâng cấp phiên bản sao chép lên phiên bản hỗ trợ phiên bản hiện tại của cơ sở dữ liệu PostgreSQL đích. Sau khi cả cơ sở dữ liệu đích và nguồn được cập nhật lên các phiên bản lớn tương thích, bạn có thể tiếp tục các tác vụ DMS.

Dọn dẹp

Để hoàn nguyên các thay đổi và tránh bất kỳ chi phí nào tiếp tục phát sinh, hãy xóa các tài nguyên bạn đã tạo cho bài viết này:

Tóm tắt

Trong bài viết này, chúng tôi đã thảo luận cách xử lý các tác vụ AWS DMS khi nâng cấp các cơ sở dữ liệu PostgreSQL được cấu hình làm nguồn hoặc đích cho DMS.

Về các Tác giả

Veeramani A là một Kỹ sư Cơ sở dữ liệu Đám mây tại Amazon Web Services, đảm nhiệm vai trò Chuyên gia lĩnh vực (Subject Matter Expert) về Dịch vụ Di chuyển Cơ sở dữ liệu AWS và Amazon RDS cho PostgreSQL. Với hơn 15 năm kinh nghiệm đa dạng trong các công nghệ cơ sở dữ liệu, ông cung cấp hướng dẫn chiến lược và chuyên môn kỹ thuật cho khách hàng trong hành trình di chuyển cơ sở dữ liệu của họ lên Đám mây AWS.
Manoj Ponnurangam làm việc với vai trò Kỹ sư Cơ sở dữ liệu Đám mây tại Amazon Web Services. Anh là Chuyên gia Chủ đề về Amazon RDS cho Oracle, Amazon RDS cho PostgreSQL và Dịch vụ Di chuyển Cơ sở dữ liệu AWS. Manoj có 15 năm kinh nghiệm làm việc với các cơ sở dữ liệu quan hệ. Ông hỗ trợ khách hàng của chúng tôi bằng cách cung cấp hướng dẫn và hỗ trợ kỹ thuật cho các dự án cơ sở dữ liệu và di chuyển khác nhau.
←
→

Leave a comment