Amazon Aurora là một dịch vụ cơ sở dữ liệu quan hệ hiện đại mang lại hiệu năng và tính sẵn sàng cao trên quy mô lớn, cung cấp các phiên bản tương thích với MySQL và PostgreSQL nguồn mở hoàn toàn cũng như một loạt công cụ dành cho nhà phát triển để xây dựng các ứng dụng phi máy chủ và theo định hướng máy học (ML).

Aurora bao gồm một hệ thống lưu trữ phân phối chịu lỗi tốt và có khả năng tự động sửa lỗi, tách biệt với các tài nguyên điện toán và có thể tự động tăng quy mô lên tới 128 TiB với mỗi phiên bản cơ sở dữ liệu. Aurora mang lại hiệu năng cùng độ sẵn sàng cao với 15 bản sao chỉ có quyền đọc có độ trễ thấp, tính năng khôi phục theo thời điểm, khả năng sao lưu liên tục vào Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) và tính năng sao chép qua ba Vùng sẵn sàng (AZ).

Aurora cũng là dịch vụ được quản lý toàn phần, giúp tự động hóa các tác vụ quản trị tốn nhiều thời gian như cung cấp phần cứng, thiết lập cơ sở dữ liệu, vá lỗi và sao lưu, đồng thời mang lại khả năng bảo mật, tính sẵn sàng và độ tin cậy của cơ sở dữ liệu thương mại với chi phí bằng một phần mười.

Amazon Aurora tương thích linh hoạt với các cơ sở dữ liệu nguồn mở MySQL hiện có, đồng thời đều đặn bổ sung khả năng hỗ trợ cho các phiên bản mới ra mắt. Điều này có nghĩa là bạn có thể dễ dàng di chuyển cơ sở dữ liệu MySQL đến và đi từ Aurora thông qua các công cụ xuất/nhập tiêu chuẩn hoặc các ảnh chụp nhanh. Đồng thời, điều này có nghĩa là phần lớn mã, ứng dụng, trình điều khiển và công cụ mà bạn đang dùng với các cơ sở dữ liệu MySQL đều có thể sử dụng với Aurora mà gần như không cần thay đổi gì. Điều này cho phép dễ dàng di chuyển các ứng dụng giữa hai công cụ.

Bạn có thể xem thông tin hiện tại về khả năng tương thích của Amazon Aurora với phiên bản MySQL mới ra mắt trong tài liệu này.

Amazon Aurora tương thích linh hoạt với các cơ sở dữ liệu nguồn mở PostgreSQL hiện có, đồng thời bổ sung khả năng hỗ trợ cho các phiên bản mới ra mắt một cách đều đặn. Điều này có nghĩa là bạn có thể dễ dàng di chuyển cơ sở dữ liệu PostgreSQL sang và từ Aurora thông qua các công cụ xuất/nhập tiêu chuẩn hoặc các bản kết xuất nhanh. “Tương thích với PostgreSQL” cũng có nghĩa là hầu hết các đoạn mã, ứng dụng, trình điều khiển và công cụ mà bạn đang dùng với các cơ sở dữ liệu PostgreSQL đều có thể sử dụng với Aurora mà gần như không cần thay đổi gì.

Bạn có thể xem thông tin hiện tại về khả năng tương thích của Amazon Aurora với phiên bản PostgreSQL mới ra mắt trong tài liệu này.

Amazon hỗ trợ đầy đủ Aurora PostgreSQL và tất cả các phần mở rộng có sẵn với Aurora. Nếu bạn cần hỗ trợ về Aurora PostgreSQL, hãy liên hệ với bộ phận Hỗ trợ AWS. Nếu bạn có tài khoản Hỗ trợ AWS cao cấp đang hoạt động, bạn có thể liên hệ với bộ phận Hỗ trợ AWS cao cấp để được hỗ trợ về các vấn đề cụ thể liên quan đến Aurora.

Để dùng thử Aurora, hãy đăng nhập vào Bảng điều khiển quản lý AWS, chọn RDS trong danh mục Cơ sở dữ liệu rồi chọn Amazon Aurora làm công cụ cơ sở dữ liệu của bạn. Để tìm tài nguyên và hướng dẫn chi tiết, hãy xem trang Bắt đầu sử dụng Aurora của chúng tôi.

Bạn có thể xem Khu vực có khả năng sử dụng Aurora tại đây.

Nếu bạn muốn di chuyển từ MySQL sang Aurora và ngược lại, bạn có một số lựa chọn sau:

• Bạn có thể sử dụng tiện ích mysqldump tiêu chuẩn để xuất dữ liệu từ MySQL rồi dùng tiện ích mysqlimport để nhập dữ liệu vào Aurora và ngược lại.
• Bạn cũng có thể sử dụng tính năng di chuyển Ảnh chụp nhanh CSDL của Amazon RDS để di chuyển Ảnh chụp nhanh CSDL Amazon RDS dành cho MySQL sang Aurora bằng Bảng điều khiển quản lý AWS.

Với hầu hết khách hàng, quá trình di chuyển sang Aurora sẽ mất chưa đến một giờ, tuy nhiên, thời lượng thực tế phụ thuộc vào định dạng và kích thước tập dữ liệu. Để biết thêm thông tin, hãy tham khảo Những phương pháp tốt nhất để di chuyển cơ sở dữ liệu MySQL sang Amazon Aurora.

Nếu bạn muốn di chuyển từ PostgreSQL sang Aurora và ngược lại, bạn có một số lựa chọn sau:

• Bạn có thể sử dụng tiện ích pg_dump tiêu chuẩn để xuất dữ liệu từ PostgreSQL rồi dùng tiện ích pg_restore để nhập dữ liệu vào Aurora và ngược lại.
• Bạn cũng có thể sử dụng tính năng di chuyển Ảnh chụp nhanh CSDL của RDS để di chuyển Ảnh chụp nhanh CSDL Amazon RDS dành cho PostgreSQL sang Aurora bằng Bảng điều khiển quản lý AWS.

Với hầu hết khách hàng, quá trình di chuyển sang Aurora sẽ mất chưa đến một giờ, tuy nhiên, thời lượng thực tế phụ thuộc vào định dạng và kích thước tập dữ liệu.

Để di chuyển các cơ sở dữ liệu SQL Server sang Phiên bản Amazon Aurora tương thích với PostgreSQL, bạn có thể sử dụng Babelfish dành cho Aurora PostgreSQL. Các ứng dụng của bạn sẽ hoạt động mà không có bất kỳ thay đổi nào. Hãy xem tài liệu Babelfish để biết thêm thông tin.

Không, Aurora hoạt động với các trình điều khiển cơ sở dữ liệu PostgreSQL tiêu chuẩn.

Amazon Aurora giúp tăng hiệu năng MySQL đáng kể bằng cách tích hợp chặt chẽ công cụ cơ sở dữ liệu với lớp lưu trữ ảo hóa dựa trên SSD chuyên dụng cho khối lượng công việc liên quan đến cơ sở dữ liệu, từ đó giảm lượng ghi vào hệ thống lưu trữ, giảm thiểu tranh chấp khóa và loại bỏ sự chậm trễ do các luồng quy trình cơ sở dữ liệu gây ra.

Những thử nghiệm của chúng tôi với SysBench trên các phiên bản r3.8xlarge cho thấy Amazon Aurora đạt tốc độ trên 500.000 SELECT/giây và 100.000 UPDATE/giây, cao hơn năm lần so với MySQL chạy cùng chương trình quy chuẩn trên cùng phần cứng. Hướng dẫn chi tiết về chương trình quy chuẩn này cũng như cách tự thực hiện lại có trong Hướng dẫn quy chuẩn hiệu năng Phiên bản Amazon Aurora tương thích với MySQL.

Amazon Aurora giúp tăng hiệu năng PostgreSQL đáng kể bằng cách tích hợp chặt chẽ công cụ cơ sở dữ liệu với khối lượng công việc cơ sở dữ liệu chuyên dụng có lớp lưu trữ ảo hóa sử dụng ổ đĩa SSD, giảm lượt ghi vào hệ thống lưu trữ, giảm thiểu xung đột khóa và hạn chế sự chậm trễ do các luồng tiến trình cơ sở dữ liệu gây ra.

Các thử nghiệm của chúng tôi với SysBench trên các phiên bản r4.16xlarge cho thấy Amazon Aurora đạt tốc độ SELECT/giây và UPDATE/giây cao gấp hơn ba lần so với PostgreSQL chạy cùng chương trình quy chuẩn trên cùng phần cứng. Hướng dẫn chi tiết về chương trình quy chuẩn này cũng như cách tự thực hiện lại có trong Hướng dẫn quy chuẩn hiệu năng Phiên bản Amazon Aurora tương thích với PostgreSQL.

Amazon Aurora được thiết kế tương thích với MySQL, nên các ứng dụng và công cụ MySQL hiện tại đều có thể chạy mà không cần sửa đổi gì. Tuy nhiên, có một lĩnh vực mà Amazon Aurora sẽ giúp cải thiện hiệu năng của MySQL, chính là khi xử lý nhiều khối lượng công việc đồng thời. Để tăng tối đa thông lượng của khối lượng công việc trên Amazon Aurora, bạn nên dựng các ứng dụng sao cho có thể xử lý số lượng lớn truy vấn và giao dịch đồng thời.

Amazon Aurora được thiết kế tương thích với PostgreSQL, nên các ứng dụng và công cụ PostgreSQL hiện tại đều có thể chạy mà không cần sửa đổi gì. Tuy nhiên, có một lĩnh vực mà Amazon Aurora sẽ giúp cải thiện hiệu năng của PostgreSQL, chính là khi xử lý nhiều khối lượng công việc đồng thời. Để tăng tối đa thông lượng của khối lượng công việc trên Amazon Aurora, bạn nên dựng các ứng dụng sao cho có thể xử lý số lượng lớn truy vấn và giao dịch đồng thời.

Hãy tham khảo trang định giá Aurora để biết thông tin mức giá hiện tại.

Không có dịch vụ Bậc miễn phí của AWS cho Aurora tại thời điểm này. Tuy nhiên, Aurora lưu trữ lâu dài dữ liệu của bạn trên ba Vùng sẵn sàng trong một Khu vực và chỉ tính phí cho một bản sao dữ liệu. Bạn không phải trả phí cho các bản sao lưu lên tới 100% kích cỡ của cụm cơ sở dữ liệu của bạn. Bạn cũng không bị tính phí cho ảnh chụp nhanh trong thời gian lưu giữ bản sao lưu mà bạn đã cấu hình cho cụm cơ sở dữ liệu của mình.

Không, việc sao chép của Aurora đã được gộp vào trong giá. Bạn phải trả phí theo dung lượng lưu trữ mà cơ sở dữ liệu của bạn sử dụng trên lớp cơ sở dữ liệu, chứ không phải dung lượng lưu trữ được sử dụng trong lớp lưu trữ ảo hóa của Aurora.

Các hoạt động I/O được công cụ cơ sở dữ liệu Aurora thực hiện trên lớp lưu trữ ảo hóa sử dụng SSD. Mỗi hoạt động đọc trang cơ sở dữ liệu được tính là một lượt I/O.
Công cụ cơ sở dữ liệu Aurora xuất lệnh đọc lớp lưu trữ để tìm nạp các trang cơ sở dữ liệu không có trong bộ nhớ nằm bên trong bộ nhớ đệm:

• Nếu lưu lượng truy vấn của bạn có thể được phân phối hoàn toàn từ bộ nhớ hoặc bộ nhớ đệm, bạn sẽ không bị tính phí truy xuất cho bất kỳ trang dữ liệu nào từ bộ nhớ.
• Nếu lưu lượng truy vấn của bạn không thể được phân phối hoàn toàn từ bộ nhớ, bạn sẽ bị tính phí cho bất kỳ trang dữ liệu nào cần truy xuất từ kho lưu trữ.
  Mỗi trang cơ sở dữ liệu có dung lượng 16 KB trong Phiên bản Amazon Aurora tương thích với MySQL và 8 KB trong Phiên bản Aurora tương thích với PostgreSQL.

Aurora được thiết kế để loại bỏ các hoạt động I/O không cần thiết nhằm giảm chi phí mà vẫn bảo đảm tài nguyên sẵn sàng sử dụng để phục vụ lưu lượng đọc/ghi. Các hoạt động I/O ghi chỉ được sử dụng khi duy trì bản ghi làm lại trong Phiên bản Aurora tương thích với MySQL hoặc ghi bản ghi trước trong Phiên bản Aurora tương thích với PostgreSQL vào lớp lưu trữ nhằm giúp hoạt động ghi bền bỉ hơn.

Các hoạt động I/O ghi được tính theo đơn vị 4 KB. Ví dụ: bản ghi có dung lượng 1.024 byte sẽ được tính là một hoạt động I/O ghi. Tuy nhiên, nếu bản ghi lớn hơn 4 KB, cần nhiều hơn một hoạt động I/O ghi để tiến hành việc ghi.

Các thao tác ghi đồng thời đối với các bản ghi nhỏ hơn 4 KB có thể được công cụ cơ sở dữ liệu Aurora gom lại với nhau theo lô để tối ưu hóa mức tiêu thụ I/O. Không giống như các công cụ cơ sở dữ liệu truyền thống, Aurora không bao giờ đẩy trang dữ liệu vô dụng vào kho lưu trữ.

Bạn có thể xem phiên bản Aurora của mình đang tiêu thụ bao nhiêu yêu cầu I/O bằng cách kiểm tra Bảng điều khiển quản lý AWS. Để xem mức tiêu thụ I/O, hãy vào mục Amazon RDS của bảng điều khiển, tìm trong danh sách phiên bản, chọn phiên bản Aurora rồi tìm các chỉ số “VolumeReadIOPs” và “VolumeWriteIOPs” trong mục theo dõi.

Để biết thêm thông tin về giá của hoạt động I/O, hãy truy cập trang định giá Aurora. Bạn phải trả phí cho các hoạt động I/O đọc và ghi khi bạn cấu hình cụm cơ sở dữ liệu của mình theo cấu hình Aurora tiêu chuẩn. Bạn không phải trả phí cho các hoạt động I/O đọc và ghi khi bạn cấu hình cụm cơ sở dữ liệu của mình thành Amazon Aurora tối ưu hóa I/O.

Aurora mang đến sự linh hoạt để giúp bạn tối ưu hóa mức chi tiêu cơ sở dữ liệu của mình bằng cách chọn giữa hai tùy chọn cấu hình dựa trên nhu cầu của bạn về tỷ lệ giá-hiệu năng và khả năng dự đoán giá. Hai tùy chọn cấu hình là Aurora tiêu chuẩn và Aurora tối ưu hóa I/O. Không có tùy chọn nào yêu cầu trả trước cho I/O hoặc việc cung cấp dung lượng lưu trữ và cả hai tùy chọn đều có thể điều chỉnh quy mô hoạt động I/O để hỗ trợ các ứng dụng đòi hỏi khắt khe nhất.

Aurora tiêu chuẩn là cấu hình cụm cơ sở dữ liệu cung cấp mức giá tiết kiệm chi phí cho phần lớn các ứng dụng có mức sử dụng I/O từ thấp đến trung bình. Với Aurora tiêu chuẩn, bạn phải trả tiền cho các phiên bản cơ sở dữ liệu, dung lượng lưu trữ và I/O thanh toán trên mỗi yêu cầu.

Aurora tối ưu hóa I/O là cấu hình cụm cơ sở dữ liệu mang lại tỷ lệ giá-hiệu năng cao hơn cho các ứng dụng sử dụng nhiều hoạt động I/O như hệ thống xử lý thanh toán, hệ thống thương mại điện tử và các ứng dụng tài chính. Ngoài ra, nếu chi tiêu I/O của bạn vượt quá 25% tổng chi tiêu cơ sở dữ liệu Aurora, bạn có thể tiết kiệm tới 40% chi phí cho các khối lượng công việc sử dụng nhiều thao tác I/O với Aurora tối ưu hóa I/O. Aurora tối ưu hóa I/O cung cấp mức giá có thể dự đoán cho tất cả các ứng dụng vì không phải trả phí cho các hoạt động I/O đọc và ghi, nhờ vậy mà cấu hình này lý tưởng cho khối lượng công việc có độ biến thiên I/O cao.

Aurora tối ưu hóa I/O là lựa chọn lý tưởng khi bạn cần biết chi phí có thể dự đoán cho bất kỳ ứng dụng nào. Cấu hình này mang lại tỷ lệ giá-hiệu năng cao hơn cho các ứng dụng sử dụng nhiều hoạt động I/O, đòi hỏi thông lượng ghi cao hoặc chạy các truy vấn phân tích để xử lý lượng dữ liệu lớn. Những khách hàng có chi tiêu I/O vượt quá 25% hóa đơn Aurora của họ có thể tiết kiệm tới 40% chi phí cho khối lượng công việc sử dụng nhiều hoạt động I/O thông qua Aurora tối ưu hóa I/O.

Bạn có thể sử dụng trải nghiệm một cú nhấp chuột có sẵn trong Bảng điều khiển quản lý AWS để thay đổi kiểu lưu trữ của cụm cơ sở dữ liệu hiện có thành Aurora tối ưu hóa I/O. Bạn cũng có thể gọi Giao diện dòng lệnh AWS (AWS CLI) hoặc SDK AWS để thực hiện thay đổi này.

Bạn có thể chuyển cụm cơ sở dữ liệu hiện có của mình sang Aurora tối ưu hóa I/O sau mỗi 30 ngày. Bạn có thể chuyển trở lại Aurora tiêu chuẩn bất cứ lúc nào.

Có, Aurora tối ưu hóa I/O hoạt động với Phiên bản đặt trước Aurora hiện có. Aurora tự động tính đến chênh lệch giá giữa Aurora tiêu chuẩn và Aurora tối ưu hóa I/O với Phiên bản đặt trước. Với chiết khấu của Phiên bản đặt trước áp dụng cho Aurora tối ưu hóa I/O, bạn có thể tiết kiệm hơn nữa cho chi tiêu I/O của mình.

Giá của tính năng dò ngược, ảnh chụp nhanh, xuất hoặc sao lưu liên tục không thay đổi với Aurora tối ưu hóa I/O.

Có, bạn vẫn phải trả phí cho các hoạt động I/O cần thiết để sao chép dữ liệu trên các Khu vực. Aurora tối ưu hóa I/O chỉ không tính phí cho các hoạt động I/O đọc và ghi, vốn không phải là hoạt động sao chép dữ liệu.

Đọc tối ưu hóa của Amazon Aurora cho Aurora PostgreSQL không tính thêm phí ngoài giá của các phiên bản R6id dựa trên Intel và R6gd dựa trên Graviton. Để biết thêm thông tin, hãy truy cập trang định giá của Aurora.

Dung lượng lưu trữ nhỏ nhất là 10 GB. Tùy theo mức sử dụng cơ sở dữ liệu, dung lượng lưu trữ Amazon Aurora của bạn sẽ tự động tăng đến tối đa 128 TiB với gia số 10 GB, mà không ảnh hưởng gì đến hiệu năng của cơ sở dữ liệu. Bạn sẽ không cần phải dự phòng trước dung lượng lưu trữ.

Có hai cách để thay đổi quy mô tài nguyên điện toán gắn liền với Phiên bản CSDL Amazon Aurora của tôi – thông qua Aurora Serverless và thông qua điều chỉnh thủ công.

Bạn có thể sử dụng Aurora Serverless, một cấu hình theo nhu cầu, tự động thay đổi quy mô dành cho Amazon Aurora để thay đổi quy mô tài nguyên điện toán cơ sở dữ liệu dựa trên nhu cầu ứng dụng. Nhờ có Amazon Aurora Serverless, bạn có thể chạy cơ sở dữ liệu của mình trên nền tảng đám mây mà không phải lo nghĩ về việc quản lý dung lượng cơ sở dữ liệu. Bạn có thể chỉ định phạm vi dung lượng cơ sở dữ liệu mong muốn và cơ sở dữ liệu của bạn sẽ thay đổi quy mô dựa trên nhu cầu ứng dụng của bạn. Đọc thêm trong Hướng dẫn sử dụng Aurora Serverless.

Bạn cũng có thể tự thay đổi quy mô tài nguyên điện toán gắn liền với cơ sở dữ liệu của mình bằng cách chọn loại phiên bản CSDL mong muốn trong Bảng điều khiển quản lý AWS. Thay đổi bạn yêu cầu sẽ được áp dụng trong khung thời gian bảo trì bạn đã chỉ định hoặc bạn có thể sử dụng cờ “Áp dụng ngay” để lập tức thay đổi loại phiên bản cơ sở dữ liệu.

Cả hai lựa chọn đều ảnh hưởng đến khả năng sử dụng trong vài phút do hoạt động thay đổi quy mô diễn ra. Hãy lưu ý rằng bất kỳ thay đổi đang chờ xử lý nào của hệ thống cũng sẽ được áp dụng theo.

Tính năng sao lưu liên tục tự động luôn được bật trên các Phiên bản CSDL của Amazon Aurora. Bản sao lưu không ảnh hưởng đến hiệu năng của cơ sở dữ liệu.

Có và hiệu năng sẽ không bị ảnh hưởng khi tạo bản kết xuất nhanh. Hãy lưu ý rằng việc phục hồi dữ liệu từ bản Kết xuất nhanh CSDL bắt buộc phải tạo Phiên bản CSDL mới.

Amazon Aurora tự động giúp dữ liệu của bạn trở nên bền vững hơn trên ba Vùng sẵn sàng (AZ) trong một Khu vực. Dịch vụ này cũng sẽ tự động khôi phục cơ sở dữ liệu của bạn trong một AZ đang ở tình trạng tốt mà không làm mất dữ liệu. Trong trường hợp không may là dữ liệu của bạn không có trong bộ lưu trữ của Amazon Aurora, bạn có thể khôi phục từ Ảnh chụp nhanh CSDL hoặc khôi phục theo thời điểm sang phiên bản mới. Hãy lưu ý rằng thời điểm gần nhất có thể khôi phục là tối đa năm phút trước đó.

Bạn có thể chọn tạo bản Kết xuất nhanh CSDL cuối cùng khi xóa phiên bản CSDL. Nếu chọn lựa chọn này, bạn có thể sử dụng bản Kết xuất nhanh cơ sở dữ liệu để khôi phục phiên bản CSDL đã bị xóa về sau. Amazon Aurora giữ lại bản kết xuất nhanh CSDL cuối cùng do người dùng tạo ra này cùng với toàn bộ các bản kết xuất nhanh CSDL được tạo thủ công khác sau khi phiên bản CSDL được xóa đi. Chỉ các bản Kết xuất nhanh CSDL được giữ lại sau khi phiên bản CSDL bị xóa (tức là, các bản sao lưu tự động được tạo cho hoạt động khôi phục theo thời điểm cũng không được giữ lại).

Có. Aurora cho bạn khả năng tạo bản kết xuất nhanh cơ sở dữ liệu để bạn có thể sử dụng để phục hồi cơ sở dữ liệu về sau. Bạn có thể chia sẻ bản kết xuất nhanh với tài khoản AWS khác và chủ sở hữu của tài khoản nhận được có quyền sử dụng bản kết xuất nhanh của bạn để khôi phục CSDL có chứa dữ liệu của bạn. Thậm chí, bạn còn có quyền cung cấp công khai bản kết xuất nhanh của mình – tức là, bất kỳ ai cũng có thể khôi phục CSDL có chứa dữ liệu (công khai) của bạn.

Bạn có thể sử dụng tính năng này để chia sẻ dữ liệu giữa nhiều môi trường khác nhau của bạn (sản xuất, phát triển/kiểm thử, dàn dựng...) có nhiều tài khoản AWS khác nhau cũng như giữ bản sao lưu của toàn bộ dữ liệu của bạn an toàn trong tài khoản riêng trong trường hợp tài khoản AWS chính của bạn gặp vấn đề.

Việc chia sẻ ảnh chụp nhanh giữa các tài khoản không bị tính phí. Tuy nhiên, bạn có thể sẽ bị tính phí cho chính các bản kết xuất nhanh cũng như mọi cơ sở dữ liệu bạn phục hồi từ bản kết xuất nhanh được chia sẻ hoặc dùng chung. Tìm hiểu thêm về giá Aurora.

Chúng tôi không hỗ trợ chia sẻ bản kết xuất nhanh CSDL tự động. Để chia sẻ bản kết xuất nhanh, bạn phải tạo thủ công bản sao của bản kết xuất nhanh rồi chia sẻ bản sao đó.

Bạn được quyền chia sẻ bản kết xuất nhanh thủ công của mình với tối đa 20 ID tài khoản AWS. Nếu muốn chia sẻ bản kết xuất nhanh với trên 20 tài khoản, bạn có thể chia sẻ dưới dạng công khai hoặc liên hệ bộ phận hỗ trợ để tăng định mức của mình.

Bạn có thể chia sẻ bản kết xuất nhanh Aurora trong mỗi khu vực AWS cung cấp Aurora.

Không. Chỉ có các tài khoản trong cùng khu vực với tài khoản chia sẻ mới truy cập được bản kết xuất nhanh Aurora được chia sẻ của bạn.

Có. Bạn được quyền chia sẻ ảnh chụp nhanh Aurora đã mã hóa.

Amazon Aurora sẽ tự động chia dung lượng cơ sở dữ liệu thành từng khúc gồm 10 GB đặt trên nhiều ổ đĩa. Từng khúc 10 GB trong dung lượng cơ sở dữ liệu của bạn được sao chép thành sáu phần trên ba vùng sẵn sàng. Amazon Aurora được thiết kế để xử lý sự cố mất đến hai bản sao dữ liệu một cách minh bạch mà không ảnh hưởng đến khả năng ghi của cơ sở dữ liệu và đến ba bản không ảnh hưởng đến khả năng đọc.

Bộ lưu trữ của Amazon Aurora cũng có khả năng tự động sửa chữa. Khối dữ liệu và ổ đĩa được quét liên tục để tìm lỗi và sửa chữa ngay lập tức.

Không giống như các cơ sở dữ liệu khác, sau khi cơ sở dữ liệu hư hỏng, Amazon Aurora không cần chạy lại nhật ký tiến hành lại từ điểm kiểm tra cơ sở dữ liệu gần nhất (thường là năm phút) và xác nhận rằng mọi thay đổi đã được áp dụng rồi mới cho cơ sở dữ liệu đi vào hoạt động. Việc này giúp giảm thời gian khởi động lại cơ sở dữ liệu xuống dưới 60 giây trong hầu hết trường hợp.

Amazon Aurora di chuyển bộ nhớ đệm ra khỏi tiến trình của cơ sở dữ liệu và cung cấp để sử dụng ngay vào thời điểm khởi động lại. Việc này giúp bạn không phải điều tiết lượng truy cập cho đến khi bộ nhớ đệm cache được tạo lại để tránh hao mòn.

Phiên bản Amazon Aurora tương thích với MySQL và Phiên bản Amazon Aurora tương thích với PostgreSQL hỗ trợ bản sao Amazon Aurora, dùng chung dung lượng ngầm với phiên bản chính trong cùng khu vực AWS. Các cập nhật trên phiên bản chính cũng hiển thị cho toàn bộ Bản sao Amazon Aurora.

Với Phiên bản Amazon Aurora tương thích với MySQL, bạn cũng có thể tạo ra Bản sao đọc MySQL liên vùng trên nền tảng công cụ sao chép bằng binlog của MySQL. Trong Bản sao chỉ có quyền đọc MySQL, dữ liệu từ phiên bản chính của bạn được phát lại thành các giao dịch. Trong hầu hết trường hợp sử dụng, kể cả thay đổi quy mô đọc và độ sẵn sàng cao, chúng tôi đều khuyến nghị sử dụng bản sao Amazon Aurora Replica.

Bạn sẽ có được sự linh hoạt để kết hợp và đối chiếu hai loại bản sao này theo nhu cầu ứng dụng của bạn:

Ngoài các tùy chọn được liệt kê ở trên, bạn còn có hai tùy chọn bản sao khác. Bạn có thể sử dụng Cơ sở dữ liệu toàn cầu của Amazon để sao chép vật lý nhanh hơn nhiều giữa các cụm Aurora trong các khu vực khác nhau. Ngoài ra, để sao chép giữa các cơ sở dữ liệu Aurora và không phải Phiên bản Aurora tương thích với MySQL (kể cả bên ngoài AWS), bạn có thể thiết lập quá trình sao chép binlog tự quản lý của riêng mình.

Có, bạn có thể thiết lập bản sao Aurora liên khu vực bằng tính năng sao chép logic hoặc sao chép vật lý. Tính năng sao chép vật lý, còn gọi là Amazon Aurora Global Database, sử dụng cơ sở hạ tầng chuyên dụng nhằm cung cấp toàn bộ cơ sở dữ liệu để phân phối ứng dụng. Tính năng này có thể sao chép vào tối đa năm khu vực phụ với độ trễ thường chỉ dưới 1 giây. Tính năng này có trên cả Phiên bản Aurora tương thích với MySQL và Phiên bản Aurora tương thích với PostgreSQL.

Để đọc trên toàn hệ thống với độ trễ thấp và phục hồi sau thảm họa, bạn nên sử dụng Amazon Aurora Global Database.
Aurora hỗ trợ sao chép logic tự nhiên trong từng công cụ cơ sở dữ liệu (binlog cho MySQL và các suất sao chép PostgreSQL cho PostgreSQL) nên bạn có thể sao chép vào các cơ sở dữ liệu Aurora và không phải Aurora, thậm chí trên nhiều Khu vực.

Phiên bản Aurora tương thích với MySQL còn cung cấp tính năng bản sao đọc logic liên khu vực dễ sử dụng, hỗ trợ tối đa năm khu vực AWS phụ. Tính năng này dựa trên hoạt động sao chép binlog MySQL đơn luồng nên độ trễ sao chép sẽ chịu ảnh hưởng của tốc độ thay đổi/áp dụng và độ trễ trong kết nối mạng giữa các khu vực cụ thể được chọn.

Có, bạn có thể thêm tối đa 15 Bản sao Aurora trên mỗi cụm liên khu vực. Các bản sao này sẽ dùng chung bộ lưu trữ cơ bản với bản sao liên khu vực. Bản sao liên khu vực đóng vai trò là bản chính trên cụm và Bản sao Aurora trên cụm thường sẽ bị trễ so với bản chính khoảng mấy mươi mili giây.

Có, bạn có thể tăng cấp bản sao liên khu vực lên thành bản chính mới từ bảng điều khiển Amazon RDS. Đối với tính năng sao chép logic (binlog), quá trình tăng cấp này thường mất vài phút tùy theo khối lượng công việc. Việc sao chép liên khu vực sẽ dừng lại khi bạn khởi chạy quá trình tăng cấp.

Với Cơ sở dữ liệu toàn cầu Amazon Aurora, bạn có thể tăng cấp khu vực phụ để đảm nhận toàn bộ khối lượng công việc đọc/ghi trong chưa đầy 1 phút.

Có. Bạn có thể chỉ định bậc ưu tiên chuyển đổi cho từng phiên bản trong cụm. Khi phiên bản chính hư hỏng, Amazon RDS sẽ đưa bản sao có độ ưu tiên cao nhất lên làm bản chính. Nếu hai hoặc nhiều Bản sao Aurora có cùng mức độ ưu tiên thì Amazon RDS sẽ lấy bản sao có kích thước lớn nhất. Nếu hai hoặc nhiều Bản sao Aurora có cùng mức độ ưu tiên và kích thước thì Amazon RDS sẽ lấy một bản sao tùy ý trong cùng một bậc khuyến mại.

Để biết thêm thông tin về logic chuyển đổi dự phòng, hãy đọc Hướng dẫn sử dụng Amazon Aurora.

Có, bạn có thể sửa đổi bậc ưu tiên của một phiên bản bất cứ lúc nào. Việc sửa đổi bậc ưu tiên đơn thuần sẽ không kích hoạt chuyển đổi dự phòng.

Bạn có thể chỉ định bậc ưu tiên thấp hơn cho các bản sao bạn không muốn đưa lên làm phiên bản chính. Tuy nhiên, nếu bản sao có độ ưu tiên cao hơn trên cụm không hoạt động bình thường hoặc không thể sử dụng vì lý do nào đó thì Amazon RDS sẽ đưa lên bản sao có độ ưu tiên thấp hơn.

Bạn có thể bổ sung bản sao Amazon Aurora. Bản sao Aurora trong cùng Khu vực AWS dùng chung bộ lưu trữ cơ bản với phiên bản chính. Mọi Bản sao Aurora đều có thể tăng cấp thành bản chính mà không bị mất dữ liệu, nên có thể dùng để cải thiện khả năng chịu lỗi trong trường hợp Phiên bản CSDL chính bị lỗi.

Để tăng tính sẵn sàng của cơ sở dữ liệu, bạn chỉ cần tạo 1 đến 15 bản sao ở bất kỳ vùng nào trong ba vùng sẵn sàng và Amazon RDS sẽ tự động đưa các bản sao đó vào phiên bản chính được lựa chọn chuyển đổi dự phòng trong trường hợp cơ sở dữ liệu ngừng hoạt động. Bạn có thể sử dụng Amazon Aurora Global Database nếu muốn cơ sở dữ liệu trải rộng ra nhiều Khu vực AWS. Tính năng này sẽ sao chép dữ liệu mà không ảnh hưởng đến hiệu năng của cơ sở dữ liệu, đồng thời mang lại khả năng phục hồi sau thảm họa do sự cố ngừng hoạt động trên toàn khu vực.

Quá trình chuyển đổi dự phòng được Amazon Aurora tự động xử lý để ứng dụng của bạn có thể tiếp tục các hoạt động cơ sở dữ liệu nhanh nhất có thể mà không cần phải can thiệp về mặt quản trị theo cách thủ công.

• Nếu bạn có Bản sao Aurora trong cùng một AZ hoặc ở AZ khác khi chuyển đổi dự phòng, Aurora sẽ lật bản ghi tên quy chuẩn (CNAME) cho Phiên bản CSDL để trỏ đến bản sao hoạt động tốt. Bản này sẽ được tăng cấp thành bản chính. Toàn bộ quá trình chuyển đổi dự phòng từ khi bắt đầu đến khi kết thúc thường diễn ra trong vòng 30 giây. Để cải thiện khả năng phục hồi và chuyển đổi dự phòng nhanh hơn, hãy cân nhắc sử dụng Proxy cho Amazon RDS có khả năng tự động kết nối với phiên bản CSDL chuyển đổi dự phòng trong khi vẫn duy trì các kết nối ứng dụng. Proxy giúp chuyển đổi dự phòng trở nên minh bạch cho các ứng dụng của bạn và giảm tới 66% thời gian chuyển đổi dự phòng.
• Nếu bạn đang chạy Aurora phi máy chủ phiên bản 1 và phiên bản CSDL hoặc AZ trở nên không khả dụng, Aurora sẽ tự động tạo lại phiên bản CSDL đó tại một AZ khác. Aurora phi máy chủ phiên bản 2 hoạt động giống như dịch vụ được cung cấp cho chuyển đổi dự phòng và các tính năng có độ sẵn sàng cao khác. Để biết thêm thông tin, hãy xem Aurora phi máy chủ phiên bản 2 và độ sẵn sàng cao. 
• Nếu bạn không có Bản sao Aurora (tức là sử dụng phiên bản đơn) và hiện không chạy Aurora phi máy chủ, Aurora sẽ cố gắng tạo Phiên bản CSDL mới trong cùng Vùng sẵn sàng với phiên bản gốc. Aurora sẽ cố gắng hết sức để thực hiện việc thay thế phiên bản gốc này nhưng có thể không thành công, ví dụ: nếu có sự cố ảnh hưởng rộng đến Vùng sẵn sàng.
  

Ứng dụng của bạn sẽ thử kết nối lại cơ sở dữ liệu trong trường hợp mất kết nối. Phục hồi sau thảm họa ở các khu vực là quá trình thủ công, trong đó bạn tăng cấp khu vực phụ để đảm nhận khối lượng công việc đọc/ghi.

Amazon Aurora sẽ tự động phát hiện vấn đề với phiên bản chính và kích hoạt quá trình chuyển đổi dự phòng. Nếu bạn đang dùng Điểm cuối cụm thì kết nối đọc/viết của bạn sẽ tự động được chuyển hướng lại sang một Bản sao Amazon Aurora. Bản sao này sẽ được tăng cấp thành bản chính.

Bên cạnh đó, lưu lượng đọc mà Bản sao Aurora phục vụ sẽ bị gián đoạn tạm thời. Nếu bạn đang dùng Điểm cuối trình đọc dữ liệu cụm để chuyển hướng lưu lượng đọc đến Bản sao Aurora, thì các kết nối chỉ đọc sẽ được chuyển hướng đến Bản sao Aurora mới được tăng cấp cho đến khi nút chính cũ được khôi phục ở dạng bản sao.

Do Bản sao Amazon Aurora dùng chung ổ đĩa dữ liệu với phiên bản chính trong cùng Khu vực AWS nên việc sao chép gần như không bị trễ. Thời gian trễ thường rơi vào khoảng mấy mươi mili giây.

Đối với giải pháp sao chép liên khu vực, độ trễ sao chép logic bằng binlog có thể tăng vô hạn theo tốc độ thay đổi/áp dụng cũng như độ trễ trong kết nối mạng. Tuy nhiên, trong điều kiện lý tưởng, độ trễ sao chép thường dưới 1 phút. Bản sao liên khu vực sử dụng tính năng sao chép vật lý của Cơ sở dữ liệu toàn cầu Amazon Aurora thường có độ trễ dưới 1 giây.

Có, bạn có thể thiết lập sao chép binlog giữa Phiên bản Aurora tương thích với MySQL và cơ sở dữ liệu MySQL bên ngoài. Cơ sở dữ liệu đó có thể chạy trên Amazon RDS hoặc dưới dạng cơ sở dữ liệu tự quản lý trên AWS hoặc hoàn toàn bên ngoài AWS.

Nếu bạn đang chạy Phiên bản Aurora tương thích với MySQL 5.7, hãy cân nhắc việc thiết lập sao chép binlog dựa trên GTID. Điều này sẽ tạo sự nhất quán hoàn toàn để việc sao chép của bạn không bỏ lỡ giao dịch hoặc tạo ra xung đột, ngay cả sau khi chuyển đổi dự phòng hoặc ngừng hoạt động.

Cơ sở dữ liệu toàn cầu Amazon Aurora là tính năng cho phép một cơ sở dữ liệu Amazon Aurora trải rộng ra nhiều khu vực AWS. Tính năng này sao chép dữ liệu mà không ảnh hưởng đến hiệu năng của cơ sở dữ liệu, cho phép đọc cục bộ nhanh chóng trong mỗi Khu vực với độ trễ thường dưới 1 giây, đồng thời đem lại khả năng phục hồi sau thảm họa do sự cố ngừng hoạt động trên toàn khu vực. Trong trường hợp hiếm gặp là ngừng hoạt động hoặc giảm hiệu năng tại khu vực, một khu vực phụ có thể được tăng cấp để đảm nhận toàn bộ chức năng đọc/ghi trong chưa đầy một phút. Tính năng này có trên cả Phiên bản Aurora tương thích với MySQL và Phiên bản Aurora tương thích với PostgreSQL.

Bạn có thể tạo Cơ sở dữ liệu toàn cầu Aurora chỉ với vài cú nhấp chuột trong bảng điều khiển Amazon RDS. Ngoài ra, bạn có thể sử dụng Bộ phát triển phần mềm (SDK) AWS hoặc Giao diện dòng lệnh (CLI) AWS. Bạn cần cấp phép tối thiểu một phiên bản cho mỗi khu vực trong Cơ sở dữ liệu toàn cầu Amazon Aurora.

Bạn có thể tạo tối đa năm khu vực phụ cho mỗi Cơ sở dữ liệu toàn cầu Amazon Aurora.

Có. Nếu mục tiêu của bạn là phân tích hoạt động cơ sở dữ liệu, hãy cân nhắc sử dụng tính năng kiểm tra nâng cao, bản ghi chung và bản ghi truy vấn chậm của Aurora để tránh ảnh hưởng đến hiệu năng của cơ sở dữ liệu.

Không. Nếu khu vực chính của bạn không khả dụng, bạn có thể xóa thủ công khu vực phụ khỏi Cơ sở dữ liệu toàn cầu Amazon Aurora và tăng cấp khu vực đó để đảm nhận toàn bộ chức năng đọc và ghi. Bạn cũng cần trỏ ứng dụng của mình sang khu vực mới tăng cấp.

Có, mọi Phiên bản CSDL của Amazon Aurora đều phải được tạo trong VPC. Với Amazon VPC, bạn có thể xác định một cấu trúc mạng ảo giống nhất với mạng truyền thống mà bạn vận hành tại trung tâm dữ liệu của riêng mình. Việc này sẽ cho bạn quyền kiểm soát hoàn toàn đối tượng nào được truy cập vào cơ sở dữ liệu Amazon Aurora của bạn.

Có. Amazon Aurora sử dụng SSL (AES-256) để bảo mật kết nối giữa phiên bản cơ sở dữ liệu và ứng dụng. Amazon Aurora cho phép bạn mã hóa cơ sở dữ liệu bằng các khóa do bạn quản lý thông qua Dịch vụ quản lý khóa của AWS (AWS KMS).

Trên một phiên bản cơ sở dữ liệu đang chạy với mã hóa Amazon Aurora, dữ liệu đang được lưu trữ trên bộ lưu trữ cơ bản được mã hóa, giống như các bản sao lưu, bản kết xuất nhanh và bản sao tự động trong cùng cụm. Quá trình mã hóa và giải mã được xử lý một cách trơn tru. Để biết thêm thông tin về việc sử dụng AWS KMS với Amazon Aurora, hãy tham khảo Hướng dẫn dành cho người dùng Amazon RDS.

Hiện tại, việc mã hóa phiên bản Aurora hiện có chưa được mã hóa không được hỗ trợ. Để sử dụng mã hóa Amazon Aurora cho cơ sở dữ liệu hiện có chưa được mã hóa, hãy tạo phiên bản CSDL mới đã kích hoạt mã hóa rồi di chuyển dữ liệu của bạn vào đó.

Bạn phải truy cập cơ sở dữ liệu Aurora thông qua cổng cơ sở dữ liệu được nhập khi tạo cơ sở dữ liệu. Việc này tạo thêm một lớp bảo mật cho dữ liệu của bạn. Hướng dẫn từng bước về cách kết nối đến cơ sở dữ liệu Amazon Aurora của bạn được cung cấp trong Hướng dẫn kết nối Amazon Aurora.

Có, các phiên bản tương thích với MySQL và PostgreSQL của Aurora đáp ứng tiêu chuẩn của HIPAA. Bạn có thể sử dụng các phiên bản này để xây dựng các ứng dụng tuân thủ HIPAA và lưu trữ thông tin liên quan đến chăm sóc sức khỏe, bao gồm thông tin sức khỏe được bảo vệ (PHI) theo Phụ lục liên kết kinh doanh (BAA) đã ký với AWS. Nếu bạn đã ký BAA với AWS, bạn không cần phải làm gì thêm để bắt đầu sử dụng các dịch vụ này trên (các) tài khoản thuộc phạm vi BAA của bạn. Để biết thêm thông tin về cách sử dụng AWS để xây dựng các ứng dụng tuân thủ, hãy xem Nhà cung cấp dịch vụ chăm sóc sức khỏe.

Hiện bạn có thể tìm xem danh sách các CVE tại Bản cập nhật bảo mật Amazon Aurora.

Aurora được tích hợp với Amazon GuardDuty để giúp bạn xác định các mối đe dọa tiềm ẩn đối với dữ liệu được lưu trữ trong cơ sở dữ liệu Aurora. Tính năng Bảo vệ RDS của GuardDuty phân tích và giám sát hoạt động đăng nhập và cơ sở dữ liệu mới trong tài khoản của bạn, đồng thời sử dụng các mô hình ML phù hợp để phát hiện các lượt đăng nhập đáng ngờ vào cơ sở dữ liệu Aurora. Để biết thêm thông tin, hãy tham khảo Giám sát các mối đe dọa bằng tính năng Bảo vệ RDS của GuardDuty và Hướng dẫn sử dụng tính năng Bảo vệ RDS của GuardDuty.

Aurora phi máy chủ là cấu hình theo nhu cầu, tự động điều chỉnh quy mô dành cho Amazon Aurora. Với Aurora phi máy chủ, bạn có thể chạy cơ sở dữ liệu của mình trên nền tảng đám mây mà không phải quản lý dung lượng cơ sở dữ liệu. Việc quản lý thủ công dung lượng cơ sở dữ liệu có thể tốn thời gian và dẫn đến việc sử dụng không hiệu quả tài nguyên cơ sở dữ liệu. Với Aurora phi máy chủ, bạn tạo ra cơ sở dữ liệu, chỉ định phạm vi dung lượng cơ sở dữ liệu mong muốn, rồi kết nối với ứng dụng của mình. Aurora tự động điều chỉnh dung lượng trong phạm vi bạn đã chỉ định dựa trên nhu cầu ứng dụng của bạn.

Bạn trả phí tính theo giây cho dung lượng cơ sở dữ liệu mà bạn sử dụng khi cơ sở dữ liệu hoạt động. Tìm hiểu thêm về Aurora phi máy chủ và bắt đầu sử dụng chỉ với vài bước trong Bảng điều khiển quản lý Amazon RDS.

Aurora phi máy chủ v2 hỗ trợ mọi loại khối lượng công việc cơ sở dữ liệu, từ môi trường phát triển và thử nghiệm, trang web và ứng dụng có khối lượng công việc không thường xuyên, không liên tục hoặc không thể đoán trước được đến các ứng dụng kinh doanh quan trọng, khắt khe nhất đòi hỏi quy mô lớn và tính sẵn sàng cao. Phiên bản này điều chỉnh quy mô tại chỗ bằng cách bổ sung CPU và bộ nhớ mà không cần phải chuyển đổi dự phòng cơ sở dữ liệu sang phiên bản cơ sở dữ liệu lớn hơn hoặc nhỏ hơn. Do đó, phiên bản này có thể điều chỉnh quy mô ngay cả khi có các giao dịch đang diễn ra trong thời gian dài, khóa bảng, v.v.

Ngoài ra, phiên bản này điều chỉnh quy mô dung lượng cơ sở dữ liệu theo gia số nhỏ tới 0,5 Đơn vị dung lượng Aurora (ACU) để dung lượng cơ sở dữ liệu của bạn khớp hơn với nhu cầu ứng dụng của bạn.

Aurora phi máy chủ phiên bản 1 đem đến tùy chọn đơn giản và tiết kiệm chi phí cho các khối lượng công việc không thường xuyên, không liên tục và không thể dự đoán trước. Phiên bản này tự động khởi động, thay đổi dung lượng điện toán để phù hợp với mức sử dụng ứng dụng của bạn và tắt khi không sử dụng. Hãy truy cập vào Hướng dẫn sử dụng Aurora để tìm hiểu thêm.

Aurora phi máy chủ phiên bản 2 hỗ trợ tất cả các tính năng của Aurora được cung cấp, bao gồm bản sao chỉ có quyền đọc, cấu hình nhiều Vùng sẵn sàng, Cơ sở dữ liệu toàn cầu Aurora, Proxy RDS và Thông tin chuyên sâu về hiệu năng.

Có. Bạn có thể bắt đầu sử dụng Aurora phi máy chủ phiên bản 2 để quản lý dung lượng điện toán cơ sở dữ liệu trong cụm CSDL Aurora hiện có của bạn. Một cụm có cả hai phiên bản được cung cấp cũng như Aurora Serverless v2 được gọi là cụm cấu hình hỗn hợp. Bạn có thể chọn dùng Aurora Serverless v2 kết hợp với bất cứ phiên bản được cung cấp nào trong cụm của mình.

Để kiểm thử Aurora Serverless v2, bạn hãy thêm trình đọc vào cụm cơ sở dữ liệu Aurora của mình và chọn loại phiên bản là Serverless v2. Sau khi trình đọc đã được tạo và sẵn sàng, bạn có thể bắt đầu dùng cho khối lượng công việc chỉ đọc. Khi bạn xác nhận rằng trình đọc đang hoạt động như mong đợi, bạn có thể bắt đầu chuyển đổi dự phòng để sử dụng Aurora Serverless v2 cho cả tác vụ đọc và ghi. Tùy chọn này cung cấp trải nghiệm thời gian ngừng hoạt động tối thiểu để bắt đầu sử dụng Aurora Serverless v2.

Có. Bạn có thể di chuyển từ Aurora phi máy chủ v1 sang Aurora phi máy chủ v2. Hãy tham khảo Hướng dẫn sử dụng Aurora để tìm hiểu thêm.

Bạn có thể xem thông tin về khả năng tương thích của Aurora Serverless v1 tại đây. Bạn có thể xem thông tin về khả năng tương thích của Aurora Serverless v2 tại đây.

Có, bạn có thể khôi phục ảnh chụp nhanh được lấy từ cụm Aurora được cung cấp hiện có vào Cụm CSDL Aurora phi máy chủ và ngược lại.

Bạn truy cập vào cụm CSDL Aurora Serverless từ bên trong một ứng dụng khách chạy trong cùng một VPC. Bạn không thể cấp địa chỉ IP công cộng cho CSDL Aurora Serverless.

Aurora phi máy chủ tự động thay đổi quy mô theo khối lượng công việc cơ sở dữ liệu hiện hoạt nhưng đôi khi, dung lượng có thể không thay đổi đủ nhanh để đáp ứng sự thay đổi khối lượng công việc bất ngờ, ví dụ như số lượng lớn giao dịch mới. Trong các trường hợp này, bạn có thể chỉ định rõ ràng giá trị dung lượng cụ thể bằng Bảng điều khiển quản lý AWS, AWS CLI hoặc API Amazon RDS.

Sau khi khởi động hoạt động thay đổi quy mô, Aurora phi máy chủ cố gắng tìm kiếm một điểm thay đổi quy mô, đây là điểm mà cơ sở dữ liệu có thể hoàn thành quá trình thay đổi quy mô một cách an toàn. Aurora phi máy chủ có thể sẽ không tìm được điểm thay đổi quy mô nếu bạn có nhiều truy vấn dài, giao dịch đang diễn ra hoặc nhiều bảng tạm thời hay khóa bảng đang được sử dụng.

Trong Aurora phi máy chủ, dung lượng cơ sở dữ liệu được đo bằng ACU. Bạn trả một mức phí cố định cho mỗi giây sử dụng ACU. Chi phí điện toán để chạy khối lượng công việc của bạn trên Aurora phi máy chủ sẽ phụ thuộc vào cấu hình cụm cơ sở dữ liệu mà bạn chọn: Aurora tiêu chuẩn hoặc Aurora tối ưu hóa I/O. Truy cập vào trang định giá Aurora để biết thông tin về cách định giá và Khu vực cung cấp dịch vụ.

Đọc được tối ưu hóa của Amazon Aurora dành cho Aurora PostgreSQL là một tùy chọn giá-hiệu năng mới giúp cải thiện độ trễ truy vấn lên đến 8 lần và tiết kiệm tới 30% chi phí so với các phiên bản không có tùy chọn này. Đây là tùy chọn lý tưởng cho các ứng dụng có tập dữ liệu lớn vượt quá dung lượng bộ nhớ của phiên bản cơ sở dữ liệu.

Phiên bản Đọc được tối ưu hóa của Amazon Aurora sử dụng kho lưu trữ cấp khối SSD dựa trên NVMe cục bộ (được cung cấp trên các phiên bản r6gd dựa trên Graviton và r6id dựa trên Intel) để cải thiện độ trễ truy vấn của các ứng dụng có tập dữ liệu vượt quá dung lượng bộ nhớ của phiên bản cơ sở dữ liệu. Đọc được tối ưu hóa bao gồm các cải tiến về hiệu năng như lưu bộ nhớ đệm theo bậc và các đối tượng tạm thời.

Lưu bộ nhớ đệm theo bậc giúp cải thiện độ trễ truy vấn lên đến 8 lần và tiết kiệm tới 30% chi phí cho các ứng dụng cần đọc nhiều, sử dụng nhiều I/O như bảng điều khiển hoạt động, phát hiện bất thường và tìm kiếm tương tự dựa trên véc-tơ. Những lợi ích này được thực hiện bằng cách tự động lưu trữ dữ liệu bị loại bỏ khỏi bộ nhớ đệm của cơ sở dữ liệu nằm trong bộ nhớ vào kho lưu trữ cục bộ để tăng tốc độ truy cập dữ liệu đó trong những lần sau. Lưu bộ nhớ đệm theo bậc chỉ dành cho Phiên bản Amazon Aurora PostgreSQL với cấu hình Aurora tối ưu hóa I/O.

Các đối tượng tạm thời sẽ giúp xử lý truy vấn nhanh hơn bằng cách đặt các bảng tạm thời do Aurora PostgreSQL tạo ra trên kho lưu trữ cục bộ, cải thiện hiệu năng của các truy vấn liên quan đến sắp xếp, tổng hợp băm, tham gia tải cao và các hoạt động yêu cầu nhiều dữ liệu khác.

Đọc được tối ưu hóa của Amazon Aurora cho Aurora PostgreSQL cung cấp một giải pháp giá-hiệu năng thay thế hấp dẫn cho khách hàng có các ứng dụng nhạy cảm với độ trễ và tập làm việc quy mô lớn để đáp ứng các SLA kinh doanh của họ và khai thác các phiên bản của họ triệt để hơn nữa.

Đọc được tối ưu hóa của Amazon Aurora có sẵn trên các phiên bản R6id dựa trên Intel và R6gd dựa trên Graviton. Bạn có thể xem Khu vực có khả năng sử dụng Aurora tại đây.

Đọc được tối ưu hóa của Amazon Aurora có sẵn cho Phiên bản tương thích với PostgreSQL của Aurora trên các phiên bản R6id và R6gd. Các phiên bản công cụ được hỗ trợ là 15.4 trở lên và 14.9 trở lên trên Aurora PostgreSQL.

Đọc được tối ưu hóa của Amazon Aurora không khả dụng trên Aurora phi máy chủ phiên bản 2 (ASv2).

Có, Đọc được tối ưu hóa của Amazon Aurora khả dụng với cả hai cấu hình. Trên cả hai cấu hình, các phiên bản hỗ trợ Đọc được tối ưu hóa sẽ tự động ánh xạ các bảng tạm thời vào kho lưu trữ cục bộ dựa trên NVMe để cải thiện hiệu năng của các truy vấn phân tích và tạo lại chỉ mục.

Đối với khối lượng công việc sử dụng nhiều I/O cần đọc nhiều, các phiên bản hỗ trợ Đọc được tối ưu hóa trên Aurora PostgreSQL được cấu hình để sử dụng Aurora tối ưu hóa I/O tự động lưu trữ dữ liệu bị loại bỏ khỏi bộ nhớ trên kho lưu trữ cục bộ dựa trên NVMe để cải thiện độ trễ truy vấn lên đến 8 lần và tiết kiệm chi phí lên đến 30% so với các phiên bản không có tùy chọn này, cho các ứng dụng có tập dữ liệu lớn vượt quá dung lượng bộ nhớ của phiên bản cơ sở dữ liệu.

Khách hàng có thể bắt đầu sử dụng Đọc được tối ưu hóa của Amazon Aurora thông qua Bảng điều khiển quản lý AWS, CLI và SDK. Đọc được tối ưu hóa có sẵn trên tất cả các phiên bản R6id và R6gd theo mặc định. Để sử dụng chức năng này, khách hàng chỉ cần sửa đổi cụm cơ sở dữ liệu Aurora hiện tại của mình để bao gồm các phiên bản R6id và R6gd hoặc tạo cụm cơ sở dữ liệu mới bằng các phiên bản này. Xem tài liệu về Đọc được tối ưu hóa của Amazon Aurora để bắt đầu.

Khoảng 90% dung lượng lưu trữ cục bộ có sẵn trên các phiên bản R6id và R6gd dành cho Đọc được tối ưu hóa, Aurora dành 10% kho lưu trữ NVMe để giảm tác động của việc khuếch đại ghi SSD. Việc phân bổ dung lượng lưu trữ khả dụng phụ thuộc vào các tính năng Đọc được tối ưu hóa được bật.

Khi sử dụng Đọc được tối ưu hóa với cả tính năng Đối tượng tạm thời và Lưu bộ nhớ đệm theo bậc, không gian sẵn có cho các đối tượng tạm thời trong kho lưu trữ cục bộ tương đương 2 lần kích thước bộ nhớ sẵn có trên các phiên bản cơ sở dữ liệu này. Điều này phù hợp với kích thước hiện tại của kho lưu trữ đối tượng tạm thời trên Aurora PostgreSQL. Dung lượng đĩa lưu trữ cục bộ còn lại dành cho lưu dữ liệu vào bộ nhớ đệm.

Khi chỉ sử dụng Đọc được tối ưu hóa với tính năng Đối tượng tạm thời, toàn bộ không gian đĩa lưu trữ cục bộ có sẵn đều dành cho các đối tượng tạm thời. Ví dụ: khi sử dụng phiên bản r6gd.8xlarge với cả tính năng Đối tượng tạm thời và Lưu bộ nhớ đệm theo bậc, 534 GiB (2 lần dung lượng bộ nhớ) được dành riêng cho các đối tượng tạm thời và 1054 GiB dành riêng cho bộ nhớ đệm theo bậc.

Nếu kho lưu trữ cục bộ có lỗi, Aurora sẽ tự động thực hiện thay thế máy chủ. Trong cụm cơ sở dữ liệu nhiều nút, thao tác này kích hoạt chuyển đổi dự phòng trong khu vực.

Trong trường hợp chuyển đổi dự phòng cơ sở dữ liệu, độ trễ truy vấn sẽ tạm thời tăng sau khi chuyển đổi dự phòng. Mức tăng độ trễ này sẽ giảm theo thời gian và cuối cùng sẽ bắt kịp độ trễ truy vấn trước khi chuyển đổi dự phòng. Có thể đẩy nhanh thời gian bắt kịp này bằng cách bật quản lý bộ nhớ đệm của cụm (CCM). Với CCM, khách hàng có thể chỉ định một phiên bản cơ sở dữ liệu Aurora PostgreSQL cụ thể làm đích chuyển đổi dự phòng.

Khi CCM được bật, bộ nhớ đệm lưu trữ cục bộ của đích chuyển đổi dự phòng được chỉ định sẽ phản chiếu sát sao bộ nhớ đệm lưu trữ cục bộ của phiên bản chính, giảm thời gian bắt kịp sau khi chuyển đổi dự phòng. Tuy nhiên, việc bật CCM có thể ảnh hưởng đến hiệu suất lâu dài của bộ nhớ đệm lưu trữ cục bộ nếu đích chuyển đổi dự phòng được chỉ định cũng đang được sử dụng để phục vụ khối lượng công việc đọc tách biệt với khối lượng công việc trên phiên bản trình ghi.

Do đó, khách hàng chạy khối lượng công việc yêu cầu trình đọc được chỉ định là chuyển đổi dự phòng phải bật CCM để tăng khả năng nhanh chóng khôi phục độ trễ truy vấn sau khi chuyển đổi dự phòng. Khách hàng chạy các khối lượng công việc riêng biệt trên các đích chuyển đổi dự phòng được chỉ định của họ nên cân bằng nhu cầu khôi phục độ trễ ngay lập tức sau khi chuyển đổi dự phòng với hiệu quả lâu dài của hiệu năng bộ nhớ đệm trước khi bật CCM.

pgvector là một phần mở rộng nguồn mở cho PostgreSQL được hỗ trợ bởi Phiên bản Amazon Aurora tương thích với PostgreSQL.

Có. Máy học Aurora (ML) hiển thị các mô hình ML dưới dạng hàm SQL, cho phép bạn sử dụng SQL tiêu chuẩn để gọi và truyền dữ liệu đến các mô hình ML đó, sau đó trả về dự đoán dưới dạng kết quả truy vấn. pgvector cần các phần nhúng véc-tơ được lưu trữ trong cơ sở dữ liệu, tức là yêu cầu chạy mô hình ML trên dữ liệu hình ảnh hoặc văn bản nguồn để tạo ra các phần nhúng và sau đó di chuyển theo lô phần nhúng vào Aurora PostgreSQL.

Aurora ML có thể biến quy trình này thành quy trình theo thời gian thực, cho phép cập nhật các phần nhúng trong Aurora PostgreSQL bằng cách thực hiện các lệnh gọi định kỳ tới Amazon Bedrock hoặc Amazon SageMaker, giúp trả về các phần nhúng gần đây nhất từ mô hình của bạn.

Có. Có hai phương pháp tích hợp cơ sở dữ liệu Amazon Aurora với Amazon Bedrock để hỗ trợ các ứng dụng AI tạo sinh. Phương pháp thứ nhất: hiện công nghệ ML của Amazon Aurora có thể cung cấp khả năng truy cập vào các mô hình nền tảng được cung cấp trực tiếp trong Amazon Bedrock thông qua SQL cho cả Aurora MySQL và Aurora PostgreSQL. Phương pháp thứ hai: bạn có thể cấu hình Aurora làm Cơ sở kiến thức cho Amazon Bedrock và lưu trữ các phần nhúng được tạo ra từ Bedrock trên Aurora. Cơ sở kiến thức cho Amazon Bedrock hỗ trợ Aurora PostgreSQL như một kho véc-tơ cho các trường hợp sử dụng như Kỹ thuật tạo sinh tăng cường truy xuất (RAG). Đọc blog và tài liệu của chúng tôi về cách sử dụng Aurora PostgreSQL làm Cơ sở kiến thức cho Amazon Bedrock.

Tính năng Đọc tối ưu hóa của Amazon Aurora PostgreSQL với pgvector tăng số lượng truy vấn mỗi giây cho lượt tìm kiếm véc-tơ lên đến gấp 9 lần trong khối lượng công việc vượt quá bộ nhớ phiên bản được cung cấp. Điều này khả thi nhờ tính năng lưu bộ nhớ đệm theo bậc được cung cấp trong tính năng Đọc tối ưu hóa sẽ tự động lưu dữ liệu bị loại bỏ khỏi bộ nhớ đệm của cơ sở dữ liệu nằm trong bộ nhớ vào kho lưu trữ cục bộ để tăng tốc độ truy cập dữ liệu đó trong những lần sau.

Đọc blog và tài liệu của chúng tôi về cách nâng cao hiệu năng truy vấn cho Aurora PostgreSQL bằng tính năng Đọc tối ưu hóa của Aurora.

Bạn nên sử dụng tích hợp không ETL giữa Amazon Aurora và Amazon Redshift khi cần truy cập dữ liệu giao dịch gần thời gian thực. Tích hợp này cho phép bạn tận dụng ML của Amazon Redshift với các lệnh SQL đơn giản.

Tích hợp không ETL giữa Aurora và Amazon Redshift có sẵn trên Phiên bản Aurora tương thích với MySQL dành cho phiên bản Aurora MySQL 3.05 (tương thích với MySQL 8.0.32) trở lên ở các Khu vực Miền Đông Hoa Kỳ (Ohio), Miền Đông Hoa Kỳ (Bắc Virginia), Miền Tây Hoa Kỳ (Oregon), Châu Á Thái Bình Dương (Singapore), Châu Á Thái Bình Dương (Sydney), Châu Á Thái Bình Dương (Tokyo), Châu Âu (Frankfurt), Châu Âu (Ireland) và Châu Âu (Stockholm). Tích hợp không ETL giữa Aurora và Amazon Redshift có sẵn trên Phiên bản Aurora tương thích với PostgreSQL dành cho phiên bản Aurora PostgreSQL 15.4 ở Khu vực Miền Đông Hoa Kỳ (Ohio).

Tích hợp không ETL giữa Aurora và Amazon Redshift loại bỏ nhu cầu xây dựng và duy trì các kênh dữ liệu phức tạp. Bạn có thể hợp nhất dữ liệu từ nhiều bảng từ nhiều cụm cơ sở dữ liệu Aurora khác nhau vào một cụm cơ sở dữ liệu duy nhất của Amazon Redshift, sau đó chạy phân tích gần thời gian thực và ML thông qua Amazon Redshift trên hàng petabyte dữ liệu giao dịch từ Aurora. Bạn có thể chọn cơ sở dữ liệu và bảng sẽ được sao chép từ Aurora sang Amazon Redshift. Dựa vào nhu cầu phân tích của bạn, việc lọc dữ liệu của cơ sở dữ liệu và bảng cụ thể giúp bạn đưa dữ liệu vào Amazon Redshift một cách có chọn lọc.

Tích hợp không ETL giữa Aurora và Amazon Redshift tương thích với Aurora phi máy chủ phiên bản 2. Khi sử dụng cả Aurora phi máy chủ phiên bản 2 và Amazon Redshift phi máy chủ, bạn có thể tạo phân tích gần thời gian thực trên dữ liệu giao dịch mà không cần quản lý bất kỳ cơ sở hạ tầng nào cho các kênh dữ liệu.

Bạn có thể bắt đầu từ việc sử dụng bảng điều khiển Amazon RDS để tạo tích hợp không ETL bằng cách chỉ định nguồn Aurora và đích Amazon Redshift. Sau khi tích hợp đã được tạo, cơ sở dữ liệu Aurora sẽ được sao chép sang Amazon Redshift và bạn có thể bắt đầu truy vấn dữ liệu sau khi quá trình gieo hạt ban đầu hoàn tất. Để biết thêm thông tin, hãy đọc hướng dẫn bắt đầu về tích hợp không ETL giữa Aurora và Amazon Redshift.

Khả năng xử lý liên tục các thay đổi dữ liệu bằng cách tích hợp không ETL được cung cấp miễn phí. Bạn trả tiền cho các tài nguyên Amazon RDS và Amazon Redshift hiện tại được sử dụng để tạo và xử lý dữ liệu thay đổi được tạo trong quá trình tích hợp không ETL. Những tài nguyên này có thể bao gồm:

• Dữ liệu đầu vào/đầu ra và dung lượng bổ sung được sử dụng bằng cách kích hoạt binlog (nhật ký nhị phân) nâng cao
• Chi phí xuất ảnh chụp nhanh cho lần xuất dữ liệu ban đầu để khởi tạo cơ sở dữ liệu Amazon Redshift của bạn
• Dung lượng Amazon Redshift bổ sung để lưu trữ dữ liệu được sao chép
• Điện toán Amazon Redshift bổ sung để xử lý sao chép dữ liệu
• Chi phí truyền dữ liệu giữa các Vùng sẵn sàng để chuyển dữ liệu từ nguồn sang đích

Để biết thêm thông tin, hãy truy cập trang định giá của Aurora.

Có, bạn có thể quản lý và tự động hóa cấu hình cũng như triển khai tài nguyên cần thiết để tích hợp không ETL Aurora MySQL với Amazon Redshift bằng AWS CloudFormation. Để biết thêm thông tin, hãy truy cập các mẫu CloudFormation với tích hợp không ETL.

Amazon DevOps Guru dành cho RDS là một tính năng mới được hỗ trợ bởi ML dành cho Amazon RDS (bao gồm cả Amazon Aurora). Tính năng này được thiết kế để tự động phát hiện và chẩn đoán các sự cố về hoạt động và hiệu năng của cơ sở dữ liệu, cho phép bạn giải quyết sự cố chỉ trong vài phút thay vì mất vài ngày.

Amazon DevOps Guru dành cho RDS là một tính năng của Amazon DevOps Guru, được thiết kế để phát hiện các sự cố về hoạt động và hiệu năng cho tất cả các công cụ Amazon RDS và hàng chục loại tài nguyên khác. DevOps Guru for RDS mở rộng khả năng của DevOps Guru, cho phép phát hiện, chẩn đoán và khắc phục nhiều sự cố liên quan đến cơ sở dữ liệu trong Amazon RDS (ví dụ: sử dụng quá mức tài nguyên và hoạt động bất thường của một số truy vấn SQL).

Khi xảy ra sự cố, Amazon DevOps Guru dành cho RDS được thiết kế để lập tức thông báo cho các nhà phát triển và kỹ sư DevOps, đồng thời cung cấp thông tin chẩn đoán, chi tiết về mức độ của sự cố và các đề xuất khắc phục thông minh để giúp khách hàng nhanh chóng giải quyết các sự cố vận hành và nút thắt hiệu năng liên quan đến cơ sở dữ liệu.

Amazon DevOps Guru dành cho RDS được thiết kế để không cần xử lý thủ công và rút ngắn thời gian (từ nhiều giờ và ngày xuống còn vài phút) để phát hiện và giải quyết các nút thắt hiệu năng khó tìm trong khối lượng công việc cơ sở dữ liệu quan hệ của bạn.

Bạn có thể bật DevOps Guru for RDS cho mỗi cơ sở dữ liệu Amazon Aurora và tính năng này sẽ tự động phát hiện các sự cố về hiệu năng cho khối lượng công việc của bạn, gửi cảnh báo cho bạn về từng sự cố, giải thích các phát hiện và đề xuất các hành động để giải quyết.
DevOps Guru for RDS giúp những người không phải chuyên gia dễ tiếp cận hơn với quản trị cơ sở dữ liệu và hỗ trợ các chuyên gia cơ sở dữ liệu để họ có thể quản lý nhiều cơ sở dữ liệu hơn nữa.

Amazon DevOps Guru dành cho RDS sử dụng ML để phân tích dữ liệu đo từ xa do Thông tin chuyên sâu về hiệu năng (PI) của Amazon RDS thu thập. DevOps Guru for RDS không sử dụng bất kỳ dữ liệu nào của bạn được lưu trữ trong cơ sở dữ liệu để phân tích. PI đo tải cơ sở dữ liệu, một số liệu đặc trưng cho cách thức ứng dụng dành thời gian trong cơ sở dữ liệu và các số liệu được chọn do cơ sở dữ liệu tạo ra, chẳng hạn như các biến trạng thái máy chủ trong MySQL và bảng pg_stat trong PostgreSQL.

Để bắt đầu sử dụng DevOps Guru dành cho RDS, hãy đảm bảo bạn đã bật Thông tin chuyên sâu về hiệu năng thông qua bảng điều khiển RDS, sau đó chỉ cần bật DevOps Guru cho cơ sở dữ liệu Amazon Aurora của bạn. Với DevOps Guru, bạn có thể chọn ranh giới phạm vi phân tích là toàn bộ tài khoản AWS của mình, quy định các ngăn xếp AWS CloudFormation cụ thể mà bạn muốn DevOps Guru phân tích hoặc sử dụng thẻ AWS để tạo nhóm tài nguyên mà bạn muốn DevOps Guru phân tích.

Amazon DevOps Guru dành cho RDS giúp xác định một loạt các sự cố về hiệu năng có thể ảnh hưởng đến chất lượng dịch vụ ứng dụng, chẳng hạn như khóa chồng chất, bão kết nối, hồi quy SQL, tranh chấp CPU và I/O cũng như các sự cố về bộ nhớ.

Thông tin chuyên sâu về hiệu năng của Amazon RDS là tính năng giám sát và điều chỉnh hiệu năng cơ sở dữ liệu, giúp thu thập và trực quan hóa các chỉ số hiệu năng cơ sở dữ liệu của Amazon RDS, giúp bạn nhanh chóng đánh giá tải trên cơ sở dữ liệu của mình, đồng thời xác định thời điểm và địa điểm cần hành động. Amazon DevOps Guru dành cho RDS được thiết kế để theo dõi các chỉ số đó, phát hiện thời điểm cơ sở dữ liệu của bạn gặp sự cố về hiệu năng, phân tích các chỉ số, sau đó cho bạn biết có sự cố gì và cách để bạn có thể giải quyết.

Bạn nên sử dụng API dữ liệu cho các ứng dụng hiện đại mới, đặc biệt là những ứng dụng được xây dựng bằng AWS Lambda cần truy cập Aurora trong mô hình yêu cầu/phản hồi. Bạn nên sử dụng trình điều khiển cơ sở dữ liệu thay vì API dữ liệu và quản lý các kết nối cơ sở dữ liệu liên tục khi một ứng dụng hiện có được kết hợp chặt chẽ với trình điều khiển cơ sở dữ liệu, khi có truy vấn kéo dài hoặc khi nhà phát triển muốn tận dụng các tính năng cơ sở dữ liệu như bảng tạm thời hoặc sử dụng các biến thể của phiên.

Bạn có thể tìm hiểu độ sẵn sàng của phiên bản cơ sở dữ liệu và Khu vực AWS của API dữ liệu cho Aurora phi máy chủ phiên bản 2 và các phiên bản Aurora được cung cấp trong tài liệu của chúng tôi. Khách hàng hiện đang sử dụng API dữ liệu cho Aurora phi máy chủ phiên bản 1 được khuyến khích di chuyển sang Aurora phi máy chủ phiên bản 2 để tận dụng API dữ liệu được thiết kế lại và điều chỉnh quy mô chi tiết hơn của Aurora phi máy chủ phiên bản 2.

API dữ liệu sẽ cho phép bạn đơn giản hóa và tăng tốc phát triển ứng dụng hiện đại. API dữ liệu là API dựa trên HTTP an toàn dễ sử dụng, giúp loại bỏ nhu cầu triển khai trình điều khiển cơ sở dữ liệu, quản lý các nhóm kết nối phía máy khách hoặc thiết lập mạng VPC phức tạp giữa ứng dụng và cơ sở dữ liệu. API dữ liệu cũng cải thiện khả năng điều chỉnh quy mô bằng cách tự động gộp chung và chia sẻ các kết nối cơ sở dữ liệu, giúp giảm chi phí điện toán từ các ứng dụng mở và đóng kết nối thường xuyên. 

API dữ liệu hiện có cho Aurora phi máy chủ phiên bản 1 sẽ vẫn là một tính năng của Aurora phi máy chủ phiên bản 1 cho cả Phiên bản tương thích với PostgreSQL và Phiên bản tương thích với MySQL của Aurora. API dữ liệu cho Aurora phi máy chủ phiên bản 2 và các phiên bản Aurora được cung cấp không hỗ trợ Aurora phi máy chủ phiên bản 1. API dữ liệu cho Aurora phi máy chủ phiên bản 2 và các phiên bản Aurora được cung cấp có hỗ trợ các phiên bản ghi Cơ sở dữ liệu toàn cầu Aurora.

Người dùng chỉ có thể gọi các hoạt động API dữ liệu nếu được cho phép làm như vậy. Quản trị viên có thể cấp cho người dùng quyền sử dụng API dữ liệu bằng cách đính kèm chính sách Quản lý danh tính và truy cập (IAM) trong AWS xác định đặc quyền của họ. Bạn cũng có thể đính kèm chính sách vào vai trò nếu bạn đang sử dụng vai trò IAM. Khi gọi API dữ liệu, bạn có thể chuyển thông tin chứng thực cho cụm CSDL Aurora thông qua bí mật trong Trình quản lý thông tin bí mật của AWS. 

Bạn vẫn có thể sử dụng API dữ liệu với Aurora phi máy chủ phiên bản 1 mà không bị tính thêm phí. API dữ liệu cho Aurora phi máy chủ phiên bản 2 và các phiên bản Aurora được cung cấp được định giá theo khối lượng yêu cầu API như được mô tả trên trang định giá của Aurora. API dữ liệu cho Aurora phi máy chủ phiên bản 2 và các phiên bản Aurora được cung cấp sử dụng sự kiện mặt phẳng dữ liệu AWS CloudTrail để ghi lại hoạt động thay vì các sự kiện quản lý, giống như API dữ liệu cho Aurora phi máy chủ phiên bản 1.

Bạn có thể bật ghi sự kiện dữ liệu thông qua bảng điều khiển CloudTrail, CLI hoặc SDK nếu muốn theo dõi hoạt động này. Điều này sẽ phát sinh các khoản phí như được nêu trên trang định giá của CloudTrail. Ngoài ra, việc sử dụng Trình quản lý thông tin bí mật của AWS sẽ phát sinh các khoản phí như được nêu trên trang định giá của Trình quản lý thông tin bí mật của AWS. 

AWS CloudTrail ghi lại hoạt động API AWS dưới dạng sự kiện quản lý hoặc sự kiện dữ liệu. Các sự kiện quản lý CloudTrail (còn được gọi là “hoạt động mặt phẳng điều khiển”) hiển thị các hoạt động quản lý được thực hiện trên các tài nguyên trong tài khoản AWS của bạn, chẳng hạn như tạo, cập nhật và xóa tài nguyên. Sự kiện dữ liệu CloudTrail (còn được gọi là “hoạt động mặt phẳng dữ liệu”) hiển thị các hoạt động tài nguyên được thực hiện trên hoặc trong tài nguyên trong tài khoản AWS của bạn.

API dữ liệu thực hiện các hoạt động mặt phẳng dữ liệu vì thực hiện truy vấn trên dữ liệu trong cơ sở dữ liệu Aurora của bạn. Do đó, chúng tôi sẽ ghi lại hoạt động API dữ liệu dưới dạng sự kiện dữ liệu vì đây là cách phân loại chính xác các sự kiện. Phí sẽ chỉ phát sinh cho các sự kiện dữ liệu CloudTrail nếu bạn bật tính năng ghi sự kiện dữ liệu.

Có, bậc API dữ liệu miễn phí bao gồm tổng cộng một triệu yêu cầu mỗi tháng cho năm đầu tiên sử dụng trên tất cả các Khu vực AWS. Sau một năm, khách hàng sẽ bắt đầu thanh toán cho API dữ liệu như được mô tả trên trang định giá của Aurora.

Triển khai lục/lam trên Amazon RDS sẵn dùng ở Phiên bản Amazon Aurora tương thích với MySQL phiên bản 5.6 trở lên và Phiên bản Amazon Aurora tương thích với PostgreSQL phiên bản 11.21 trở lên, 12.16 trở lên, 13.12 trở lên, 14.9 trở lên và 15.4 trở lên. Hãy tham khảo tài liệu Aurora để tìm hiểu thêm về các phiên bản có sẵn.

Triển khai lục/lam trên Amazon RDS được cung cấp ở tất cả Khu vực AWS có áp dụng và các Khu vực AWS GovCloud.

Triển khai lục/lam trên Amazon RDS cho phép bạn thực hiện thay đổi cơ sở dữ liệu an toàn hơn, đơn giản hơn và nhanh hơn. Triển khai lục/lam là phương pháp lý tưởng dành cho các trường hợp sử dụng như nâng cấp công cụ cơ sở dữ liệu phiên bản lớn hoặc nhỏ, cập nhật hệ điều hành, thay đổi lược đồ trên môi trường xanh lục không phá vỡ hoạt động sao chép logic, chẳng hạn như thêm cột mới vào cuối bảng hoặc thay đổi cài đặt tham số cơ sở dữ liệu.

Bạn có thể sử dụng Triển khai lục/lam để thực hiện nhiều bản cập nhật cơ sở dữ liệu cùng một lúc bằng một lượt chuyển đổi duy nhất. Điều này giúp bạn cập nhật các bản vá bảo mật, cải thiện hiệu năng cơ sở dữ liệu và truy cập các tính năng cơ sở dữ liệu mới hơn với thời gian ngừng hoạt động ngắn và có thể dự đoán. Nếu chỉ muốn nâng cấp một phiên bản nhỏ trên Aurora, bạn nên sử dụng tính năng Vá lỗi với thời gian ngừng hoạt động bằng 0 (ZDP) trên Aurora.

Mức giá chạy khối lượng công việc của bạn trên các phiên bản xanh lục và phiên bản xanh lam là như nhau. Chi phí chạy trên phiên bản xanh lam và xanh lục bao gồm giá tiêu chuẩn hiện tại của chúng tôi cho các phiên bản CSDL, chi phí lưu trữ, chi phí I/O đọc/ghi và mọi tính năng được bật, chẳng hạn như chi phí sao lưu và Thông tin chuyên sâu về hiệu năng trong Amazon RDS. Trên thực tế, bạn sẽ phải trả gấp khoảng 2 lần chi phí chạy khối lượng công việc trên phiên bản CSDL trong suốt thời gian tồn tại triển khai lục-lam.

Ví dụ: Bạn có cụm Phiên bản Aurora tương thích với MySQL 5.7 chạy trên hai phiên bản CSDL r5.2xlarge, một phiên bản ghi chính và một phiên bản đọc, trong khu vực AWS us-east-1. Mỗi phiên bản CSDL r5.2xlarge được cấu hình cho 40 GiB lưu trữ và có 25 triệu I/O mỗi tháng. Bạn tạo một bản sao của cấu trúc liên kết phiên bản xanh lam bằng cách sử dụng Triển khai lục/lam trên Amazon RDS, chạy trong 15 ngày (360 giờ) và mỗi phiên bản xanh lục có 3 triệu lần đọc I/O trong thời gian đó. Sau đó, bạn xóa các phiên bản xanh lam sau khi chuyển đổi thành công. Các phiên bản xanh lam (ghi và đọc) có giá 849,2 USD trong 15 ngày với mức giá theo nhu cầu là 1,179 USD/giờ (Phiên bản + Lưu trữ + I/O). Các phiên bản xanh lục (ghi và đọc) có giá 840,40 USD trong 15 ngày với mức giá theo nhu cầu là 1,167 USD/giờ (Phiên bản + Lưu trữ + I/O). Tổng chi phí cho việc sử dụng Triển khai lục/lam trong 15 ngày đó là 1689,60 USD, gấp khoảng 2 lần chi phí chạy phiên bản xanh lam trong khoảng thời gian đó.

Triển khai lục/lam trên Amazon RDS giúp bạn thực hiện các thay đổi cơ sở dữ liệu an toàn hơn, đơn giản hơn và nhanh hơn, chẳng hạn như nâng cấp phiên bản lớn hoặc nhỏ, thay đổi lược đồ, điều chỉnh quy mô phiên bản, thay đổi tham số công cụ và cập nhật bảo trì.

Trong Triển khai lục/lam trên Amazon RDS, môi trường xanh lam là môi trường sản xuất hiện tại. Môi trường xanh lục là môi trường thử nghiệm mà sẽ trở thành môi trường sản xuất mới sau khi chuyển đổi.

Khi Triển khai lục/lam trên Amazon RDS bắt đầu quá trình chuyển đổi, chúng sẽ chặn lượt ghi vào cả môi trường xanh lam và xanh lục cho đến khi quá trình chuyển đổi hoàn tất. Trong quá trình chuyển đổi, môi trường thử nghiệm, hay còn gọi là môi trường xanh lục, bắt kịp với hệ thống sản xuất, đảm bảo dữ liệu nhất quán giữa môi trường thử nghiệm và sản xuất. Khi môi trường sản xuất và thử nghiệm đồng bộ hoàn toàn, Triển khai lục/lam tăng cấp cho môi trường thử nghiệm thành môi trường sản xuất mới bằng cách chuyển hướng lưu lượng truy cập đến môi trường sản xuất mới được tăng cấp.

Triển khai lục/lam trên Amazon RDS được thiết kế để cho phép ghi trên môi trường xanh lục sau khi quá trình chuyển đổi hoàn tất, đảm bảo không mất dữ liệu trong quá trình chuyển đổi.

Triển khai lục/lam trên Amazon RDS không xóa môi trường sản xuất cũ của bạn. Nếu cần, bạn có thể truy cập môi trường sản xuất cũ để xác thực bổ sung và kiểm thử hiệu năng/hồi quy. Nếu không cần nữa, bạn có thể xóa môi trường sản xuất cũ. Bạn vẫn phải trả phí thanh toán tiêu chuẩn cho các phiên bản sản xuất cũ cho đến khi bạn xóa chúng.

Nếu môi trường xanh lam của bạn là bản sao logic tự quản lý hoặc bên đăng ký nhận, chúng tôi sẽ chặn hoạt động chuyển đổi. Trước tiên, bạn nên dừng sao chép sang môi trường xanh lam, hãy tiến hành chuyển đổi, sau đó tiếp tục sao chép. Ngược lại, nếu môi trường xanh lam của bạn là nguồn cho bản sao logic tự quản lý hoặc bên gửi, bạn có thể tiếp tục chuyển đổi. Tuy nhiên, bạn sẽ cần cập nhật bản sao tự quản lý để sao chép từ môi trường xanh lục sau khi chuyển đổi.

Không, Triển khai lục/lam trên Amazon RDS không hỗ trợ Cơ sở dữ liệu toàn cầu Amazon Aurora, Proxy cho Amazon RDS hay bản sao chỉ có quyền đọc xuyên Khu vực. 

Không, tại thời điểm này, bạn không thể sử dụng Triển khai lục/lam trên Amazon RDS để hoàn tác thay đổi.

Phần mở rộng ngôn ngữ đáng tin cậy (TLE) dành cho PostgreSQL cho phép các nhà phát triển xây dựng các phần mở rộng PostgreSQL hiệu năng cao và chạy chúng một cách an toàn trên Amazon Aurora. Khi làm như vậy, TLE rút ngắn thời gian đưa ra thị trường và loại bỏ gánh nặng cho quản trị viên cơ sở dữ liệu trong việc chứng nhận mã tùy chỉnh và mã của bên thứ ba để sử dụng trong khối lượng công việc cơ sở dữ liệu sản xuất. Bạn có thể tiến hành ngay khi bạn quyết định rằng một phần mở rộng đáp ứng nhu cầu của bạn. Với TLE, các nhà cung cấp phần mềm độc lập (ISV) có thể cung cấp các phần mở rộng PostgreSQL mới cho khách hàng đang chạy trên Aurora.

TLE dành cho PostgreSQL được cung cấp cho Phiên bản Amazon Aurora tương thích với PostgreSQL từ các phiên bản 14.5 trở lên. TLE được triển khai như một phần mở rộng PostgreSQL và bạn có thể kích hoạt nó từ vai trò rds_superuser theo cách tương tự như các phần mở rộng khác được hỗ trợ trên Aurora.

Bạn có thể chạy TLE dành cho PostgreSQL ở PostgreSQL phiên bản 14.5 trở lên trong Amazon Aurora.

TLE dành cho PostgreSQL hiện được cung cấp ở tất cả Khu vực AWS (không bao gồm các Khu vực AWS tại Trung Quốc) và Khu vực AWS GovCloud.

TLE dành cho PostgreSQL được cung cấp cho khách hàng Aurora mà không mất thêm chi phí.

Aurora và Amazon RDS hỗ trợ một tập hợp được tuyển chọn gồm hơn 85 phần mở rộng PostgreSQL. AWS quản lý rủi ro bảo mật cho từng phần mở rộng này theo Mô hình trách nhiệm chung AWS. Phần mở rộng triển khai TLE dành cho PostgreSQL nằm trong tập hợp này. Các phần mở rộng mà bạn ghi hoặc bạn có được từ các nguồn của bên thứ ba và cài đặt trong TLE được coi là một phần thuộc mã ứng dụng của bạn. Bạn chịu trách nhiệm về tính bảo mật của các ứng dụng sử dụng phần mở rộng TLE.

Bạn có thể xây dựng các chức năng dành cho nhà phát triển, chẳng hạn như nén bitmap và quyền riêng tư khác biệt (chẳng hạn như các truy vấn thống kê có thể truy cập công khai để bảo vệ quyền riêng tư của các cá nhân).

TLE dành cho PostgreSQL hiện hỗ trợ JavaScript, PL/pgSQL, Perl và SQL.

Khi vai trò rds_superuser kích hoạt TLE dành cho PostgreSQL, bạn có thể triển khai các phần mở rộng TLE bằng cách sử dụng lệnh SQL CREATE EXTENSION từ bất kỳ máy khách PostgreSQL nào, chẳng hạn như psql. Điều này tương tự như cách bạn tạo một hàm do người dùng xác định được viết bằng ngôn ngữ thủ tục, ví dụ như PL/pgSQL hoặc PL/Perl. Bạn có thể kiểm soát người dùng nào có quyền triển khai phần mở rộng TLE và sử dụng các phần mở rộng cụ thể.

TLE dành cho PostgreSQL chỉ truy cập cơ sở dữ liệu PostgreSQL của bạn thông qua API TLE. Các ngôn ngữ đáng tin cậy được TLE hỗ trợ bao gồm tất cả các chức năng của giao diện lập trình máy chủ (SPI) PostgreSQL và hỗ trợ cho các hook của PostgreSQL, bao gồm cả hook kiểm tra mật khẩu.

Bạn có thể tìm hiểu thêm về dự án TLE dành cho PostgreSQL trên trang GitHub chính thức của TLE.