Phần 3/6 · 7 phút

Aurora: replica, Global Database và Serverless

0/7

Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

Aurora là relational database engine tương thích MySQL và PostgreSQL với tầng storage do AWS thiết kế lại, giúp Aurora Replica có replica lag thấp hơn và cluster mở rộng sang nhiều Region dễ hơn.

Read Replica của RDS for MySQL bắt đầu có replica lag vài phút vào giờ cao điểm, do đó MFTECH chuyển sang Aurora MySQL. Khác biệt lớn nhất: mọi instance dùng chung một cluster volume, nên replica không phải sao chép lại dữ liệu. Thử lần lượt các thao tác:

Writer tại AZ a, hai reader tại AZ b và c, tất cả dùng chung một cluster volume. Thực hiện lần lượt từng thao tác phía trên.

Xem ngân hàng Aurora: một quầy ghi, nhiều quầy đọc trên một kho chung 6 bản; quầy ghi hỏng, rồi cả thành phố sập.

Một số quyết định khác của MFTECH liên quan tới Aurora:

Giải pháp đề xuấtRestore từ automated backup của Aurora (hoặc tạo clone)

Tạo cluster riêng từ backup, không ảnh hưởng tới cluster production. Aurora cloning nhanh hơn và tiết kiệm dung lượng hơn restore snapshot: clone dùng chung data page với cluster gốc theo cơ chế copy-on-write, chỉ cấp phát thêm storage khi một bên thay đổi dữ liệu. Cloning là tính năng của Aurora; với RDS DB instance, dùng restore snapshot hoặc point-in-time recovery.

Ghi nhớ:

Aurora không có standby instance riêng: khi writer gặp sự cố, Aurora promote một Aurora Replica (theo priority tier 0–15) thành writer mới; nếu cluster không có replica, Aurora tạo lại primary trong cùng AZ (thường dưới 10 phút, chậm hơn nhiều so với promote replica).
Vì vậy, để tăng tính sẵn sàng, tạo Aurora Replica ở AZ khác.
Aurora Replica + reader endpoint phục vụ tải đọc lớn, đồng thời là đích failover.
Tải đọc biến động: Aurora Auto Scaling.
Nhiều Region (tối đa 10 secondary Region), RPO thường tính bằng giây, RTO tính bằng phút: Global Database.
Tải không dự đoán được: Serverless v2.

Part 3/6 · 7 phút

Aurora: replicas, Global Database and Serverless

0/8

Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

Aurora is a MySQL- and PostgreSQL-compatible relational database engine with a storage layer AWS redesigned, so Aurora Replicas have lower replica lag and clusters extend across Regions more easily.

The RDS for MySQL Read Replica starts to show several minutes of replica lag at peak hours, so MFTECH moves to Aurora MySQL. The biggest difference: all instances share one cluster volume, so replicas do not have to copy the data again. Try each action in turn:

Writer tại AZ a, hai reader tại AZ b và c, tất cả dùng chung một cluster volume. Thực hiện lần lượt từng thao tác phía trên.

Xem ngân hàng Aurora: một quầy ghi, nhiều quầy đọc trên một kho chung 6 bản; quầy ghi hỏng, rồi cả thành phố sập.

Some other MFTECH decisions involving Aurora:

Giải pháp đề xuấtRestore from an Aurora automated backup (or create a clone)

Creates a separate cluster from the backup, with no impact on the production cluster. Aurora cloning is faster and more space-efficient than restoring a snapshot: the clone shares data pages with the source cluster through copy-on-write and allocates new storage only when either side changes data. Cloning is an Aurora feature; for an RDS DB instance, restore a snapshot or use point-in-time recovery.

Ghi nhớ:

Aurora has no separate standby instance: when the writer fails, Aurora promotes an Aurora Replica (by priority tier 0–15) to be the new writer; if the cluster has no replica, Aurora recreates the primary in the same AZ (typically under 10 minutes, much slower than promoting a replica).
So, to improve availability, create an Aurora Replica in another AZ.
Aurora Replicas + the reader endpoint serve heavy read traffic and are also failover targets.
Fluctuating read traffic: Aurora Auto Scaling.
Multiple Regions (up to 10 secondary Regions), RPO typically measured in seconds, RTO in minutes: Global Database.
Unpredictable load: Serverless v2.