Hướng dẫn cách tăng tốc quá trình di chuyển hàng terabyte dữ liệu bằng Database Migration Service từ PostgreSQL lên Google Cloud

Đối với những ai đang muốn dịch chuyển sang Google Cloud, Database Migration Service (DMS) cung cấp một cách toàn diện để di chuyển dữ liệu của bạn, đơn giản hóa quá trình chuyển dữ liệu sang các cơ sở dữ liệu Google Cloud khác nhau. Một số dịch vụ chính của DMS bao gồm di chuyển liên tục từ MySQL, PostgreSQL và SQL Server sang Cloud SQL và từ PostgreSQL sang AlloyDB cho PostgreSQL. Ngoài ra, DMS hỗ trợ hiện đại hóa tải trọng Oracle bằng cách di chuyển chúng sang Cloud SQL cho PostgreSQL và AlloyDB. Bằng cách tận dụng DMS, bạn có thể tối ưu hóa quá trình di chuyển dữ liệu, giúp đảm bảo quá trình chuyển đổi sang cơ sở dữ liệu Google Cloud diễn ra trơn tru.

Trong bài đăng này, Gimasys sẽ xem xét các phương pháp khác nhau để cải thiện tốc độ tổng thể của quá trình di chuyển dữ liệu từ Cloud SQL sang PostgreSQL / AlloyDB. Hãy cùng khám phá.

Những thách thức của việc di chuyển cơ sở dữ liệu lớn

Mục tiêu chính của Database Migration Service là di chuyển cơ sở dữ liệu một cách liền mạch với thời gian ngừng hoạt động tối thiểu. Khi xử lý các luồng dữ liệu quy mô lớn, tốc độ di chuyển là yếu tố quan trọng quyết định trải nghiệm tổng thể. Đối với các cơ sở dữ liệu PostgreSQL cụ thể, tốc độ di chuyển chậm có thể có các tác dụng phụ như:

• Độ trễ sao chép lớn tới đích khiến nguồn không bắt kịp sau khi thiết lập sao chép
• Độ trễ giao dịch trên nguồn, vì vacuum bị tạm dừng do các hoạt động sao chép chạy lâu
• Tăng kích thước Nhật ký WAL, gây ra quá tải đĩa trên nguồn

Các cách tăng tốc độ di chuyển

Để tránh các vấn đề trên, Google có thể tinh chỉnh một số cài đặt để di chuyển nhanh hơn. Lưu ý rằng các cài đặt sau áp dụng cho cả Cloud SQL và AlloyDB làm đích. Bạn có thể cải thiện tốc độ di chuyển, các cài đặt sau có thể được điều chỉnh theo nhiều danh mục khác nhau:

• Tải dữ liệu ban đầu song song và CDC sử dụng DMS
• Định cấu hình các tham số cơ sở dữ liệu PostgreSQL trong nguồn và đích
• Tối ưu hóa cấu hình máy và mạng

Chúng ta hãy xem xét những cách này một cách chi tiết.

Tải dữ liệu ban đầu song song và CDC sử dụng DMS

Gần đây, Google đã giới thiệu một tính năng mới của DMS để tăng tốc độ di chuyển bằng cách sử dụng nhiều đăng ký PostgreSQL, cho phép di chuyển dữ liệu trên các kết nối song song bằng cách thiết lập nhiều đăng ký sử dụng pglogical giữa cơ sở dữ liệu nguồn và đích. Với tính năng này, dữ liệu được di chuyển trong các luồng song song cả trong quá trình tải dữ liệu ban đầu và sau đó là CDC.

Khi bạn sử dụng DMS thông qua giao diện người dùng hoặc API của Cloud SQL, tùy chọn mặc định để di chuyển dữ liệu là OPTIMAL, cung cấp hiệu suất cân bằng với tải tối ưu trên cơ sở dữ liệu nguồn. Nếu bạn muốn cải thiện thêm tốc độ di chuyển, bạn có thể chọn cài đặt khác là MAXIMUM, cung cấp tốc độ dump cao nhất cho quá trình di chuyển.

Dựa trên cài đặt bạn chọn, DMS tính toán số lượng đăng ký tối ưu (đăng ký là phía nhận của thiết lập sao chép pglogical) cho mỗi cơ sở dữ liệu tùy thuộc vào thông tin cơ sở dữ liệu và kích thước instance. Các bảng được phân phối đến các bộ sao chép khác nhau (cung cấp cơ chế để kiểm soát bảng nào trong cơ sở dữ liệu sẽ được sao chép) dựa trên kích thước để cân bằng kích thước bộ sao chép trên các đăng ký. Dữ liệu được sao chép song song với kết nối riêng lẻ cho mỗi đăng ký dẫn đến sao chép ban đầu song song hoặc CDC.

Theo kinh nghiệm của Gimasys, chọn tùy chọn MAXIMUM sẽ tăng tốc độ di chuyển gấp nhiều lần so với khi chọn chế độ MINIMAL / OPTIMAL.

Lưu ý rằng mặc dù cài đặt MAXIMUM cung cấp tốc độ tốt nhất, nhưng nếu nguồn đã chịu tải cao, điều này có thể ảnh hưởng đến hiệu suất của ứng dụng của bạn. Vì vậy, hãy đảm bảo việc sử dụng tài nguyên nguồn trước khi chọn tùy chọn này.

Định cấu hình các tham số cơ sở dữ liệu PostgreSQL trong nguồn và đích

Các tham số cơ sở dữ liệu sau đây sẽ giúp tối ưu hóa tải dữ liệu ban đầu và CDC. Lưu ý rằng các gợi ý có một phạm vi giá trị, bạn cần kiểm tra và theo dõi theo tải công việc của mình và đặt chúng cho phù hợp.

Cấu hình tinh chỉnh trên instance đích

Dưới đây là một số cấu hình có thể được tinh chỉnh trên cơ sở dữ liệu đích.

• max_wal_size: Đặt trong khoảng 20GB-50GB Tham số hệ thống max_wal_size xác định kích thước tối đa của WAL có thể tăng trong quá trình kiểm tra điểm tự động. Có kích thước WAL cao hơn làm giảm tần suất kiểm tra điểm, từ đó giúp phân bổ tài nguyên tốt hơn cho các quá trình di chuyển. Giá trị mặc định của max_wal_size có thể khiến các điểm kiểm tra xảy ra vài giây một lần trong quá trình tải DMS. Để tránh điều này, chúng ta có thể đặt phạm vi max_wal_size từ 20GB đến 50GB tùy thuộc vào tầng máy. Đặt giá trị này cao hơn giúp tăng tốc độ di chuyển tổng thể, đặc biệt là trong quá trình tải ban đầu. Đối với AlloyDB, không cần thay đổi tham số này vì nó tự động quản lý các điểm kiểm tra. Sau khi hoàn thành quá trình di chuyển, hãy đảm bảo thay đổi giá trị để đáp ứng yêu cầu của tải trọng sản xuất của bạn.
• pglogical.synchronous_commit: Đặt thành off Như tên gọi pglogical.synchronous_commit cho biết, xác nhận cam kết có thể đến trước khi ghi các bản ghi WAL vào đĩa. Việc ghi WAL sẽ không xảy ra ngay lập tức mà dựa vào cài đặt wal_writer_delay. Điều này thường được gọi là cam kết không đồng bộ, giúp các cam kết nhanh hơn trong quá trình CDC khi các thay đổi DML được áp dụng nhưng phải trả giá bằng độ bền. Nếu instance PostgreSQL bị lỗi, một số cam kết không đồng bộ cuối cùng có thể bị mất.
• wal_buffers: Đặt 32-64 MB trong máy 4 vCPU, 64-128 MB trong máy 8-16 vCPU Bộ đệm wal chỉ ra lượng bộ nhớ dùng chung được sử dụng cho dữ liệu WAL chưa được ghi vào đĩa. Mục tiêu là giảm tần suất cam kết trong quá trình tải ban đầu. Nó có thể được đặt thành 256MB cho các mục tiêu vCPU cao hơn. wal_buffers nhỏ hơn làm tăng tần suất cam kết, vì vậy tăng giá trị sẽ giúp trong tải ban đầu.
• maintenance_work_mem: Giá trị đề xuất là 1GB / kích thước chỉ mục lớn nhất nếu có thể Các hoạt động bảo trì PostgreSQL như VACUUM, CREATE INDEX và ALTER TABLE ADD FOREIGN KEY sử dụng một vùng nhớ chuyên dụng gọi là maintenance_work_mem. Các hoạt động này được thực hiện tuần tự bởi cơ sở dữ liệu. DMS di chuyển dữ liệu tải ban đầu trước và sau đó xây dựng lại các chỉ mục và ràng buộc trên đích trước khi bắt đầu giai đoạn CDC. Vì vậy, maintenance_work_mem giúp tận dụng tối ưu bộ nhớ để xây dựng các ràng buộc này. Đặt giá trị này cao hơn nhiều so với giá trị mặc định là 64 MB. Trước đây, các thử nghiệm đặt giá trị này thành 1 GB đã cho kết quả tốt. Nếu có thể, giá trị lý tưởng cho cài đặt này sẽ gần với kích thước của chỉ mục lớn nhất cần được tạo lại trên đích. Sau khi hoàn thành quá trình di chuyển, bạn có thể đặt lại tham số này về giá trị mặc định để quá trình xử lý truy vấn ứng dụng không bị ảnh hưởng.
• max_parallel_maintenance_workers: Tỷ lệ thuận với số lượng CPU DMS di chuyển dữ liệu trước và sau đó tạo lại các chỉ mục phụ trên đích bằng cách sử dụng pg_restore. DMS chọn cấu hình song song tối ưu cho tham số –jobs dựa trên cấu hình máy trên đích. Để tăng tốc thêm các cuộc gọi CREATE INDEX, tham số max_parallel_maintenance_workers có thể được đặt trên đích để tạo chỉ mục song song. Cài đặt mặc định là 2 và có thể được tăng thêm dựa trên số lượng CPU và bộ nhớ của instance đích. Sau khi hoàn thành quá trình di chuyển, bạn có thể đặt lại tham số này về giá trị mặc định để quá trình xử lý truy vấn ứng dụng không bị ảnh hưởng.
• max_parallel_workers: Đặt tỷ lệ này với max_worker_processes Bạn có thể tăng số lượng tối đa công nhân mà hệ thống có thể hỗ trợ cho các hoạt động song song bằng cờ max_parallel_workers. Giá trị mặc định là 8. Đặt giá trị này cao hơn max_worker_processes không có tác dụng, vì các công nhân song song được lấy từ nhóm các tiến trình công nhân được thiết lập bởi cài đặt đó. Đảm bảo max_parallel_workers bằng hoặc lớn hơn max_parallel_maintainence_workers.
• autovacuum: Tắt nó thành ‘off’ Nếu có nhiều dữ liệu để bắt kịp trên đích trong giai đoạn CDC, hãy tạm thời tắt autovacuum trên đích cho đến khi độ trễ sao chép tối thiểu. Bạn có thể thực hiện một lần vacuum thủ công trước khi nâng cấp một instance với max_parallel_maintenance_workers=4 (đặt nó thành số lượng vCPU của instance Cloud SQL) và maintenance_work_mem=10GB hoặc cao hơn để tăng tốc độ vacuum. Lưu ý rằng vacuum thủ công lấy bộ nhớ từ maintenance_work_mem. Đảm bảo bật lại autovacuum sau khi di chuyển.

Cấu hình tinh chỉnh trên instance nguồn

Cuối cùng, hãy xem xét các cấu hình sau để tinh chỉnh trên instance nguồn:

• Shared_buffers: Đặt thành 60% RAM Tham số shared_buffers điều khiển lượng bộ nhớ được phân bổ bởi máy chủ cơ sở dữ liệu cho các bộ đệm bộ nhớ dùng chung. Để nâng cao hiệu suất tải ban đầu và cho phép nhiều bộ nhớ hơn cho các lệnh SELECT được đệm trong bộ nhớ, nên tăng shared_buffers lên tối đa 60% RAM khả dụng trong cơ sở dữ liệu PostgreSQL nguồn.

Tối ưu hóa cấu hình máy và mạng

Một khía cạnh quan trọng khác đóng vai trò chính trong việc đạt được tốc độ di chuyển nhanh hơn là cấu hình máy hoặc mạng. Có cấu hình đích và nguồn lớn hơn (RAM cao, CPU, Đĩa IO) giúp đạt được tốc độ di chuyển nhanh hơn.

Một số cách để đạt được điều này:

• Khi di chuyển với DMS, hãy thử di chuyển đến tầng máy lớn hơn cho instance đích. Sau khi hoàn thành quá trình di chuyển và trước khi nâng cấp instance, bạn có thể hạ cấp máy xuống tầng máy nhỏ hơn. Lưu ý rằng bạn sẽ cần khởi động lại máy trong trường hợp này. Nhưng vì điều này được thực hiện trước khi nâng cấp instance nên trong hầu hết các trường hợp sẽ không ảnh hưởng đến thời gian ngừng hoạt động của nguồn.
• Thông lượng mạng bị giới hạn bởi số lượng vCPU. Mỗi VM có giới hạn thoát mạng về thông lượng ghi phụ thuộc vào loại máy. Thông lượng đĩa tối đa (0,48MBps mỗi GB) bị giới hạn bởi thông lượng thoát mạng cho VM. Đối với Disk IOPS, chúng ta có được 30 IOPS / GB. Hãy thử chọn instance Cloud SQL đích với số lượng vCPU lớn hơn. Phân bổ đủ đĩa để có được nhiều thông lượng và IOPS hơn.
• Trong các thử nghiệm của Google, các di chuyển với IP riêng đã cải thiện tốc độ di chuyển (nhanh hơn 20%) so với các di chuyển dựa trên IP công cộng.
• Đừng xác định kích thước lưu trữ ban đầu dựa trên kích thước cơ sở dữ liệu nguồn; hãy tính đến yêu cầu thông lượng và IOPS của tải trọng di chuyển.
• Các luồng song song để xây dựng lại chỉ mục trong cơ sở dữ liệu đích được xác định bởi số lượng vCPU của instance Cloud SQL đích. (DMS hoãn việc tạo các chỉ mục và ràng buộc phụ cho đến sau khi tải ban đầu nhưng trước CDC.)

Giới hạn

• Trong trường hợp một bảng lớn duy nhất, nếu nguồn có một bảng lớn chứa phần lớn dữ liệu trong cơ sở dữ liệu đang được di chuyển, thì bạn có thể không thấy cải thiện tốc độ đáng kể với DMS. Điều này là do sự song song hiện tại ở cấp bảng do giới hạn của pglogical. Vì vậy, dữ liệu trong một bảng không thể được song song hóa; điều này sẽ được giải quyết trong các bản phát hành sắp tới.
• Không bật sao lưu tự động trong quá trình di chuyển. Ngoài ra, không thực hiện DDL trên nguồn nếu có thể; DDL không được hỗ trợ cho sao chép. Tham khảo tài liệu để biết thêm chi tiết.

Kết luận

Tối ưu hóa quá trình di chuyển DMS bao gồm tinh chỉnh cấu hình trên cả instance nguồn và đích, tận dụng cấu hình máy và mạng tối ưu và theo dõi quy trình làm việc ở các giai đoạn khác nhau. Bằng cách tuân theo các thực tiễn tốt nhất được khuyến nghị và giải quyết các hạn chế tiềm năng, bạn có thể đạt được quá trình di chuyển DMS nhanh hơn và hiệu quả hơn. Để bắt đầu, hãy tham khảo hướng dẫn khởi động nhanh DMS cho các di chuyển sang AlloyDB và Cloud SQL hoặc liên hệ với Gimasys để được tư vấn chi tiết nhất về cách di chuyển dữ liệu lớn nhanh chóng an toàn