PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Nhà cung cấp dịch vụ đám mây chuyên sâu:PostgreSQL trên AWS Aurora

Chúng ta nên đi sâu đến mức nào với điều này? Tôi sẽ bắt đầu bằng cách nói rằng tính đến thời điểm viết bài này, tôi chỉ có thể tìm thấy 3 cuốn sách trên Amazon về PostgreSQL trên đám mây và 117 cuộc thảo luận trên danh sách gửi thư PostgreSQL về Aurora PostgreSQL. Điều đó trông không giống nhiều, và nó khiến tôi, người dùng cuối PostgreSQL tò mò, với tài liệu chính thức là nơi duy nhất mà tôi thực sự có thể tìm hiểu thêm. Vì tôi không có khả năng cũng như không có kiến ​​thức để tự mình khám phá sâu hơn nhiều, nên có AWS re:Invent 2018 dành cho những ai đang tìm kiếm loại cảm giác mạnh đó. Tôi có thể giải quyết bài báo của Werner về số đại biểu.

Để khởi động, tôi bắt đầu từ trang chủ Aurora PostgreSQL, nơi tôi lưu ý rằng điểm chuẩn cho thấy Aurora PostgreSQL nhanh hơn ba lần so với PostgreSQL tiêu chuẩn chạy trên cùng một phần cứng có từ PostgreSQL 9.6. Như tôi đã tìm hiểu ở phần sau, 9.6.9 hiện là tùy chọn mặc định khi thiết lập một cụm mới. Đó là tin rất tốt cho những ai không muốn hoặc không thể nâng cấp ngay lập tức. Và tại sao chỉ có 99,99% khả dụng? Bạn có thể tìm thấy một lời giải thích trong bài viết của Bruce Momjian.

Khả năng tương thích

Theo AWS, Aurora PostgreSQL là bản thay thế cho PostgreSQL và tài liệu cho biết:

Mã, công cụ và ứng dụng bạn sử dụng ngày nay với cơ sở dữ liệu MySQL và PostgreSQL hiện có của bạn có thể được sử dụng với Aurora.

Điều đó được củng cố bởi Câu hỏi thường gặp về Aurora:

Điều đó có nghĩa là hầu hết các mã, ứng dụng, trình điều khiển và công cụ bạn đã sử dụng ngày nay với cơ sở dữ liệu PostgreSQL của mình đều có thể được sử dụng với Aurora mà không có hoặc ít thay đổi. Công cụ cơ sở dữ liệu Amazon Aurora được thiết kế để tương thích với PostgreSQL 9.6 và 10, đồng thời hỗ trợ cùng một tập hợp các phần mở rộng PostgreSQL được hỗ trợ với RDS cho PostgreSQL 9.6 và 10, giúp dễ dàng di chuyển các ứng dụng giữa hai công cụ.

"Hầu hết" trong văn bản trên gợi ý rằng không có đảm bảo 100% trong trường hợp đó những người đang tìm kiếm sự chắc chắn nên cân nhắc mua hỗ trợ kỹ thuật từ AWS Professional Services hoặc các đối tác của Aamazon Aurora. Lưu ý thêm, tôi nhận thấy rằng không có Nhà cung cấp dịch vụ lưu trữ chuyên nghiệp PostgreSQL nào sử dụng cộng tác viên cốt lõi của cộng đồng nằm trong danh sách đó.

Từ trang Câu hỏi thường gặp của Aurora, chúng tôi cũng biết rằng Aurora PostgreSQL hỗ trợ các tiện ích mở rộng tương tự như RDS, từ đó liệt kê hầu hết các tiện ích mở rộng cộng đồng và một số tiện ích bổ sung.

Các khái niệm

Là một phần của Amazon RDS, Aurora PostgreSQL đi kèm với thuật ngữ riêng:

  • Cluster:Một phiên bản DB chính ở chế độ đọc / ghi và không hoặc nhiều hơn các Bản sao Aurora. DB chính thường được gắn nhãn là Master trong `AWS maps`_ hoặc Writer trong AWS Console. Dựa trên sơ đồ tham khảo, chúng ta có thể đưa ra một quan sát thú vị:Aurora viết ba lần. Vì độ trễ giữa các AZ thường cao hơn trong cùng AZ, giao dịch được coi là cam kết ngay khi được ghi trên bản sao dữ liệu trong cùng AZ, nếu không, độ trễ và khả năng ngừng hoạt động giữa các AZ.
  • Khối lượng Cụm:Khối lượng lưu trữ cơ sở dữ liệu ảo trải dài nhiều AZ.
  • URL Aurora:Cặp `host:port`.
  • Điểm cuối của cụm:URL Aurora cho DB chính. Có một Điểm cuối cụm.
  • Điểm cuối của trình đọc:URL Aurora cho tập hợp bản sao. Để tương tự với DNS, đó là một bí danh (CNAME). Yêu cầu đọc được cân bằng tải giữa các bản sao có sẵn.
  • Điểm cuối tùy chỉnh:Aurora URL tới một nhóm bao gồm một hoặc nhiều phiên bản DB.
  • Điểm cuối phiên bản:URL Aurora tới một phiên bản DB cụ thể.
  • Phiên bản Aurora:Phiên bản sản phẩm được trả về bởi `SELECT AURORA_VERSION ();`.

Hiệu suất và Giám sát PostgreSQL trên AWS Aurora

Định cỡ

Aurora PostgreSQL áp dụng cấu hình phỏng đoán tốt nhất dựa trên kích thước phiên bản DB và dung lượng lưu trữ, để điều chỉnh thêm cho DBA thông qua việc sử dụng các nhóm tham số DB.

Khi chọn phiên bản DB, hãy căn cứ lựa chọn của bạn vào giá trị mong muốn cho max_connections.

Chia tỷ lệ

Aurora PostgreSQL có tính năng mở rộng quy mô tự động và thủ công. Việc mở rộng quy mô theo chiều ngang của các bản sao đã đọc được tự động hóa thông qua việc sử dụng các chỉ số hiệu suất. Chia tỷ lệ theo chiều dọc có thể được tự động hóa thông qua các API.

Chia tỷ lệ ngang diễn ra ngoại tuyến trong vài phút trong khi thay thế công cụ máy tính và thực hiện bất kỳ hoạt động bảo trì nào (nâng cấp, vá lỗi). Do đó, AWS khuyên bạn nên thực hiện các thao tác như vậy trong thời gian bảo trì.

Mở rộng theo cả hai hướng thật dễ dàng:

Chia tỷ lệ dọc:sửa đổi lớp cá thể Chia tỷ lệ ngang:thêm bản sao trình đọc.

Ở cấp bộ nhớ, dung lượng được thêm vào với gia số 10G. Bộ nhớ đã phân bổ không bao giờ bị đòi lại, hãy xem bên dưới để biết cách giải quyết hạn chế này.

Bộ nhớ

Như đã đề cập ở trên, Aurora PostgreSQL được thiết kế để tận dụng các túc số nhằm cải thiện tính nhất quán của hiệu suất.

Vì bộ nhớ cơ bản được chia sẻ bởi tất cả các phiên bản DB trong cùng một cụm, nên không cần ghi bổ sung trên các nút dự phòng. Ngoài ra, việc thêm hoặc xóa các phiên bản DB không thay đổi dữ liệu cơ bản.

Tự hỏi những IO đó là gì đơn vị có nghĩa là trên hóa đơn hàng tháng? Câu hỏi thường gặp về Aurora lại được giải thích để giải thích thế nào là IO là, trong bối cảnh giám sát và thanh toán. IO đọc tương đương với đọc trang cơ sở dữ liệu 8KiB và IO ghi tương đương với 4KiB được ghi vào lớp lưu trữ.

Đồng tiền cao

Để tận dụng tối đa thiết kế đồng thời cao của Aurora, bạn nên định cấu hình các ứng dụng để thúc đẩy một số lượng lớn các truy vấn và giao dịch đồng thời.

Các ứng dụng được thiết kế để hướng các truy vấn đọc và ghi tới các nút cơ sở dữ liệu chính và dự phòng tương ứng sẽ được hưởng lợi từ điểm cuối bản sao trình đọc Aurora PostgreSQL.

Các kết nối được cân bằng tải giữa các bản sao đã đọc.

Sử dụng các phiên bản cơ sở dữ liệu điểm cuối tùy chỉnh có nhiều dung lượng hơn có thể được nhóm lại với nhau để chạy khối lượng công việc chuyên sâu như phân tích.

Điểm cuối phiên bản DB có thể được sử dụng để cân bằng tải chi tiết hoặc chuyển đổi dự phòng nhanh.

Lưu ý rằng để Điểm cuối trình đọc cân bằng tải các truy vấn riêng lẻ, mỗi truy vấn phải được gửi dưới dạng một kết nối mới.

Bộ nhớ đệm

Aurora PostgreSQL sử dụng kỹ thuật Làm nóng bộ nhớ cache tồn tại để đảm bảo rằng ngày trong bộ đệm ẩn được lưu giữ, loại bỏ nhu cầu tạo lại hoặc khởi động bộ đệm sau khi khởi động lại cơ sở dữ liệu.

Nhân rộng

Thời gian trễ sao chép giữa các bản sao được giữ trong phần nghìn giây một chữ số. Mặc dù không có sẵn cho PostgreSQL, nhưng thật tốt khi biết rằng độ trễ sao chép giữa các vùng được duy trì trong vòng 10 giây của mili giây.

Theo tài liệu, độ trễ của bản sao tăng lên trong khoảng thời gian yêu cầu ghi nhiều.

Kế hoạch thực thi truy vấn

Dựa trên giả định rằng hiệu suất truy vấn suy giảm theo thời gian do các thay đổi cơ sở dữ liệu khác nhau, vai trò của thành phần Aurora PostgreSQL này là duy trì danh sách các kế hoạch thực thi truy vấn đã được phê duyệt hoặc bị từ chối.

Các kế hoạch được chấp thuận hoặc bị từ chối bằng cách sử dụng phương pháp chủ động hoặc phản ứng.

Khi một kế hoạch thực thi được đánh dấu là bị từ chối, Kế hoạch Thực thi Truy vấn sẽ ghi đè các quyết định của trình tối ưu hóa PostgreSQL và ngăn không cho kế hoạch “xấu” được thực thi.

Tính năng này yêu cầu Aurora 2.1.0 trở lên.

Tính khả dụng và nhân rộng cao của PostgreSQL trên AWS Aurora

Ở lớp lưu trữ, Aurora PostgreSQL đảm bảo độ bền bằng cách sao chép mỗi 10GB dung lượng lưu trữ, sáu lần trên 3 AZ (mỗi vùng thường bao gồm 3 AZ) bằng cách sử dụng sao chép đồng bộ vật lý. Điều đó làm cho việc ghi cơ sở dữ liệu có thể tiếp tục hoạt động ngay cả khi 2 bản sao dữ liệu bị mất. Tính khả dụng của tính năng đọc vẫn tồn tại khi mất 3 bản sao dữ liệu.

Đọc các bản sao đảm bảo rằng một bản sao chính bị lỗi có thể nhanh chóng được thay thế bằng cách quảng bá một trong 15 bản sao có sẵn. Khi chọn một triển khai nhiều AZ, một bản sao đọc sẽ tự động được tạo. Chuyển đổi dự phòng không yêu cầu người dùng can thiệp và các hoạt động cơ sở dữ liệu sẽ tiếp tục sau chưa đầy 30 giây.

Đối với triển khai đơn AZ, quy trình khôi phục bao gồm khôi phục từ bản sao lưu tốt đã biết gần đây nhất. Theo Aurora FAQs, quá trình hoàn tất trong vòng chưa đầy 15 phút nếu cơ sở dữ liệu cần được khôi phục ở một AZ khác. Tài liệu không cụ thể như vậy, cho rằng chỉ mất chưa đến 10 phút để hoàn tất quá trình khôi phục.

Không cần thay đổi ở phía ứng dụng để kết nối với phiên bản DB mới vì điểm cuối cụm không thay đổi trong quá trình quảng bá bản sao hoặc khôi phục phiên bản.

Bước 1:xóa phiên bản chính để buộc chuyển đổi dự phòng:

Tự động chuyển đổi dự phòng Bước 1:xóa chính

Bước 2:hoàn thành chuyển đổi dự phòng tự động

Tự động chuyển đổi dự phòng Bước 2:hoàn tất chuyển đổi dự phòng.

Đối với cơ sở dữ liệu bận, thời gian khôi phục sau khi khởi động lại hoặc gặp sự cố giảm đáng kể vì Aurora PostgreSQL không cần phát lại nhật ký giao dịch.

Là một phần của dịch vụ được quản lý đầy đủ, các khối và đĩa dữ liệu không hợp lệ sẽ tự động được thay thế.

Quá trình chuyển đổi dự phòng khi bản sao tồn tại mất tới 120 giây với thời gian thường là dưới 60 giây. Thời gian khôi phục nhanh hơn có thể đạt được khi các điều kiện chuyển đổi dự phòng được xác định trước, trong trường hợp đó, các bản sao có thể được chỉ định các ưu tiên chuyển đổi dự phòng.

Aurora PostgreSQL chơi tốt với Amazon RDS - một phiên bản Aurora có thể hoạt động như một bản sao đọc cho một phiên bản RDS chính.

Aurora PostgreSQL hỗ trợ Logical Replication, giống như trong phiên bản cộng đồng, có thể được sử dụng để khắc phục các hạn chế sao chép tích hợp sẵn. Không có tự động hóa hoặc giao diện bảng điều khiển AWS.

Bảo mật cho PostgreSQL trên AWS Aurora

Ở cấp độ mạng, Aurora PostgreSQL tận dụng các thành phần cốt lõi của AWS, VPC để cách ly mạng đám mây và Nhóm bảo mật để kiểm soát truy cập mạng.

Không có quyền truy cập siêu người dùng. Khi tạo một cụm, Aurora PostgreSQL tạo một tài khoản chính với một tập hợp con các quyền siêu người dùng:

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

Để bảo mật dữ liệu khi truyền, Aurora PostgreSQL cung cấp hỗ trợ SSL / TLS gốc có thể được định cấu hình cho mỗi phiên bản DB.

Tất cả dữ liệu ở trạng thái nghỉ có thể được mã hóa với tác động hiệu suất tối thiểu. Điều này cũng áp dụng cho các bản sao lưu, ảnh chụp nhanh và bản sao.

Mã hóa ở trạng thái nghỉ.

Việc xác thực được kiểm soát bởi các chính sách IAM và việc gắn thẻ cho phép kiểm soát thêm những gì người dùng được phép làm và những tài nguyên nào.

Các lệnh gọi API được sử dụng bởi tất cả các dịch vụ đám mây được đăng nhập vào CloudTrail.

Quản lý mật khẩu hạn chế phía máy khách khả dụng thông qua tham số rds.restrict_password_commands.

Sao lưu và phục hồi PostgreSQL trên AWS Aurora

Sao lưu được bật theo mặc định và không thể tắt. Họ cung cấp khả năng khôi phục tại điểm trong thời gian sử dụng ảnh chụp nhanh đầy đủ hàng ngày làm bản sao lưu cơ sở.

Khôi phục từ bản sao lưu tự động có một số nhược điểm:thời gian khôi phục có thể kéo dài vài giờ và mất dữ liệu có thể lên đến 5 phút trước khi ngừng hoạt động. Triển khai Amazon RDS Multi-AZ giải quyết vấn đề này bằng cách quảng bá bản sao đã đọc thành bản chính, không mất dữ liệu.

Ảnh chụp nhanh cơ sở dữ liệu nhanh chóng và không ảnh hưởng đến hiệu suất của cụm. Chúng có thể được sao chép hoặc chia sẻ với những người dùng khác.

Chụp nhanh gần như ngay lập tức:

Thời gian chụp nhanh.

Việc khôi phục ảnh chụp nhanh cũng nhanh chóng. So sánh với PITR:

Các bản sao lưu và ảnh chụp nhanh được lưu trữ trong S3, mang đến độ bền 11 9.

Ngoài các bản sao lưu và ảnh chụp nhanh, Aurora PostgreSQL cho phép nhân bản cơ sở dữ liệu. Đây là một phương pháp hiệu quả để tạo bản sao của các tập dữ liệu lớn. Ví dụ:sao chép nhiều terabyte dữ liệu chỉ mất vài phút và không ảnh hưởng đến hiệu suất.

Aurora PostgreSQL - Bản trình diễn khôi phục điểm trong thời gian

Kết nối với cụm:

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Điền vào bảng với dữ liệu:

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

Bắt đầu khôi phục:

Point-in-Time Recovery:bắt đầu khôi phục.

Sau khi quá trình khôi phục hoàn tất, hãy đăng nhập và kiểm tra:

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

Các phương pháp hay nhất

Giám sát và Kiểm toán

  • Tích hợp các luồng hoạt động của cơ sở dữ liệu với sự giám sát của bên thứ ba để giám sát hoạt động của cơ sở dữ liệu đối với các yêu cầu tuân thủ và quy định.
  • Dịch vụ cơ sở dữ liệu được quản lý đầy đủ không có nghĩa là thiếu trách nhiệm - xác định các chỉ số để giám sát CPU, RAM, Dung lượng đĩa, Mạng và Kết nối cơ sở dữ liệu.
  • Aurora PostgreSQL tích hợp với công cụ giám sát tiêu chuẩn AWS CloudWatch, cũng như cung cấp các màn hình bổ sung cho Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication và cả cho RDS Metrics có thể được nhóm thêm theo Thứ nguyên RDS.
  • Theo dõi mức tải trung bình của các phiên hoạt động trong cơ sở dữ liệu bằng cách Chờ các dấu hiệu của kết nối trên đầu, các truy vấn SQL cần điều chỉnh, tranh chấp tài nguyên hoặc một lớp cá thể DB nhỏ hơn.
  • Thiết lập Thông báo Sự kiện.
  • Định cấu hình các thông số nhật ký lỗi.
  • Theo dõi các thay đổi cấu hình đối với các thành phần cụm cơ sở dữ liệu:phiên bản, nhóm mạng con, ảnh chụp nhanh, nhóm bảo mật.

Nhân rộng

  • Sử dụng phân vùng bảng gốc cho khối lượng công việc vượt quá khả năng lưu trữ và lớp phiên bản DB tối đa

Mã hóa

  • Cơ sở dữ liệu được mã hóa phải bật tính năng sao lưu để đảm bảo dữ liệu có thể được khôi phục trong trường hợp khóa mã hóa bị thu hồi.

Tài khoản Chính

  • Không sử dụng psql để thay đổi mật khẩu người dùng chính.

Định cỡ

  • Cân nhắc sử dụng các lớp đối tượng khác nhau trong một cụm để giảm chi phí.

Nhóm tham số

  • Tinh chỉnh bằng cách sử dụng Nhóm tham số để tiết kiệm $$$.

Bản trình diễn nhóm tham số

Cài đặt hiện tại:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

Tạo một nhóm thông số mới và đặt giá trị rộng cho cụm mới:

Đang cập nhật trên toàn bộ cụm shared_buffers.

Liên kết nhóm thông số tùy chỉnh với cụm:

Khởi động lại trình viết và kiểm tra giá trị:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)
  • Đặt múi giờ địa phương

Theo mặc định, múi giờ là UTC:

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

Đặt múi giờ mới:

Định cấu hình múi giờ

Và sau đó kiểm tra:

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Lưu ý rằng danh sách các giá trị múi giờ được Amazon Aurora chấp nhận không phải là tập hợp múi giờ được tìm thấy trong PostgreSQL ngược dòng.

  • Xem lại các tham số bản sao bị ghi đè bởi các tham số cụm
  • Sử dụng công cụ so sánh nhóm thông số.

Ảnh chụp nhanh

  • Tránh tính phí bộ nhớ bổ sung bằng cách chia sẻ ảnh chụp nhanh với tài khoản khác để cho phép khôi phục vào môi trường tương ứng của họ.

Bảo trì

  • Thay đổi thời lượng bảo trì mặc định theo lịch trình của tổ chức.

Chuyển đổi dự phòng

  • Cải thiện thời gian khôi phục bằng cách định cấu hình Quản lý bộ nhớ cache theo cụm.
  • Giảm các giá trị lưu giữ TCP của hạt nhân trên máy khách và định cấu hình bộ đệm DNS của ứng dụng và TTL cũng như các chuỗi kết nối PostgreSQL.

Hãy coi chừng DBA!

Ngoài những hạn chế đã biết, hãy tránh hoặc lưu ý những điều sau:

Mã hóa

  • Khi cơ sở dữ liệu đã được tạo, không thể thay đổi trạng thái mã hóa.

Aurora Serverless

  • Tại thời điểm này, phiên bản PostgreSQL của Aurora Serverless chỉ có sẵn trong bản xem trước hạn chế.

Truy vấn song song

  • Amazon Parallel Query không khả dụng, mặc dù tính năng có cùng tên đã có từ PostgreSQL 9.6.

Điểm cuối

Từ Quản lý kết nối Amazon:

  • 5 Điểm cuối tùy chỉnh trên mỗi cụm
  • Tên Điểm cuối tùy chỉnh không được vượt quá 63 ký tự
  • Tên Điểm cuối của cụm là duy nhất trong cùng một khu vực
  • Như đã thấy trong ảnh chụp màn hình ở trên (cực quang-tùy chỉnh-điểm cuối-chi tiết) READER và BẤT KỲ loại điểm cuối tùy chỉnh nào không khả dụng, hãy sử dụng CLI
  • Điểm cuối tùy chỉnh không biết về việc các bản sao tạm thời không khả dụng

Nhân rộng

  • Khi quảng cáo Bản sao lên Chính, các kết nối qua Điểm cuối của người đọc có thể tiếp tục được chuyển hướng trong một thời gian ngắn tới Bản sao đã quảng cáo.
  • Bản sao giữa các vùng không được hỗ trợ
  • Mặc dù được phát hành vào cuối tháng 11 năm 2017, nhưng bản xem trước Amazon Aurora Multi-Master vẫn không khả dụng cho PostgreSQL
  • Đề phòng sự suy giảm hiệu suất khi tính năng sao chép lôgic được bật trên cụm.
  • Bản sao lôgic yêu cầu một công cụ PostgreSQL đang chạy đã xuất bản 10.6 trở lên.

Bộ nhớ

  • Bộ nhớ được phân bổ tối đa không bị thu hẹp khi dữ liệu bị xóa, không gian được lấy lại bằng cách khôi phục từ ảnh chụp nhanh. Cách duy nhất để lấy lại không gian là thực hiện kết xuất hợp lý vào một cụm mới.

Sao lưu và phục hồi

  • Khả năng lưu giữ các bản sao lưu không được kéo dài trong khi dừng cụm.
  • Khoảng thời gian lưu giữ tối đa là 35 ngày - sử dụng ảnh chụp nhanh thủ công để có thời gian lưu giữ lâu hơn.
  • khôi phục tại điểm trong thời gian khôi phục thành một cụm DB mới.
  • thời gian đọc bị gián đoạn ngắn trong quá trình chuyển đổi dự phòng sang bản sao.
  • Các kịch bản Khôi phục sau thảm họa không khả dụng giữa các khu vực.

Ảnh chụp nhanh

  • Việc khôi phục từ ảnh chụp nhanh sẽ tạo ra một điểm cuối mới (chỉ có thể khôi phục ảnh chụp nhanh vào một cụm mới).
  • Sau khi khôi phục ảnh chụp nhanh, các điểm cuối tùy chỉnh phải được tạo lại.
  • Việc khôi phục từ ảnh chụp nhanh sẽ đặt lại múi giờ địa phương thành UTC.
  • Khôi phục từ ảnh chụp nhanh không bảo toàn các nhóm bảo mật tùy chỉnh.
  • Có thể chia sẻ ảnh chụp nhanh với tối đa 20 ID tài khoản AWS.
  • Không thể chia sẻ ảnh chụp nhanh giữa các vùng.
  • Ảnh chụp nhanh gia tăng luôn được sao chép dưới dạng ảnh chụp nhanh đầy đủ, giữa các vùng và trong cùng một vùng.
  • Việc sao chép ảnh chụp nhanh giữa các vùng không bảo toàn các nhóm thông số không phải mặc định.

Thanh toán

  • Hóa đơn 10 phút áp dụng cho các phiên bản mới cũng như sau khi thay đổi dung lượng (máy tính hoặc bộ nhớ).

Xác thực

  • Việc sử dụng xác thực cơ sở dữ liệu IAM đặt ra giới hạn về số lượng kết nối mỗi giây.
  • Tài khoản chính đã bị thu hồi một số đặc quyền của người dùng cấp cao nhất định.

Bắt đầu và Dừng

Từ Tổng quan về việc dừng và nhìn chằm chằm vào một cụm Aurora DB:

  • Không thể dừng các nhóm vô thời hạn vì chúng được bắt đầu tự động sau 7 ngày.
  • Không thể dừng các phiên bản DB riêng lẻ.

Nâng cấp

  • Nâng cấp phiên bản chính tại chỗ không được hỗ trợ.
  • Các thay đổi nhóm tham số cho cả phiên bản DB và cụm DB mất ít nhất 5 phút để phổ biến.

Nhân bản

  • 15 bản sao cho mỗi cơ sở dữ liệu (bản gốc hoặc bản sao).
  • Các bản sao không bị xóa khi xóa cơ sở dữ liệu nguồn.

Chia tỷ lệ

  • Tự động mở rộng quy mô yêu cầu rằng tất cả các bản sao đều có sẵn.
  • Chỉ có thể có một `` chính sách điều chỉnh tỷ lệ tự động`_ cho mỗi số liệu trên mỗi cụm.
  • Việc chia tỷ lệ theo chiều ngang của cá thể DB chính (lớp cá thể) không hoàn toàn tự động. Trước khi mở rộng quy mô, cụm sẽ kích hoạt chuyển đổi dự phòng tự động sang một trong các bản sao. Sau khi hoàn thành việc chia tỷ lệ, phiên bản mới phải được thăng cấp theo cách thủ công từ người đọc sang người viết: Phiên bản mới vẫn ở chế độ đọc sau khi thay đổi lớp cá thể DB.

Giám sát

  • Việc xuất bản nhật ký PostgreSQL lên CloudWatch yêu cầu phiên bản công cụ cơ sở dữ liệu tối thiểu là 9.6.6 và 10.4.
  • Chỉ một số chỉ số Aurora có sẵn trong Bảng điều khiển RDS và các chỉ số khác có tên và đơn vị đo lường khác nhau.
  • Theo mặc định, nhật ký Giám sát nâng cao được lưu trong CloudWatch trong 30 ngày.
  • Các chỉ số của Cloudwatch và Giám sát nâng cao sẽ khác nhau, vì chúng thu thập dữ liệu từ trình siêu giám sát và tương ứng với tác nhân đang chạy trên phiên bản đó.
  • Thông tin chi tiết về hiệu suất_ tổng hợp các chỉ số trên tất cả các cơ sở dữ liệu trong Phiên bản DB.
  • Các câu lệnh SQL được giới hạn trong 500 ký tự khi được xem bằng AWS Performance Insights CLI và API.

Di chuyển

  • Chỉ có thể mã hóa ảnh chụp nhanh DB không được mã hóa RDS.
  • Quá trình di chuyển bằng kỹ thuật Aurora Read Replica mất vài giờ mỗi TiB.

Định cỡ

  • Lớp cá thể nhỏ nhất có sẵn là db.t3.medium và db.r5.24xlarge lớn nhất. Để so sánh, MySQL engine cung cấp db.t2.small và db.t2.medium, tuy nhiên không có db.r5.24xlarge trong phạm vi phía trên.
  • Giới hạn trên của
  • max_connections là 262.143.

Quản lý kế hoạch truy vấn

  • Các câu lệnh bên trong các hàm PL / pgSQL không được hỗ trợ.

Di chuyển

Aurora PostgreSQL không cung cấp các dịch vụ di chuyển trực tiếp, thay vào đó, nhiệm vụ được giảm tải cho một sản phẩm AWS chuyên biệt, cụ thể là AWS DMS.

Kết luận

Là một sự thay thế thả vào được quản lý hoàn toàn cho PostgreSQL ngược dòng, Amazon Aurora PostgreSQL tận dụng các công nghệ cung cấp năng lượng cho đám mây AWS để loại bỏ sự phức tạp cần thiết để thiết lập các dịch vụ như tự động mở rộng quy mô, cân bằng tải truy vấn, dữ liệu cấp thấp sao chép, sao lưu gia tăng và mã hóa.

Kiến trúc và cách tiếp cận thận trọng để nâng cấp công cụ PostgreSQL cung cấp hiệu suất và các tổ chức ổn định từ nhỏ đến lớn đang tìm kiếm.

Những hạn chế cố hữu chỉ là bằng chứng cho thấy việc xây dựng Cơ sở dữ liệu quy mô lớn dưới dạng Dịch vụ là một nhiệm vụ phức tạp, khiến các Nhà cung cấp dịch vụ lưu trữ PostgreSQL chuyên môn cao có được một thị trường thích hợp mà họ có thể khai thác.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Thêm tháng vào một ngày trong PostgreSQL

  2. hasMany được gọi với một cái gì đó không phải là một phiên bản của Sequelize.Model

  3. Làm sắc nét dữ liệu của bạn với PostgreSQL 11

  4. Làm cách nào để chọn id với nhóm ngày tối đa theo danh mục trong PostgreSQL?

  5. Cách nhập tệp CSV trong PostgreSQL