Hiểu các điểm cuối Amazon Aurora

Nếu bạn đã từng sử dụng Aurora Read Replicas, bạn có thể nhận thấy rằng có sẵn các điểm cuối khác nhau. Điểm cuối của cụm , Điểm cuối của trình đọc và Điểm cuối phiên bản … Với tất cả các tùy chọn này, làm thế nào để bạn biết cái nào sẽ sử dụng và khi nào? Như với bất kỳ hệ thống không tầm thường nào, câu trả lời là… điều đó còn tùy thuộc.

Trước tiên, hãy liên hệ với các điểm cuối khác nhau có sẵn với Amazon Aurora.

• Điểm cuối của cụm - Điểm cuối của cụm kết nối ứng dụng của bạn với phiên bản DB chính hiện tại cho cụm DB đó. Ứng dụng của bạn có thể vừa đọc vừa ghi vào phiên bản này.

• Điểm cuối của trình đọc - Điểm cuối của trình đọc các kết nối cân bằng tải trong nhóm các Bản sao Đọc sẵn có. Giảm tải các truy vấn đã đọc tại đây, giảm tải cho phiên bản DB chính của bạn.

• Điểm cuối phiên bản - Một Điểm cuối phiên bản kết nối với một phiên bản cụ thể trong cụm. Khách hàng có thể có quyền kiểm soát chi tiết đối với việc phân bổ truy vấn, thay vì để Amazon Aurora xử lý việc phân phối kết nối.

Tôi biết bạn đang nghĩ gì… Tôi sẽ chỉ kết nối với Điểm cuối của cụm forwrites, Điểm cuối của trình đọc cho tất cả các lần đọc, và tại sao tôi lại kết nối với phiên bản cụ thể - nó bỏ qua khả năng chịu lỗi tích hợp và đang yêu cầu khắc phục sự cố, phải không? Như đã đề cập trước đó, ứng dụng của bạn và sự tương tác của nó vớiAurora tạo ra một hệ thống phức tạp (hoặc ít nhất là một hệ thống không tầm thường). Với các hệ thống phức tạp, một kích thước phù hợp với tất cả không phải là quy tắc để dựa vào… trừ khi bạn thưởng thức các cuộc gọi vào lúc nửa đêm.

Hãy xem qua một số tình huống và xem xét thời điểm và vị trí sử dụng các điểm khác biệt.

Nhất quán tức thì

Một số ứng dụng mong muốn dữ liệu phải nhất quán ngay lập tức. Khi ứng dụng ghi dữ liệu, chúng ngay lập tức đọc dữ liệu tuân thủ nghiêm ngặt bất kỳ mẫu thiết kế nào có nội dung “dựa vào mô hình, không phải dữ liệu cục bộ của bạn”. Amazon Aurora tuân thủ ACID; một bài đọc từ Điểm cuối của cụm ngay sau khi ghi thành công cam kết sẽ truy xuất dữ liệu mong đợi (giả sử một giao dịch khác không sửa đổi dữ liệu trước lần đọc tiếp theo).

Trường hợp rắc rối xảy ra là khi các bài viết được gửi đến Điểm cuối của cụm andreads được thực hiện cho Điểm cuối của trình đọc . Điều này là do độ trễ giữa việc ghi dữ liệu và khi nó hiển thị cho người đọc. Mặc dù tần suất sao chép dưới 100 mili giây, nhưng nó không phải là tức thời, dẫn đến tình trạng chạy đua. Nếu bạn gặp trường hợp cần đọc ngay dữ liệu sau khi ghi, hãy sử dụng Điểm cuối cụm cho cả đọc và ghi. Cần lưu ý rằng, nếu cần có hiệu suất bổ sung, bạn phải tăng kích thước của phiên bản gốc của mình.

Tuy nhiên, nếu tính nhất quán cuối cùng có thể chấp nhận được và ứng dụng của bạn hỗ trợ nó, hãy sử dụng Reader Endpoint là một cách tuyệt vời để giảm tải cho công việc chính của bạn.

Đang giảm tải số lần đọc

Nếu tính năng đọc ngay lập tức sau khi ghi không ổn, thì có ích gì khi có một Điểm cuối của trình đọc phân tách ? Có nhiều trường hợp sử dụng mà dữ liệu hơi không nhất quán không phải là một vấn đề. Ví dụ:báo cáo hàng ngày. Khi chạy các công việc hàng loạt để tạo báo cáo từ dữ liệu của ngày hôm qua, độ trễ sao chép 100 mili giây là điều cần thiết. Có thể dễ dàng hình dung ra các tình huống khác, chẳng hạn như mô tả sản phẩm trên một trang web thương mại điện tử… bạn có nhiều khả năng có dữ liệu cũ trong trình duyệt của người dùng hơn là bị ảnh hưởng bởi độ trễ sao chép.

Nói chung, khối lượng công việc đọc nhiều không dựa trên tính nhất quán tức thì nên cân nhắc bằng cách sử dụng Reader Endpoint .

Khối lượng công việc không đồng nhất

Có những tình huống hợp lý khi sử dụng Điểm cuối phiên bản . Giả sử bạn có một ứng dụng có một số dịch vụ nhỏ không trạng thái phía sau Bộ cân bằng tải đàn hồi. Trong tình huống này, sẽ hợp lý khi giả định rằng các truy vấn được phân phối đồng đều trên các máy khách và do đó, trên các Bản sao Đọc - khi sử dụng Điểm cuối của Trình đọc .

Nhưng còn tình huống khối lượng công việc của từng khách hàng không được phân bổ đồng nhất thì sao? Nếu một dịch vụ báo cáo được thêm vào hỗn hợp, một Bản sao Đọc có tải cao không tương xứng so với các dịch vụ khác. Nếu các dịch vụ được đề cập trước đó cũng sử dụng Bản sao Đọc này, thì có khả năng cao là hiệu suất truy vấn kém khi truy vấn bản sao được dịch vụ báo cáo sử dụng. Oneapproach để tránh điều này là quản lý việc phân phối các kết nối ở phía phòng khám, thay vì để Amazon Aurora làm việc này cho bạn. May mắn thay, điều này có thể dễ dàng thực hiện bằng cách sử dụng Điểm cuối phiên bản thay vì Điểm cuối của trình đọc .Với MariaDB Connector / J cho Aurora cho MySQL hoặc Fast Failover với AmazonAurora PostgreSQL, trình điều khiển có thể được biết về các trường hợp riêng lẻ mà bạn muốn sử dụng làm Bản sao Đọc, cho phép trình điều khiển trực tiếp quản lý cách các truy vấn được phân phối đến các phiên bản riêng lẻ.

Quản lý bộ nhớ đệm DNS

Ngoài việc hiểu bản chất khối lượng công việc của bạn, điều quan trọng là phải hiểu cách các kết nối được phân bổ để cung cấp Tính khả dụng cao của Aurora và Điểm cuối người đọc cân bằng tải.

Quản lý Điểm cuối cụm tự động chuyển đổi dự phòng và Điểm cuối của trình đọc cân bằng tải được xử lý thông qua DNS (Amazon Route 53), không phải ở các lớp giao thức khách IP, TCP, ordatabase. Xử lý phân phối kết nối thông quaDNS có nghĩa là ứng dụng đó của bạn phải thực hiện truy vấn DNS cho mỗi yêu cầu kết nối mới. Các ứng dụng sử dụng bộ nhớ đệm DNS nên điều chỉnh thời gian chờ của bộ nhớ cache để phù hợp với bản ghi DNS TTL cho Amazon Aurora. Các phản hồi DNS lưu vào bộ đệm lâu hơn vì bản ghi Aurora DNS TTL sẽ dẫn đến một số điều kiện lỗi. Nếu có sự kiện chuyển đổi dự phòng Mức độ sẵn sàng cao (HA), tức là Bản sao đã đọc được thăng cấp thành Chính, phản hồi DNS được lưu trong bộ nhớ cache có nghĩa là ứng dụng của bạn sẽ cố gắng ngắt kết nối với phiên bản cũ, không thành công. Trong trường hợp của Điểm cuối của trình đọc , phản hồi DNS vào bộ nhớ đệm dẫn đến nhiều kết nối đi đến một Bản sao đọc cụ thể thay vì được phân phối trên các Bản sao đã đọc có sẵn.

Kết thúc

Như chúng ta có thể thấy, không có giải pháp duy nhất phù hợp với tất cả khi nói đến khối lượng công việc sản xuất không tầm thường. Nếu ứng dụng của bạn cần tính nhất quán ngay lập tức, thì hãy đảm bảo rằng cả đọc và ghi đều được gửi đến Điểm cuối cụm . Khi truy vấn đọc có thể xử lý một chút độ trễ sao chép, hãy giảm tải các truy vấn đọc đến Điểm cuối của trình đọc . Nếu bạn có thể sử dụng Bản sao đọc nhưng các truy vấn của bạn không được phân phối đồng nhất trên tất cả các máy khách, thì hãy sử dụng Điểm cuối phiên bản và quản lý các kết nối phân phối ở phía máy khách. Đừng quên, nếu ứng dụng của bạn sử dụng bộ nhớ đệmDNS với thời gian chờ của bộ nhớ cache lâu hơn TTL của bản ghi DNS, appeart của điểm cuối sẽ không hoạt động như mong đợi trong Cluster Endpoint Chuyển đổi dự phòng HA hoặc khi sử dụng Điểm cuối đầu đọc .

Hiểu bản chất ứng dụng của bạn, cách các Điểm cuối Aurora hoạt động và áp dụng đúng kiến ​​thức đó sẽ dẫn đến một môi trường ứng dụng mạnh mẽ hơn, điều này rất quan trọng đối với bạn và khách hàng của bạn. Không ai muốn bị cúp điện thoại vào lúc nửa đêm.

Sử dụng tab Phản hồi để đưa ra bất kỳ nhận xét hoặc đặt câu hỏi nào.