Tác giả: Sukhpreet Kaur Bedi, Raluca Constantin và Rajesh Kantamani
Ngày đăng: 07/01/2026
Danh mục: Advanced (300), Amazon Aurora, DSQL, Technical How-to

Amazon Aurora DSQL là cơ sở dữ liệu phân tán, serverless, tương thích PostgreSQL với khả năng mở rộng gần như không giới hạn, tính sẵn sàng cao nhất và không cần quản lý hạ tầng. Aurora DSQL loại bỏ nhu cầu sharding cơ sở dữ liệu và nâng cấp instance, đồng thời hỗ trợ triển khai cả single-Region và multi-Region. Aurora DSQL cung cấp các endpoint theo từng Region dành riêng cho mỗi Region trong cụm multi-Region, cho phép ứng dụng kết nối trực tiếp tới Region tối ưu nhất nhằm đạt độ trễ thấp nhất có thể. Kiến trúc của Aurora DSQL đảm bảo tính nhất quán dữ liệu mạnh cho cả đọc và ghi, với mức sẵn sàng 99,99% trong triển khai single-Region và 99,999% trong triển khai multi-Region nhờ thiết kế phân tán active-active.

Các ứng dụng sử dụng cụm Aurora DSQL multi-Region nên triển khai giải pháp định tuyến dựa trên DNS (chẳng hạn như Amazon Route 53) để tự động chuyển hướng lưu lượng giữa các AWS Region. Điều này đảm bảo tính liên tục của hoạt động trong trường hợp một cụm Aurora DSQL hoặc toàn bộ một AWS Region không thể truy cập.

Các best practice khuyến nghị triển khai logic định tuyến ở cấp ứng dụng để quản lý failover giữa các Region một cách tổng thể. Tuy nhiên, khi ứng dụng của bạn phụ thuộc vào nhiều data store, bao gồm cả Aurora DSQL, bạn cần một chiến lược riêng để xử lý các tình huống endpoint Aurora DSQL theo Region không thể truy cập. Trong bài viết này, chúng tôi giới thiệu một giải pháp tự động giúp chuyển hướng lưu lượng truy cập cơ sở dữ liệu sang các endpoint Region thay thế mà không cần thay đổi cấu hình thủ công, đặc biệt phù hợp với môi trường sử dụng nhiều data store khác nhau.

Quản lý endpoint cho các cụm Aurora DSQL multi-Region:

Hãy cùng xem xét kiến trúc ứng dụng multi-Region, sử dụng Amazon Aurora DSQL làm tầng lưu trữ dữ liệu.

Các cụm Aurora DSQL multi-Region sử dụng cơ chế replication đồng bộ xuyên Region để duy trì tính nhất quán mạnh giữa các Region (và giữa Region witness của DSQL, không được hiển thị trong sơ đồ). DSQL có thể chấp nhận cả đọc và ghi trên bất kỳ endpoint Region nào và, nhờ tính nhất quán mạnh của Aurora DSQL, một client đọc ở Region A có thể ngay lập tức thấy dữ liệu ghi đã được commit ở Region B và ngược lại. Đặc tính này của DSQL giúp việc xây dựng các ứng dụng multi-Region active-active trở nên đơn giản hơn rất nhiều.

Vì DSQL đảm bảo dữ liệu nhất quán trên toàn bộ các Region, tầng ứng dụng thậm chí không cần biết rằng nó đang hoạt động trong cấu hình multi-Region active-active. Ứng dụng có thể hoàn toàn không nhận thức được sự tồn tại của Region khác. Ứng dụng không cần thực hiện bất kỳ cơ chế điều phối hoặc messaging xuyên Region nào — DSQL sẽ xử lý tất cả.

Với Aurora DSQL, bạn không cần lo lắng về các thao tác failover hay switchover của cơ sở dữ liệu vì dịch vụ sẽ tự động xử lý. Tuy nhiên, trong một số kịch bản cụ thể — chẳng hạn khi ứng dụng sử dụng nhiều data store cho các API khác nhau, hoặc khi ứng dụng kết nối từ một datacenter bên ngoài tới các cụm DSQL multi-Region — việc chuyển đổi trực tiếp giữa các endpoint DSQL sẽ hiệu quả hơn so với việc chuyển hướng toàn bộ endpoint của application server. Cách tiếp cận này giúp giảm độ phức tạp trong vận hành và giảm thiểu công sức cần thiết khi xảy ra gián đoạn dịch vụ, vì chỉ tác động tới các kết nối cơ sở dữ liệu bị ảnh hưởng thay vì toàn bộ application stack. Bất kỳ sự kiện nào gây gián đoạn cụm DSQL theo Region cũng rất có khả năng ảnh hưởng tới tính sẵn sàng của ứng dụng trong Region đó. Chúng tôi trình bày một giải pháp tự động giúp kết nối ứng dụng tới endpoint Region còn khả dụng trong trường hợp endpoint Region gặp sự cố trong mô hình cụm DSQL multi-Region.

Giải pháp được thảo luận trong bài viết này được cung cấp dưới dạng mã mẫu trên GitHub.

Tổng quan giải pháp

Trong giải pháp này, chúng tôi trình bày cách triển khai cơ chế tự động chuyển hướng kết nối từ ứng dụng giữa các endpoint Aurora DSQL bằng một thư viện Python tùy chỉnh chạy phía client. Khi được triển khai, thư viện sẽ giám sát các endpoint Aurora DSQL thông qua API của Amazon Route 53. Thư viện trước tiên xác định các endpoint đang ở trạng thái healthy thông qua các health check, sau đó đo độ trễ giữa client và từng endpoint healthy. Dựa trên kết quả này, thư viện tự động định tuyến kết nối của client tới endpoint healthy có độ trễ thấp nhất, đồng thời đảm bảo rằng trong trường hợp hiếm hoi khi một endpoint Region không thể truy cập, các kết nối client sẽ được chuyển sang endpoint Aurora DSQL healthy có độ trễ thấp nhất. Và nhờ tính nhất quán mạnh của Aurora DSQL, client có thể ngay lập tức thấy kết quả của tất cả các transaction đã được commit thành công trên bất kỳ endpoint nào.

Hãy cùng xem các tính năng chính của giải pháp này:

• Tự động lựa chọn endpoint – Để cung cấp kết nối tối ưu, giải pháp này duy trì một danh sách động các endpoint cụm cơ sở dữ liệu khả dụng và thường xuyên thực hiện kiểm tra độ trễ tới các endpoint đó, từ đó tạo ra danh sách xếp hạng dựa trên thời gian phản hồi. Thứ hạng này sau đó được kết hợp với các thiết lập ưu tiên được định nghĩa sẵn trong file cấu hình. Dựa trên độ trễ tới từng endpoint, hệ thống sẽ chọn endpoint tốt nhất cho mỗi kết nối.
• Route 53 health checks – Giải pháp này tích hợp với Route 53 health checks, tận dụng hạ tầng toàn cầu của AWS để giám sát trạng thái một cách toàn diện. Cách tiếp cận này mang lại một hệ thống linh hoạt và mạnh mẽ để duy trì tình trạng endpoint và hỗ trợ quyết định định tuyến.
• Hỗ trợ failover kết nối tự động – Để duy trì tính sẵn sàng cao và giảm thiểu downtime cho ứng dụng, giải pháp liên tục giám sát tình trạng của từng endpoint cụm cơ sở dữ liệu theo Region. Khi phát hiện sự cố với endpoint hiện tại, hệ thống sẽ tự động chuyển hướng các kết nối client sang các endpoint healthy khác. Điều này đảm bảo các ứng dụng client luôn duy trì được quyền truy cập cơ sở dữ liệu, ngay cả khi một endpoint cụ thể không thể truy cập. Giải pháp này quản lý việc client sẽ thiết lập kết nối cơ sở dữ liệu tới Region nào, giúp giảm thiểu gián đoạn trải nghiệm người dùng vì ứng dụng có thể chuyển đổi mượt mà sang các endpoint khả dụng mà không cần can thiệp thủ công.

Sơ đồ sau minh họa workflow của giải pháp.

Workflow bao gồm các bước sau:

1. Client (chạy trong bất kỳ Region nào nơi cụm được triển khai) gọi hàm get_connection() để khởi tạo kết nối, sau đó thư viện sẽ đánh giá các endpoint DSQL khả dụng và thiết lập kết nối tối ưu dựa trên các chỉ số về tình trạng và hiệu năng.
2. Thư viện tham chiếu các Route 53 health check để lấy trạng thái endpoint theo thời gian thực. Các health check này chạy theo chu kỳ 30 giây, cung cấp thông tin gần như cập nhật liên tục về khả năng truy cập endpoint và giám sát các dấu hiệu suy giảm hoặc lỗi.
3. Dựa trên dữ liệu health check, thư viện kết nối tới endpoint healthy. Nếu endpoint chính gặp sự cố, hệ thống sẽ tự động chuyển hướng sang các endpoint healthy khác.

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

Để triển khai giải pháp này, bạn cần hoàn thành các điều kiện sau:

• Tạo một cụm Aurora DSQL multi-Region và ghi lại giá trị cluster id và endpoint cho cả hai Region.
• Đảm bảo Python phiên bản 3.10 trở lên đã được cài đặt trên hệ thống. Xác minh bằng cách chạy lệnh sau trong terminal:python3 --version
• Có AWS credentials với quyền truy cập DSQL phù hợp. Cấu hình credentials này bằng AWS Command Line Interface (AWS CLI) hoặc thông qua biến môi trường.
• Xác minh rằng hệ thống của bạn có quyền truy cập mạng tới các endpoint DSQL. Điều này có thể yêu cầu cấu hình Amazon Virtual Private Cloud (VPC) hoặc security group.
• Xác nhận rằng AWS credentials của bạn có quyền tạo và quản lý Route 53 health checks.

Cài đặt Python, các package phụ thuộc và cấu hình AWS CLI

Thực hiện các bước sau:

1. Clone repository: git clone https://github.com/aws-samples/sample-multi-region-Endpoint-Routing-for-Aurora-DSQL.git cd sample-multi-region-Endpoint-Routing-for-Aurora-DSQL
2. Thiết lập môi trường Python và tạo virtual environment mới có tên venv: python3 -m venv venv source venv/bin/activate # Trên Windows: venv\Scripts\activate
3. Cài đặt các dependency cần thiết trong file requirements.txt để chạy giải pháp:pip install -r requirements.txt
4. Cấu hình AWS CLI. Điều này cung cấp một cách thuận tiện để thiết lập credentials dùng chung:aws login
5. Làm theo các hướng dẫn hiển thị trong terminal. Lệnh này sẽ tự động mở trình duyệt mặc định và hướng dẫn bạn qua quá trình xác thực. Sau khi xác thực thành công, phiên AWS CLI của bạn sẽ có hiệu lực tối đa 12 giờ.

Thiết lập file cấu hình và Route 53 health checks

Repository trên GitHub chứa một file cấu hình có tên dsql_config_with_healthchecks.json. File này có cấu trúc tương tự ví dụ sau. Bạn cần chỉnh sửa các trường sau:

• Với cả hai Region, cập nhật trường cluster_id bằng các cluster ID đã ghi lại ở phần điều kiện tiên quyết.
• Thay thế trường hostname bằng endpoint DSQL theo Region mà bạn đã ghi lại trước đó.
• { "endpoints": [ { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-1>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" }, { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-2>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } }

Chạy lệnh sau trong terminal để tạo Route 53 health checks cho các endpoint của bạn:

python3 hybrid_failover_approach.py --setup --config dsql_config_with_healthchecks.json

Các tham số trong script này bao gồm:

• –config – Tham số này chỉ định đường dẫn tới file cấu hình. File cấu hình là file JSON dsql_config_with_healthchecks.json, chứa thông tin về các endpoint DSQL và thiết lập kết nối.
• –setup – Tham số này tạo các Route 53 health check và cập nhật giá trị health_check_id cho từng endpoint trong file cấu hình dsql_config_with_healthchecks.json.
• –test – Tham số này dùng để chạy các bài kiểm tra kết nối.

Script sẽ đọc file cấu hình của bạn, tạo một health check trong Route 53 cho mỗi endpoint, và cập nhật file cấu hình với các health check ID vừa được tạo. Trường health_check_id là định danh duy nhất cho health check Route 53 được gắn với từng endpoint.

{ "endpoints": [ { "cluster_id": "<your-cluster-id-1>", "region": "us-east-1", "hostname": "<your-hostname-1.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "57a713b9-a58f-4ae5-baaa-70cf62ca78eb" }, { "cluster_id": "<your-cluster-id-2>", "region": "us-east-2", "hostname": "<your-hostname-2.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "37d3a545-2917-4e8f-9e44-f7d5e9b966a7" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } }

Kiểm tra kết nối với Route 53 health checks và định tuyến độ trễ phía client

Để kiểm tra kết nối cơ bản tới các endpoint DSQL, hãy chạy lệnh sau. Script này kết hợp đo độ trễ phía client để lựa chọn endpoint tối ưu, sử dụng Route 53 health checks để giám sát tình trạng tin cậy, và khả năng failover tự động nhằm đảm bảo dịch vụ luôn sẵn sàng.

python3 hybrid_failover_approach.py --test --config dsql_config_with_healthchecks.json --database postgres --user admin

Kiểm tra failover với Route 53 health checks

Bài kiểm tra này mô phỏng một kịch bản lỗi và xác minh rằng hệ thống phản hồi đúng cách. Chạy script kiểm tra với lệnh sau:

python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin

Script này thực hiện một loạt các thao tác để xác thực cơ chế failover của ứng dụng (hoặc kết nối client):

1. Đầu tiên, script thiết lập kết nối tới endpoint khả dụng tối ưu dựa trên các ưu tiên cấu hình.
2. Sau khi đã kết nối, script cố ý vô hiệu hóa Route 53 health check gắn với endpoint chính để mô phỏng sự cố.
3. Script chờ trạng thái health check được lan truyền trong mạng AWS, tái hiện điều kiện lỗi trong thực tế.
4. Sau đó, script cố gắng tạo một kết nối mới, lúc này kết nối sẽ được failover sang endpoint phụ do endpoint chính đã bị mô phỏng lỗi.
5. Trong quá trình này, script xác minh rằng hệ thống đã failover thành công sang endpoint phụ, đảm bảo hoạt động liên tục dù endpoint chính gặp sự cố.
6. Sau khi xác nhận failover thành công, script bật lại health check cho endpoint chính và xác minh rằng các kết nối có thể được thiết lập lại tới endpoint chính đã được khôi phục.

python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin;

2025-05-21 19:03:52,864 - main - INFO - === STEP 1: Testing connection under normal conditions === 2025-05-21 19:03:52,866 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json ... 2025-05-21 19:06:00,212 - main - INFO - RESULT: Route 53 failover test SUCCESSFUL!

Sử dụng DSQL connection manager trong ứng dụng của bạn

Sau khi có file hybrid_failover_approach.py, việc tích hợp nó vào ứng dụng của bạn là rất đơn giản. Connection manager được thiết kế như một thành phần thay thế trực tiếp cho kết nối cơ sở dữ liệu — không cần tiến trình nền hay thiết lập phức tạp.

Ví dụ tổng quát về cách sử dụng connection manager trong ứng dụng:

`from hybrid_failover_approach import DSQLHybridConnectionManager

#Khởi tạo một lần khi ứng dụng khởi động

db_manager = DSQLHybridConnectionManager(config_file=”dsql_config_with_healthchecks.json”)

#Sử dụng ở mọi nơi cần kết nối

conn = db_manager.get_connection(“postgres”, “admin”)`

Trước tiên, hãy cấu hình các endpoint DSQL của bạn bằng cách chỉnh sửa file dsql_config_with_healthchecks.json.

Đoạn mã sau minh họa một ví dụ thực tế trong ứng dụng Flask:

`from flask import Flask, jsonify
from hybrid_failover_approach import DSQLHybridConnectionManager

app = Flask(name)
db_manager = DSQLHybridConnectionManager(config_file=”dsql_config_with_healthchecks.json”)

@app.route(‘/users’)
def get_users():

#Tự động kết nối tới endpoint nhanh nhất và healthy nhất

conn = db_manager.get_connection(“postgres”, “admin”)

try:
with conn.cursor() as cursor:
cursor.execute(“SELECT id, name, email FROM users”)
return jsonify(cursor.fetchall())
finally:
conn.close()`

Ưu điểm của cách tiếp cận này nằm ở sự đơn giản — bạn có được khả năng định tuyến thông minh, failover tự động và giám sát tình trạng mà không cần quản lý bất kỳ tiến trình nền hay hạ tầng phức tạp nào. Đây là một cách thông minh hơn để kết nối tới các cụm DSQL của bạn.

Dọn dẹp tài nguyên

Để xóa các health check, hãy sử dụng AWS CLI với các health check ID đã được thêm vào file cấu hình trong quá trình thiết lập:

aws route53 delete-health-check --health-check-id <health-check-id>

Bạn có thể tìm các health check ID trong file dsql_config_with_healthchecks.json ở trường health_check_id của từng endpoint. Chạy lệnh xóa cho từng health check ID trong cấu hình của bạn.

Cấu hình health check

Bạn có thể tùy chỉnh tần suất health check trong DSQL connection manager:

health_check_ttl=60, # Cache kết quả health check trong 60 giây

Tham số health_check_ttl lưu cache kết quả health check trong khoảng thời gian được chỉ định. Giá trị thấp (< 60 giây) cho phép failover nhanh hơn nhưng làm tăng số lượng API call tới Route 53, trong khi giá trị cao hơn sẽ giảm tải API nhưng có thể làm chậm việc phát hiện sự cố. Hãy bắt đầu với 60 giây và điều chỉnh khi cần thiết.

Tổng kết

Trong bài viết này, chúng tôi đã trình bày một giải pháp tùy chỉnh cung cấp một cách hiệu quả để quản lý kết nối Aurora DSQL với khả năng failover kết nối xuyên Region tự động. Bằng cách triển khai giải pháp này, bạn có thể cung cấp khả năng kết nối cơ sở dữ liệu đáng tin cậy cho các ứng dụng, đồng thời duy trì hiệu năng và tính sẵn sàng tối ưu.

Hãy thử giải pháp này cho use case của riêng bạn và chia sẻ phản hồi của bạn trong phần bình luận.

Tác giả

Rajesh Kantamani
Rajesh là Senior Database Specialist Solutions Architect. Anh hợp tác cùng khách hàng để thiết kế, di chuyển và tối ưu hóa các giải pháp cơ sở dữ liệu trên Amazon Web Services, tập trung vào khả năng mở rộng, bảo mật và hiệu năng. Với niềm đam mê dành cho các cơ sở dữ liệu phân tán, anh giúp các tổ chức chuyển đổi hạ tầng dữ liệu của mình.

Sukhpreet Kaur Bedi
Sukhpreet là Senior Database Specialist Solutions Architect tại AWS, tập trung vào các engine Amazon RDS/Aurora PostgreSQL. Cô hỗ trợ khách hàng đổi mới trên nền tảng AWS bằng cách xây dựng các kiến trúc cơ sở dữ liệu có tính sẵn sàng cao, khả năng mở rộng và bảo mật.

Raluca Constantin
Raluca là Senior Database Engineer tại AWS, chuyên sâu về Amazon Aurora DSQL. Với 18 năm kinh nghiệm trong lĩnh vực cơ sở dữ liệu trải dài trên Oracle, MySQL, PostgreSQL và các giải pháp cloud-native, cô tập trung vào khả năng mở rộng, hiệu năng và xử lý dữ liệu thời gian thực.