Nguồn: Fluent Commerce’s approach to near-zero downtime Amazon Aurora PostgreSQL upgrade at 32 TB scale using snapshots and AWS DMS ongoing replication | AWS Database Blog

Bài viết này là một bài viết khách mời của Adrian Cook, Kỹ sư DevOps tại Fluent Commerce, hợp tác với AWS.

Fluent Commerce, một nền tảng thương mại đa kênh, cung cấp các giải pháp quản lý đơn hàng cho phép các doanh nghiệp mang lại trải nghiệm mua sắm liền mạch trên nhiều kênh khác nhau. Fluent sử dụng Amazon Aurora phiên bản tương thích PostgreSQL (Amazon Aurora PostgreSQL-Compatible Edition) làm công cụ cơ sở dữ liệu xử lý giao dịch trực tuyến (OLTP) hiệu năng cao để xử lý hiệu quả các truy vấn tìm kiếm phức tạp của khách hàng. Hệ thống này xử lý nhiều truy vấn cơ sở dữ liệu phức tạp trong khi vẫn duy trì hoạt động nhất quán, đáng tin cậy và có khả năng mở rộng. Aurora PostgreSQL-Compatible giúp Fluent đạt được hiệu suất cơ sở dữ liệu mong muốn, nhờ đó họ có thể dễ dàng đáp ứng các nhu cầu khắt khe của khách hàng.

Khi doanh nghiệp bắt đầu hành trình mở rộng toàn cầu và liên tục tiếp nhận các khách hàng mới, họ nhận thấy rằng một sự thay đổi chiến lược là cần thiết để hỗ trợ sự phát triển không ngừng của phạm vi địa lý. Thành công của nỗ lực đầy tham vọng này phụ thuộc vào một yếu tố quan trọng: cải thiện hiệu quả chi phí trên toàn bộ tổ chức.

Amazon Relational Database Service (Amazon RDS) và Amazon Aurora đóng vai trò quan trọng trong sự chuyển đổi này. Yếu tố thúc đẩy sự thay đổi đến từ loại phiên bản AWS Graviton, hứa hẹn cải thiện hiệu suất lên đến 20%. Fluent Commerce đã quyết định chiến lược di chuyển tất cả các phiên bản của họ sang Graviton, nhận ra tiềm năng mà nó mang lại trong việc đơn giản hóa hoạt động toàn cầu với việc tối ưu hóa kích thước tài nguyên. Phương pháp này cho phép phân bổ tài nguyên tốt hơn và nâng cao hiệu suất trong khi vẫn duy trì mật độ người dùng hiệu quả trên các phiên bản.

Việc di chuyển sang dòng phiên bản Graviton2 là một quá trình đơn giản, nhưng đòi hỏi phải nâng cấp phiên bản chính từ Aurora PostgreSQL-Compatible 10.14 lên 12.4 và các phiên bản cao hơn. Việc nâng cấp cơ sở dữ liệu có thể rất gián đoạn, đặc biệt đối với Fluent Commerce, khi hỗ trợ một số nền tảng thương mại điện tử lớn nhất thế giới. Quản lý việc nâng cấp một cách dễ dàng, với thời gian gián đoạn gần như bằng không, là một thách thức, khi các cơ sở dữ liệu của họ có thể lên tới 32 TB. May mắn thay, AWS cung cấp nhiều phương pháp kỹ thuật để nâng cấp cơ sở dữ liệu, bao gồm nâng cấp tại chỗ, sao chép bản gốc, triển khai blue/green Amazon RDS và Dịch vụ Di chuyển Cơ sở Dữ liệu AWS (AWS DMS). Fluent Commerce đã kết hợp một cách chiến lược các phương pháp nâng cấp dựa trên AWS – bao gồm khôi phục snapshot và sao chép liên tục bằng AWS DMS – để nâng cấp các cơ sở dữ liệu Aurora PostgreSQL 32 TB của họ với thời gian gián đoạn tối thiểu.

Trong bài viết này, chúng tôi sẽ khám phá một phương pháp thực tế và tiết kiệm chi phí để đạt được thời gian gián đoạn gần như bằng không trong quá trình nâng cấp cơ sở dữ liệu. Chúng tôi sẽ khám phá phương pháp sử dụng snapshot và phương pháp khôi phục, sau đó là sao chép liên tục bằng AWS DMS. Vào cuối bài viết này, bạn sẽ có những hiểu biết về cách điều hướng việc nâng cấp cơ sở dữ liệu, duy trì dịch vụ không gián đoạn và tối ưu hiệu suất khi tổ chức của bạn phát triển và tiến bộ.

Tổng quan về Di chuyển

Aurora PostgreSQL-Compatible cung cấp nhiều phương pháp nâng cấp cho khách hàng của mình, bao gồm nâng cấp tại chỗ và triển khai blue/green. Với yêu cầu và ràng buộc cụ thể của Fluent, họ đã triển khai một phương pháp kết hợp sử dụng sao chép logic gốc và AWS DMS. Fluent Commerce đã sử dụng phương pháp này để nâng cấp hơn 350 cơ sở dữ liệu Aurora PostgreSQL trên môi trường sản xuất, một số cơ sở dữ liệu có kích thước lên tới 32 TB, phục vụ cho các khách hàng thương mại điện tử hàng đầu toàn cầu với yêu cầu nghiêm ngặt về thời gian gián đoạn.

AWS DMS đã trở thành sự lựa chọn ưa thích cho cả nâng cấp cơ sở dữ liệu và di chuyển sang Graviton trong môi trường sản xuất vì các lợi ích sau:

• Giảm chi phí chuyển dữ liệu, giúp trở thành một lựa chọn tiết kiệm chi phí so với các dịch vụ bên thứ ba, vốn có thể rất đắt đỏ.
• AWS DMS tích hợp với các dịch vụ AWS gốc, đồng bộ với các quy trình DevOps và pipeline dữ liệu hiện tại. Sự tích hợp này bao gồm AWS IAM Identity Center, AWS CloudFormation và các quy trình tích hợp liên tục và triển khai liên tục (CI/CD).
• AWS DMS cung cấp khả năng ghi nhận dữ liệu thay đổi (CDC), cho phép sao chép dữ liệu liên tục trong các khoảng thời gian chuyển giao với thời gian gián đoạn tối thiểu hoặc gần như bằng không. AWS DMS cũng bao gồm các tính năng giám sát toàn diện, sử dụng Amazon CloudWatch và AWS CloudTrail logs để cung cấp chỉ số và thông báo theo thời gian thực, cho phép quản lý chủ động và khắc phục sự cố trong các tác vụ nâng cấp và di chuyển.

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

Fluent Commerce đã áp dụng các bước sau để đạt được di chuyển không gián đoạn:

1. Cấu hình tham số cơ sở dữ liệu nguồn để bật các slot sao chép.
2. Tạo các slot sao chép trong cơ sở dữ liệu nguồn để tạo điểm kiểm tra.
3. Chụp snapshot của cơ sở dữ liệu nguồn. (Fluent Commerce không sử dụng tính năng clone của Aurora vì họ đang di chuyển các cụm cơ sở dữ liệu qua các tài khoản khác nhau. Tuy nhiên, các cụm gốc đã sử dụng các khóa mặc định của AWS Key Management Service (AWS KMS), và sử dụng CI/CD với AWS CloudFormation để triển khai các cụm đã khôi phục trong các tài khoản riêng biệt.)
4. Sao chép snapshot bằng khóa KMS mới và khôi phục snapshot vào cơ sở dữ liệu đích.
5. Xóa các slot sao chép trên cơ sở dữ liệu đích.
6. Thực hiện các yêu cầu tiên quyết cho nâng cấp phiên bản lớn (ví dụ: nâng cấp các tiện ích PostgreSQL như PostGIS và pg_repack).
7. Sử dụng AWS DMS để sao chép dữ liệu từ nguồn sang đích.
8. Thực hiện xác minh dữ liệu giữa cơ sở dữ liệu nguồn và đích bằng AWS DMS.
9. Chuyển ứng dụng từ nguồn sang đích.
10. Thực hiện các tác vụ sau chuyển giao như ngừng sử dụng môi trường cũ, sao lưu môi trường mới và kiểm tra, xác minh toàn bộ quy trình.

Sơ đồ dưới đây minh họa kiến trúc giải pháp.

Phần tiếp theo sẽ trình bày các bước đã thực hiện để nâng cấp cơ sở dữ liệu và cập nhật lớp phiên bản với thời gian gián đoạn tối thiểu.

Cấu hình cơ sở dữ liệu nguồn
Hoàn thành các bước sau để cấu hình cơ sở dữ liệu nguồn:

1. Cấu hình các tham số cho sao chép liên tục và CDC:
   • max_worker_processes = <value> # Trên nguồn: 1 cho mỗi cơ sở dữ liệu được sao chép, trên đích: 1 cho mỗi nút
   • max_logical_replication_workers = <value>
   • max_replication_slots = <value> # Bằng với số lượng tác vụ sẽ có
   • max_parallel_workers = <value>
   • max_wal_senders = <value> # số kết nối đồng thời tối đa cho phép từ tất cả các loại replica stream
   • wal_sender_timeout = 0
   • rds.logical_replication = 1
   • shared_preload_libraries = pglogical
2. Sử dụng mã sau để thiết lập tiện ích mở rộng pglogical:

sql

Sao chép

database_name => CREATE EXTENSION pglogical;

3. Cấu hình nút:

sql

Sao chép

database_name => SELECT pglogical.create_node(node_name := ‘database_name_node’,

dsn := ‘host=dmt-test-core-cluster.cluster-ID.ap-southeast-2.rds.amazonaws.com

dbname=database_name port=5432 user=dmt_user password=<PASSWORD>’);

4. Tạo một slot sao chép:

sql

Sao chép

database_name => SELECT * FROM pg_create_logical_replication_slot(‘database_name_slot’, ‘pglogical’);

Lưu ý tên slot sao chép này, nó sẽ cần thiết sau này khi cấu hình endpoint DMS nguồn.

5. Lấy số thứ tự logic đã xác nhận (LSN):

sql

Sao chép

database_name=> SELECT slot_name, slot_type, plugin, database, active, confirmed_flush_lsn;

6. Tạo hai replication set bằng hàm pglogical.create_replication_set:
   a. Replication set đầu tiên theo dõi các bản cập nhật và xóa cho các bảng có khóa chính.
   b. Replication set thứ hai chỉ theo dõi các bản chèn và có tên giống như replication set đầu tiên, với tiền tố “i”.

sql

Sao chép

database_name => SELECT pglogical.create_replication_set(‘database_name_slot’, false, true, true, false);

database_name => SELECT pglogical.create_replication_set(‘idatabase_name_slot’, true, false, false, true);

Replication slots là một dấu hiệu trong PostgreSQL write-ahead log (WAL) để AWS DMS có thể xác định điểm bắt đầu chính xác khi nhập dữ liệu từ cơ sở dữ liệu nguồn. Do các giao dịch DML cực kỳ cao trên cơ sở dữ liệu, Fluent Commerce đã sử dụng hai replication set cho mỗi replication slot để cải thiện khả năng kiểm soát chi tiết và hiệu suất di chuyển tổng thể. Replication set đầu tiên theo dõi các bản cập nhật và xóa cho các bảng có khóa chính. Replication set thứ hai chỉ theo dõi các bản chèn. Điều quan trọng là tất cả các bảng tham gia vào quá trình di chuyển phải có khóa chính và được bao gồm trong hai set này để đảm bảo tính toàn vẹn và nhất quán dữ liệu trong quá trình di chuyển.

Để biết thêm thông tin, tham khảo bài viết Sử dụng cơ sở dữ liệu PostgreSQL làm nguồn AWS DMS.

Sơ đồ dưới đây minh họa kiến trúc của replication slot.

1. Thêm bảng vào các replication set theo dõi các bản cập nhật và xóa.
Câu truy vấn sau đây cho thấy cách thêm một bảng vào replication set:

sql

Sao chép

select pglogical.replication_set_add_table(‘database_name_slot’, ‘schema_name.my_table’);

Bạn cũng có thể truy vấn bảng catalog để tạo SQL cho việc thêm các bảng vào replication set trong một bước:

sql

Sao chép

database_name=> SELECT E’SELECT pglogical.replication_set_add_table(\’database_name_slot\’, \” 

||tab.table_schema||’.’||tab.table_name||E’\’);’

FROM information_schema.tables tab

LEFT JOIN information_schema.table_constraints tco

ON tco.table_schema = tab.table_schema

AND tco.table_name = tab.table_name

AND tco.constraint_type = ‘PRIMARY KEY’

LEFT JOIN information_schema.key_column_usage kcu

ON kcu.constraint_name = tco.constraint_name

AND kcu.constraint_schema = tco.constraint_schema

AND kcu.constraint_name = tco.constraint_name

WHERE tab.table_schema NOT IN (‘pg_catalog’, ‘information_schema’)

AND tab.table_type = ‘BASE TABLE’ AND tco.constraint_name IS NOT NULL

GROUP BY tab.table_schema,

tab.table_name,

tco.constraint_name

ORDER BY tab.table_schema,

tab.table_name;

2. Thêm bảng vào các replication set chỉ theo dõi các bản chèn.
Câu truy vấn sau đây cho thấy cách thêm một bảng vào replication set chỉ theo dõi các bản chèn:

sql

Sao chép

select pglogical.replication_set_add_table(‘database_name_slot’, ‘schema_name.my_table’);

Tương tự, bạn có thể thêm tất cả các bảng vào các replication set trong một bước duy nhất bằng câu truy vấn SQL sau:

sql

Sao chép

database_name=> SELECT E’SELECT pglogical.replication_set_add_table(\’idatabase_name_slot\’, \” 

  ||tab.table_schema||’.’||tab.table_name||E’\’);’

FROM information_schema.tables tab

LEFT JOIN information_schema.table_constraints tco

          ON tco.table_schema = tab.table_schema

          AND tco.table_name = tab.table_name

          AND tco.constraint_type = ‘PRIMARY KEY’

LEFT JOIN information_schema.key_column_usage kcu 

          ON kcu.constraint_name = tco.constraint_name

          AND kcu.constraint_schema = tco.constraint_schema

          AND kcu.constraint_name = tco.constraint_name

WHERE tab.table_schema NOT IN (‘pg_catalog’, ‘information_schema’)

      AND tab.table_type = ‘BASE TABLE’ AND tco.constraint_name IS NOT NULL

GROUP BY tab.table_schema,

         tab.table_name,

         tco.constraint_name

ORDER BY tab.table_schema,

         tab.table_name;

Các câu truy vấn trên sẽ giúp bạn thêm các bảng vào các replication set, tùy vào yêu cầu là theo dõi bản cập nhật và xóa hoặc chỉ bản chèn, từ đó quản lý sao chép dữ liệu giữa các cơ sở dữ liệu PostgreSQL trong quá trình di chuyển.

Tạo một Snapshot

Sử dụng mã sau để tạo một snapshot của cơ sở dữ liệu nguồn. Lưu ý tên của snapshot và đảm bảo chia sẻ nó với tài khoản AWS đích, vì bạn sẽ di chuyển snapshot này sang tài khoản AWS mới.

bash

Sao chép

aws rds create-db-snapshot –db-snapshot-identifier <snapshot-name> –db-instance-identifier <db-instance-identifier>

Trong đó:

• <snapshot-identifier> – Là định danh cho snapshot DB mà bạn muốn chia sẻ.
• <db-instance-identifier> – Là định danh của DB instance mà bạn muốn tạo snapshot. Nó phải trùng với định danh của một DB instance đã tồn tại.

Chia sẻ Snapshot

Nếu bạn cần di chuyển sang tài khoản khác, bạn có thể sử dụng mã sau để chia sẻ snapshot giữa các tài khoản:

bash

Sao chép

aws rds modify-db-snapshot-attribute \

    –db-snapshot-identifier <snapshot-identifier> \

    –attribute-name restore \

    –values-to-add <account-id-to-share-with> \

    –region <region> \

    –profile <profile-name>

Trong đó:

• <snapshot-identifier> – Là định danh cho snapshot DB mà bạn muốn chia sẻ.
• <account-id-to-share-with> – Là ID tài khoản AWS mà bạn muốn chia sẻ snapshot. Bạn có thể chỉ định nhiều tài khoản ID, cách nhau bởi dấu cách.
• <region> – Là AWS Region nơi snapshot đang tồn tại (ví dụ: us-west-2).
• <profile-name> – Tên profile của AWS CLI để sử dụng cho lệnh. Điều này là tùy chọn nếu bạn đang sử dụng profile mặc định.

Nếu bạn sử dụng khóa KMS tùy chỉnh, bạn cần cấp quyền truy cập xuyên tài khoản. Sau khi snapshot được chia sẻ, bạn có thể sao chép snapshot bằng một khóa KMS mới trong tài khoản đích:

bash

Sao chép

aws rds copy-db-cluster-snapshot \

  –source-db-cluster-snapshot-identifier <original-snapshot-identifier> \

  –target-db-cluster-snapshot-identifier <new-snapshot-identifier>  \

  –kms-key-id my-us-east-1-key

Khôi phục cơ sở dữ liệu đích

Sử dụng mã sau để khôi phục cơ sở dữ liệu đích từ snapshot:

bash

Sao chép

aws rds restore-db-cluster-from-snapshot \

–db-cluster-identifier <new-db-cluster-identifier> \

–snapshot-identifier <snapshot-identifier> \

–engine <engine> \

–region <region> \

–profile <profile-name> \

[—optional-parameters]

Trong đó:

• <new-db-cluster-identifier> – Là định danh cho DB cluster mới mà bạn muốn tạo từ snapshot.
• <snapshot-identifier> – Là định danh cho snapshot DB mà bạn muốn khôi phục từ đó.
• <engine> – Tên động cơ cơ sở dữ liệu sẽ được sử dụng cho DB cluster mới (ví dụ: aurora, aurora-mysql, aurora-postgresql).
• <region> – Là Region nơi snapshot đang tồn tại (ví dụ: us-west-2).
• <profile-name> – Tên của profile AWS CLI để sử dụng cho lệnh. Điều này là tùy chọn nếu bạn đang sử dụng profile mặc định.

Mã trên giúp bạn sao lưu, chia sẻ và khôi phục snapshot cơ sở dữ liệu một cách hiệu quả và dễ dàng trong AWS.

Nâng cấp cơ sở dữ liệu đích
Vì không có lộ trình nâng cấp trực tiếp từ phiên bản 10.20 lên 14.3, bước đầu tiên là nâng cấp cơ sở dữ liệu đích lên một phiên bản nhỏ có lộ trình nâng cấp trực tiếp lên 14.3. Để biết danh sách các phiên bản tương thích, tham khảo Nâng cấp Amazon Aurora PostgreSQL DB clusters.
Trong trường hợp này, chúng ta sẽ nâng cấp từ 10.20 lên 10.21, và từ 10.21 lên 14.3.

1. Để nâng cấp từ 10.20 lên 10.21, cập nhật CloudFormation template với:

yaml

Sao chép

RDSEngineVersion: 10.21

2. Để nâng cấp từ 10.21 lên 14.3, cập nhật CloudFormation template với:

yaml

Sao chép

RDSEngineVersion: 14.3

3. Sau khi nâng cấp Aurora PostgreSQL-Compatible lên phiên bản 14.3, thay đổi loại instance (để sử dụng instance Graviton hỗ trợ) và đặt các tham số tùy chỉnh thành true:

yaml

Sao chép

RDSInstanceClass: db.r6g.4xlarge

RDSEngineVersion: 14.3

RDSEnableCustomParameters: true

4. Cập nhật các tham số cho cluster và instance của cơ sở dữ liệu đích và đảm bảo rằng MAX_WORKER_PROCESSES được cấu hình. Giá trị này phải lớn hơn hoặc bằng số lượng cơ sở dữ liệu mà bạn dự định di chuyển vào cluster này. Ví dụ, nếu bạn đang di chuyển 10 cơ sở dữ liệu từ nguồn sang đích, thì giá trị này phải được đặt tối thiểu là 10.
5. Trên cơ sở dữ liệu đích:

sql

Sao chép

database_name=> show MAX_WORKER_PROCESSES;

6. Kết quả:

text

Sao chép

max_worker_processes

———————-

32

Cấu hình AWS DMS
Trong phần này, chúng ta sẽ tập trung vào cấu hình môi trường AWS DMS, bao gồm các instance sao chép và các tác vụ sao chép. Để biết thêm thông tin, tham khảo Set up replication for AWS Database Migration Service.

Khi cấu hình endpoint nguồn cho cluster PostgreSQL nguồn, bạn phải chỉ định tên slot sao chép mà bạn đã tạo trước đó.

Các lưu ý quan trọng khi cấu hình hạ tầng AWS DMS cho việc di chuyển cơ sở dữ liệu quy mô lớn với thời gian gián đoạn tối thiểu:

• Tách các tác vụ xác minh và tác vụ di chuyển chính của AWS DMS để giảm thiểu rủi ro và chi phí phát sinh khi di chuyển thất bại. Điều này cũng giúp cải thiện throughput của tác vụ di chuyển dữ liệu.
• Nếu cơ sở dữ liệu có các kiểu dữ liệu LOB (Large Object), hãy cân nhắc thiết lập kích thước tối đa của LOB khi độ trễ di chuyển cao. Điều này giúp tăng throughput.
• Đặt instance AWS DMS trong cùng một Availability Zone với cơ sở dữ liệu nguồn để giảm độ trễ và chi phí chuyển dữ liệu giữa các Availability Zones.
• Tác vụ xác minh sử dụng bộ nhớ trên instance sao chép; càng có nhiều bộ nhớ, quá trình xác minh càng nhanh chóng. Chọn một instance với đủ bộ nhớ để đảm bảo quá trình xác minh diễn ra nhanh chóng và hiệu quả khi chuyển từ trạng thái PENDING.
• Để đạt được tốc độ chuyển dữ liệu nhanh chóng từ nguồn sang đích, khuyến nghị chọn một instance sao chép với CPU và tốc độ mạng cao hơn, ưu tiên sử dụng các instance r6i cho bộ nhớ lớn hơn và oversize instance sao chép để có quá trình di chuyển nhanh hơn.

Theo dõi tiến trình di chuyển

Trong phần này, chúng ta sẽ thảo luận về các phương pháp khác nhau để theo dõi tiến trình di chuyển dữ liệu.

Thời gian bắt đầu nhập dữ liệu

Nếu bạn muốn theo dõi thời gian bắt đầu của việc nhập dữ liệu, hãy sử dụng script sau. Script này lặp qua hàm AWS DMS task (describe-table-statistics) và theo dõi khi dữ liệu được chèn vào bất kỳ bảng nào. Timestamp cuối cùng sẽ là thời gian dữ liệu bắt đầu được nhập vào cơ sở dữ liệu đích.

bash

Sao chép

#!/bin/bash

# Check if task ARN is provided

if [ -z “$1” ]; then

    echo “Usage: $0 <task-arn>”

    exit 1

fi

TASK_ARN=”$1″

REGION=”us-east-1″

PREVIOUS_TOTAL=0

START_TIME=””

echo “Monitoring DMS task: $TASK_ARN”

echo “Waiting for ingestion to begin…”

while true; do

    # Get total inserts across all tables

    CURRENT_TOTAL=$(aws dms describe-table-statistics \

        –replication-task-arn “$TASK_ARN” \

        –region “$REGION” \

        –query ‘sum(TableStatistics[].Inserts)’ \

        –output text)

    # Check if ingestion has started

    if [ “$CURRENT_TOTAL” -gt “$PREVIOUS_TOTAL” ]; then

        if [ -z “$START_TIME” ]; then

            START_TIME=$(date ‘+%Y-%m-%d %H:%M:%S’)

            echo “Ingestion started at: $START_TIME”

        fi

        echo “Total records inserted: $CURRENT_TOTAL”

    fi

    PREVIOUS_TOTAL=$CURRENT_TOTAL

    sleep 30

done

Giải thích mã script:

• Mã script này theo dõi sự thay đổi trong số lượng bản ghi được chèn vào các bảng trong quá trình di chuyển dữ liệu.
• Nếu số bản ghi chèn vào các bảng tăng lên, nó sẽ ghi lại thời gian bắt đầu nhập dữ liệu và thông báo số lượng bản ghi đã được chèn.
• sleep 30 giúp script chạy sau mỗi 30 giây để kiểm tra lại trạng thái của tác vụ DMS.

Bạn có thể sử dụng mã này để theo dõi tiến trình di chuyển và xác định thời gian bắt đầu khi dữ liệu bắt đầu được nhập vào cơ sở dữ liệu đích.

Giám sát các tác vụ xác minh dữ liệu

Script sau đây thực hiện xác minh dữ liệu giữa cơ sở dữ liệu nguồn và đích cho các bảng được chỉ định. Nó đọc các truy vấn SQL từ một tệp (verify-${DBTYPE}-sql.txt), thực thi chúng trên cả cơ sở dữ liệu nguồn và đích, so sánh kết quả và ghi lại bất kỳ sự khác biệt nào.

bash

Sao chép

#!/bin/bash

SOURCE_SQL_RESULT_DUMP_FILE=./temp-source-sql-data-dump.txt

TARGET_SQL_RESULT_DUMP_FILE=./temp-target-sql-data-dump.txt

DATA_VERIFY_RESULTS_FILE=./temp-data-verify-results.txt

while getopts “t:s:m:l:d:h:p:u:c:H:P:U:C:D:?” optKey; do

  case “${optKey}” in

    t) TIME=${OPTARG} ;;

    s) SMALL=${OPTARG} ;;

    m) MEDIUM=${OPTARG} ;;

    l) LARGE=${OPTARG} ;;

    d) DATABASE=${OPTARG} ;;

    h) SOURCE_HOST=${OPTARG} ;;

    p) SOURCE_PORT=${OPTARG} ;;

    u) SOURCE_USERNAME=${OPTARG} ;;

    c) SOURCE_PASSWORD=${OPTARG} ;;

    H) TARGET_HOST=${OPTARG} ;;

    P) TARGET_PORT=${OPTARG} ;;

    U) TARGET_USERNAME=${OPTARG} ;;

    C) TARGET_PASSWORD=${OPTARG} ;;

    D) DBTYPE=${OPTARG} ;;

    ?) usage ;;

  esac

done

rm -f ${SOURCE_SQL_RESULT_DUMP_FILE} ${TARGET_SQL_RESULT_DUMP_FILE} ${DATA_VERIFY_RESULTS_FILE}

created_on_offset=”‘$TIME’”

sql_replace() { 

  echo “$1” | sed -e “s/\$CREATED_DATE/$created_on_offset/g” -e “s/\$COUNT1/$SMALL/g” -e “s/\$COUNT2/$MEDIUM/g” -e “s/\$COUNT3/$LARGE/g”; 

}

declare -a TABLE_NAMES=() 

SOURCE_DIFF_COUNT=() 

TARGET_DIFF_COUNT=() 

ZERO_DATA_SOURCE=() 

ZERO_DATA_TARGET=()

i=0

while IFS=” read -r line; do

  table=$(echo “$line” | cut -d”@” -f1)

  sql=$(sql_replace “$(echo “$line” | cut -d”@” -f2)”)

  echo “Validating table: $table”

  TABLE_NAMES[$i]=”$table”

  # Execute SQL on source and target databases

  echo “$sql” | PGPASSWORD=”${SOURCE_PASSWORD}” psql -h “${SOURCE_HOST}” -p “${SOURCE_PORT}” -U “${SOURCE_USERNAME}” -d “${DATABASE}” > “${SOURCE_SQL_RESULT_DUMP_FILE}”

  echo “$sql” | PGPASSWORD=”${TARGET_PASSWORD}” psql -h “${TARGET_HOST}” -p “${TARGET_PORT}” -U “${TARGET_USERNAME}” -d “${DATABASE}” > “${TARGET_SQL_RESULT_DUMP_FILE}”

  # Compare the results between source and target

  SOURCE_DIFF_COUNT[$i]=$(diff -b -w $TARGET_SQL_RESULT_DUMP_FILE $SOURCE_SQL_RESULT_DUMP_FILE –new-line-format=’Source missing %L’ | wc -l)

  TARGET_DIFF_COUNT[$i]=$(diff -b -w $SOURCE_SQL_RESULT_DUMP_FILE $TARGET_SQL_RESULT_DUMP_FILE –new-line-format=’Target missing %L’ | wc -l)

  # Check if the result is zero rows

  [[ $(tail -n2 “${SOURCE_SQL_RESULT_DUMP_FILE}”) == “(0 rows)” ]] && ZERO_DATA_SOURCE[$i]=1 || ZERO_DATA_SOURCE[$i]=0

  [[ $(tail -n2 $TARGET_SQL_RESULT_DUMP_FILE) == “(0 rows)” ]] && ZERO_DATA_TARGET[$i]=1 || ZERO_DATA_TARGET[$i]=0

  # If there are any differences, log the failure

  if [[ “${SOURCE_DIFF_COUNT[$i]}” -ne 0 || “${TARGET_DIFF_COUNT[$i]}” -ne 0 ]]; then

    echo “Failure in table=$table” >> $DATA_VERIFY_RESULTS_FILE

  fi

  rm $SOURCE_SQL_RESULT_DUMP_FILE $TARGET_SQL_RESULT_DUMP_FILE

  ((i++))

done < “/var/task/bin/verify-${DBTYPE}-sql.txt”

echo “==================================================================”

printf “%-20s %-20s %-15s %-15s\n” “Table” “Result” “Source Miss” “Target Miss”

for ((idx=0; idx<${#TABLE_NAMES[@]}; ++idx)); do

  result=”PASS”

  [[ “${ZERO_DATA_SOURCE[idx]}” -eq 1 && “${ZERO_DATA_TARGET[idx]}” -eq 1 ]] && result=”PASS (0 rows)”

  [[ “${ZERO_DATA_SOURCE[idx]}” -eq 0 && “${ZERO_DATA_TARGET[idx]}” -eq 1 ]] && result=”FAIL (Target 0 rows)”

  [[ “${SOURCE_DIFF_COUNT[idx]}” -ne 0 || “${TARGET_DIFF_COUNT[idx]}” -ne 0 ]] && result=”FAIL”

  printf “%-20s %-20s %-15s %-15s\n” “${TABLE_NAMES[idx]}” “$result” “${SOURCE_DIFF_COUNT[idx]}” “${TARGET_DIFF_COUNT[idx]}”

done

Giải thích mã script:

• Các tham số đầu vào: Các tham số như thời gian, tên cơ sở dữ liệu, tên máy chủ, cổng và thông tin xác thực cho cơ sở dữ liệu nguồn và đích được lấy từ dòng lệnh.
• Xử lý SQL: Script đọc các truy vấn SQL từ file verify-${DBTYPE}-sql.txt, thay thế các biến trong SQL như $CREATED_DATE, $COUNT1, $COUNT2, $COUNT3 bằng các giá trị thực tế.
• Thực thi SQL: Mỗi truy vấn SQL được thực thi trên cả cơ sở dữ liệu nguồn và đích.
• So sánh kết quả: Kết quả của các truy vấn từ cơ sở dữ liệu nguồn và đích được so sánh bằng lệnh diff và ghi lại các sự khác biệt.
• Kiểm tra dữ liệu: Nếu không có dữ liệu (0 rows), script ghi nhận kết quả và đánh giá dữ liệu có đúng với dự liệu mong đợi hay không.

Kết quả cuối cùng:

• Script in ra bảng kết quả gồm tên bảng, kết quả xác minh (PASS/FAIL), và số lượng bản ghi bị thiếu ở nguồn và đích

Tỷ lệ nhập dữ liệu từ nguồn

Sử dụng một script tùy chỉnh để theo dõi tỷ lệ nhập dữ liệu tại cơ sở dữ liệu nguồn và đích cung cấp một cái nhìn chi tiết hơn về luồng dữ liệu gần thời gian thực và cung cấp những thông tin cụ thể về số lượng bản ghi và khoảng thời gian. Lệnh sau theo dõi tỷ lệ nhập dữ liệu cho một bảng (source_table) dựa trên số bản ghi được tạo trong 5 phút qua:

sql

Sao chép

SELECT COUNT(id), date_trunc(‘minute’, created_on) AS truncated_time 

FROM source_table 

WHERE created_on > NOW() – interval ‘5 minutes’ 

GROUP BY truncated_time 

ORDER BY truncated_time;

Tỷ lệ nhập dữ liệu vào đích

Lệnh này tương tự như ví dụ trước cho cơ sở dữ liệu nguồn, nhưng cho cơ sở dữ liệu đích. Sau đó, bạn có thể so sánh tỷ lệ nhập dữ liệu giữa nguồn và đích để xác định tốc độ nhập liệu của AWS DMS so với nhập liệu qua API. Lưu ý rằng đây không phải là một phương pháp hoàn hảo, nó chỉ đơn giản là một cách để theo dõi tỷ lệ nhập dữ liệu ở mức độ cao.

Độ trễ CDC

Để khắc phục sự cố độ trễ trong AWS DMS, bạn cũng có thể giám sát các chỉ số CDCLatencySource và CDCLatencyTarget trong CloudWatch. Để biết thêm chi tiết, tham khảo Types of CDC latency.

Thực hiện chuyển giao (Cutover)

Sau khi cơ sở dữ liệu đích đã đồng bộ với cơ sở dữ liệu nguồn và bạn có thể xác nhận rằng dữ liệu đã được di chuyển thành công và hoàn thành xác minh, bạn có thể thực hiện chuyển giao ứng dụng. Dưới đây là một số yếu tố cần xem xét trước khi thực hiện cutover:

• Thay đổi cấu hình – Ứng dụng lấy một phần cấu hình cơ sở dữ liệu của mình từ một bảng nội bộ, đặc biệt là giá trị dbhost, điều khiển kết nối cơ sở dữ liệu. Bằng cách cập nhật dbhost trong cấu hình của ứng dụng, bạn có thể trỏ nó đến một cơ sở dữ liệu mới (như AURORA02). Việc này giúp tránh nhầm lẫn về các chi tiết của nơi và cách mà bảng ứng dụng được lưu trữ, đơn giản hóa quá trình chỉ bằng việc thay đổi cấu hình.
• Tăng giá trị sequence – Bắt đầu bằng cách xác định tất cả các số sequence trong cơ sở dữ liệu đích (cơ sở dữ liệu đang chuyển giao). Tiếp theo, tạo một truy vấn để tăng giá trị sequence ID. Trong kịch bản này, chúng ta chọn một offset tùy ý là 500,000, mặc dù số này có thể thay đổi. Điều quan trọng là đảm bảo cơ sở dữ liệu nguồn không bắt kịp với đích trong quá trình chuyển giao. Giá trị offset càng lớn, việc này càng an toàn—nên chọn một giá trị cao hơn để tạo ra một vùng đệm.
• Vacuum và phân tích bảng – Chạy lệnh vacuum và analyze trên các bảng trong instance cơ sở dữ liệu đích để đảm bảo hiệu suất tối ưu.

Kết luận

Trong bài viết này, chúng tôi đã trình bày cách Fluent Commerce sử dụng AWS DMS với sao chép liên tục và xác minh dữ liệu để giảm thiểu sự gián đoạn trong các giờ cao điểm, mang lại trải nghiệm liền mạch cho khách hàng thương mại điện tử toàn cầu của họ. Bằng cách sử dụng snapshot và restore như một bước trước khi thực hiện CDC, họ đã thực hiện việc di chuyển một cách hiệu quả và tiết kiệm chi phí—đặc biệt có lợi cho các cơ sở dữ liệu quy mô lớn. Kết quả và các chỉ số hiệu suất của Fluent Commerce làm nổi bật những ưu điểm của phương pháp này, giảm thời gian di chuyển một cách đáng kể so với các phương pháp tải đầy đủ truyền thống. Sự kết hợp giữa snapshot và CDC không chỉ tăng tốc quá trình mà còn nâng cao độ tin cậy, cho phép sao chép liên tục với ít tác động đến hiệu suất của cơ sở dữ liệu nguồn.

Kinh nghiệm của bạn với việc di chuyển cơ sở dữ liệu là gì? Hãy chia sẻ suy nghĩ của bạn trong phần bình luận.

---

About the authors

Adrian Cook

Adrian là một Kỹ sư DevOps tại Fluent Commerce, chuyên về các dịch vụ AWS và hạ tầng đám mây. Anh đóng vai trò quan trọng trong việc di chuyển và nâng cấp cơ sở dữ liệu, tận dụng các pipeline CI/CD để tối ưu hóa và tự động hóa quy trình triển khai. Với sự tập trung mạnh mẽ vào khả năng mở rộng và độ tin cậy, Adrian đam mê tạo điều kiện cho các hoạt động đám mây liền mạch trên các môi trường toàn cầu.

Roneel Kumar

Roneel là một Kiến trúc sư Giải pháp Chuyên gia Cơ sở Dữ liệu Cao cấp tại AWS, với chuyên môn sâu về các động cơ cơ sở dữ liệu quan hệ. Anh hợp tác với khách hàng để cung cấp hướng dẫn kỹ thuật, tối ưu hóa hoạt động cơ sở dữ liệu và triển khai các phương pháp tốt nhất cho hiệu suất, khả năng mở rộng và độ bền. Roneel đam mê giúp các tổ chức hiện đại hóa cơ sở hạ tầng dữ liệu của họ và thúc đẩy đổi mới thông qua các kiến trúc đám mây.

Warren Wei

Warren là một Kiến trúc sư Giải pháp Cao cấp tại AWS, nơi anh giúp khách hàng thiết kế và xây dựng các giải pháp mở rộng, bảo mật và tiết kiệm chi phí trên đám mây. Với nền tảng vững chắc trong kiến trúc đám mây và hiện đại hóa ứng dụng, Warren hợp tác với các tổ chức để thúc đẩy quá trình chuyển đổi số và đạt được thành công lâu dài. Anh đam mê giải quyết các thách thức kỹ thuật phức tạp và thúc đẩy đổi mới thông qua các công nghệ đám mây.