Penyelaman Mendalam Vendor Cloud:PostgreSQL di AWS Aurora

Seberapa dalam kita harus pergi dengan ini? Saya akan mulai dengan mengatakan bahwa pada tulisan ini, saya hanya dapat menemukan 3 buku di Amazon tentang PostgreSQL di cloud, dan 117 diskusi di milis PostgreSQL tentang Aurora PostgreSQL. Itu tidak terlihat banyak, dan itu membuat saya, pengguna akhir PostgreSQL yang penasaran, dengan dokumentasi resmi sebagai satu-satunya tempat di mana saya benar-benar dapat belajar lebih banyak lagi. Karena saya tidak memiliki kemampuan, atau pengetahuan untuk berpetualang lebih dalam, ada AWS re:Invent 2018 untuk mereka yang mencari sensasi semacam itu. Saya dapat menerima artikel Werner tentang kuorum.

Untuk pemanasan, saya mulai dari beranda Aurora PostgreSQL di mana saya mencatat bahwa tolok ukur yang menunjukkan bahwa Aurora PostgreSQL tiga kali lebih cepat daripada PostgreSQL standar yang berjalan pada perangkat keras yang sama sejak PostgreSQL 9.6. Seperti yang saya pelajari nanti, 9.6.9 saat ini merupakan opsi default saat menyiapkan cluster baru. Itu adalah kabar baik bagi mereka yang tidak ingin, atau tidak dapat segera mengupgrade. Dan mengapa ketersediaan hanya 99,99%? Satu penjelasan dapat ditemukan di artikel Bruce Momjian.

Kompatibilitas

Menurut AWS, Aurora PostgreSQL adalah pengganti drop-in untuk PostgreSQL, dan dokumentasinya menyatakan:

Kode, alat, dan aplikasi yang Anda gunakan saat ini dengan database MySQL dan PostgreSQL yang ada dapat digunakan dengan Aurora.

Hal itu diperkuat oleh FAQ Aurora:

Ini berarti bahwa sebagian besar kode, aplikasi, driver, dan alat yang sudah Anda gunakan saat ini dengan database PostgreSQL Anda dapat digunakan dengan Aurora dengan sedikit atau tanpa perubahan. Mesin database Amazon Aurora dirancang agar kompatibel dengan PostgreSQL 9.6 dan 10, dan mendukung kumpulan ekstensi PostgreSQL yang sama yang didukung dengan RDS untuk PostgreSQL 9.6 dan 10, sehingga memudahkan untuk memindahkan aplikasi di antara kedua mesin.

“sebagian besar” dalam teks di atas menunjukkan bahwa tidak ada jaminan 100% dalam hal ini mereka yang mencari kepastian harus mempertimbangkan untuk membeli dukungan teknis baik dari AWS Professional Services, atau mitra Aamazon Aurora. Sebagai catatan tambahan, saya memperhatikan bahwa tidak ada Penyedia Hosting profesional PostgreSQL yang mempekerjakan kontributor komunitas inti ada dalam daftar itu.

Dari halaman FAQ Aurora, kami juga mengetahui bahwa Aurora PostgreSQL mendukung ekstensi yang sama seperti RDS, yang pada gilirannya mencantumkan sebagian besar ekstensi komunitas dan beberapa tambahan.

Konsep

Sebagai bagian dari Amazon RDS, Aurora PostgreSQL hadir dengan terminologinya sendiri:

Cluster:Instans DB Primer dalam mode baca/tulis dan nol atau lebih Replika Aurora. DB utama sering diberi label Master di `AWS diagram`_, atau Writer di AWS Console. Berdasarkan diagram referensi kita dapat membuat pengamatan yang menarik:Aurora menulis tiga kali. Karena latensi antara AZ biasanya lebih tinggi daripada dalam AZ yang sama, transaksi dianggap berkomitmen segera setelah ditulis pada salinan data dalam AZ yang sama, jika tidak, latensi dan potensi pemadaman antara AZ.
Volume Cluster:Volume penyimpanan database virtual yang mencakup beberapa AZ.
URL Aurora:Pasangan `host:port`.
Titik Akhir Cluster:URL Aurora untuk DB Utama. Ada satu Titik Akhir Cluster.
Titik Akhir Pembaca:URL Aurora untuk kumpulan replika. Untuk membuat analogi dengan DNS itu adalah alias (CNAME). Permintaan baca adalah beban seimbang antara replika yang tersedia.
Titik Akhir Kustom:URL Aurora ke grup yang terdiri dari satu atau beberapa instans DB.
Titik Akhir Instance:URL Aurora ke instans DB tertentu.
Versi Aurora:Versi produk yang dikembalikan oleh `SELECT AURORA_VERSION();`.

Kinerja dan Pemantauan PostgreSQL di AWS Aurora

Ukuran

Aurora PostgreSQL menerapkan konfigurasi tebakan terbaik yang didasarkan pada ukuran instans DB dan kapasitas penyimpanan, meninggalkan penyesuaian lebih lanjut ke DBA melalui penggunaan grup Parameter DB.

Saat memilih instans DB, dasarkan pilihan Anda pada nilai yang diinginkan untuk max_connections.

Penskalaan

Aurora PostgreSQL memiliki fitur penskalaan otomatis dan manual. Penskalaan horizontal replika baca diotomatiskan melalui penggunaan metrik kinerja. Penskalaan vertikal dapat diotomatisasi melalui API.

Penskalaan horizontal membutuhkan offline selama beberapa menit saat mengganti mesin komputasi dan melakukan operasi pemeliharaan apa pun (peningkatan versi, penambalan). Oleh karena itu, AWS merekomendasikan untuk melakukan operasi tersebut selama periode pemeliharaan.

Penskalaan di kedua arah sangat mudah:

Penskalaan vertikal:memodifikasi kelas instance

Penskalaan horizontal:menambahkan replika pembaca.

Pada tingkat penyimpanan, ruang ditambahkan secara bertahap 10G. Penyimpanan yang dialokasikan tidak pernah diklaim kembali, lihat di bawah untuk mengetahui cara mengatasi batasan ini.

Penyimpanan

Seperti disebutkan di atas, Aurora PostgreSQL dirancang untuk memanfaatkan kuorum guna meningkatkan konsistensi kinerja.

Karena penyimpanan dasar digunakan bersama oleh semua instans DB dalam cluster yang sama, tidak diperlukan penulisan tambahan pada node siaga. Selain itu, menambahkan atau menghapus instans DB tidak mengubah data yang mendasarinya.

Ingin tahu apa itu IO unit berarti pada tagihan bulanan? FAQ Aurora datang untuk menyelamatkan lagi untuk menjelaskan apa itu IO adalah, dalam konteks pemantauan dan penagihan. A Read IO setara dengan pembacaan halaman database 8KiB, dan Write IO setara dengan 4KiB yang ditulis ke lapisan penyimpanan.

Konkurensi Tinggi

Untuk memanfaatkan sepenuhnya desain konkurensi tinggi Aurora, direkomendasikan agar aplikasi dikonfigurasikan untuk mendorong sejumlah besar kueri dan transaksi bersamaan.

Aplikasi yang dirancang untuk mengarahkan kueri baca dan tulis ke node database utama dan siaga masing-masing akan mendapat manfaat dari titik akhir replika pembaca Aurora PostgreSQL.

Koneksi adalah beban seimbang antara replika baca.

Menggunakan instans database titik akhir kustom dengan kapasitas lebih dapat dikelompokkan bersama untuk menjalankan beban kerja intensif seperti analitik.

Titik Akhir Instans DB dapat digunakan untuk penyeimbangan beban yang detail atau failover yang cepat.

Perhatikan bahwa agar Titik Akhir Pembaca memuat kueri individual yang seimbang, setiap kueri harus dikirim sebagai koneksi baru.

Menyimpan cache

Aurora PostgreSQL menggunakan teknik Survivable Cache Warming yang memastikan bahwa tanggal dalam buffer cache dipertahankan, menghilangkan kebutuhan untuk mengisi ulang atau menghangatkan cache setelah database dimulai ulang.

Replikasi

Replikasi jeda waktu antara replika disimpan dalam milidetik satu digit. Meskipun tidak tersedia untuk PostgreSQL, ada baiknya mengetahui bahwa jeda replikasi lintas wilayah dipertahankan dalam 10 detik milidetik.

Menurut dokumentasi, replika lag meningkat selama periode permintaan tulis yang berat.

Rencana Eksekusi Kueri

Berdasarkan asumsi bahwa kinerja kueri menurun seiring waktu karena berbagai perubahan basis data, peran komponen Aurora PostgreSQL ini adalah untuk mempertahankan daftar rencana eksekusi kueri yang disetujui atau ditolak.

Rencana disetujui atau ditolak menggunakan metode proaktif atau reaktif.

Saat rencana eksekusi ditandai sebagai ditolak, Rencana Eksekusi Kueri menimpa keputusan pengoptimal PostgreSQL dan mencegah rencana "buruk" untuk dieksekusi.

Fitur ini membutuhkan Aurora 2.1.0 atau lebih baru.

Replikasi dan Ketersediaan Tinggi PostgreSQL di AWS Aurora

Di lapisan penyimpanan, Aurora PostgreSQL memastikan ketahanan dengan mereplikasi setiap 10 GB volume penyimpanan, enam kali di 3 AZ (setiap wilayah biasanya terdiri dari 3 AZ) menggunakan replikasi sinkron fisik. Itu memungkinkan penulisan basis data untuk terus bekerja bahkan ketika 2 salinan data hilang. Ketersediaan baca bertahan dari hilangnya 3 salinan data.

Replika baca memastikan bahwa instans utama yang gagal dapat diganti dengan cepat dengan mempromosikan salah satu dari 15 replika yang tersedia. Saat memilih penerapan multi-AZ, satu replika baca dibuat secara otomatis. Failover tidak memerlukan intervensi pengguna, dan operasi database dilanjutkan dalam waktu kurang dari 30 detik.

Untuk penerapan AZ tunggal, prosedur pemulihan mencakup pemulihan dari cadangan baik terakhir yang diketahui. Menurut FAQ Aurora, proses selesai dalam waktu kurang dari 15 menit jika database perlu dipulihkan di AZ yang berbeda. Dokumentasinya tidak terlalu spesifik, mengklaim bahwa dibutuhkan waktu kurang dari 10 menit untuk menyelesaikan proses pemulihan.

Tidak ada perubahan yang diperlukan di sisi aplikasi untuk terhubung ke instans DB baru karena titik akhir klaster tidak berubah selama promosi replika atau pemulihan instans.

Langkah 1:hapus instance utama untuk memaksa failover:

Kegagalan otomatis Langkah 1:hapus primer

Langkah 2:failover otomatis selesai

Failover otomatis Langkah 2:failover selesai.

Untuk database yang sibuk, waktu pemulihan setelah restart atau crash berkurang drastis karena Aurora PostgreSQL tidak perlu memutar ulang log transaksi.

Sebagai bagian dari layanan terkelola penuh, blok data dan disk yang buruk akan otomatis diganti.

Failover ketika replika ada membutuhkan waktu hingga 120 detik dengan waktu sering di bawah 60 detik. Waktu pemulihan yang lebih cepat dapat dicapai jika kondisi failover telah ditentukan sebelumnya, dalam hal ini replika dapat diberi prioritas failover.

Aurora PostgreSQL berfungsi dengan baik dengan Amazon RDS – instans Aurora dapat bertindak sebagai replika baca untuk instans RDS utama.

Aurora PostgreSQL mendukung Replikasi Logis yang, seperti dalam versi komunitas, dapat digunakan untuk mengatasi keterbatasan replikasi bawaan. Tidak ada otomatisasi atau antarmuka konsol AWS.

Keamanan untuk PostgreSQL di AWS Aurora

Di tingkat jaringan, Aurora PostgreSQL memanfaatkan komponen inti AWS, VPC untuk isolasi jaringan cloud, dan Grup Keamanan untuk kontrol akses jaringan.

Tidak ada akses pengguna super. Saat membuat cluster, Aurora PostgreSQL membuat akun master dengan subset izin pengguna super:

[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  |                 |

Untuk mengamankan data saat transit, Aurora PostgreSQL menyediakan dukungan SSL/TLS asli yang dapat dikonfigurasi per instans DB.

Semua data saat istirahat dapat dienkripsi dengan dampak kinerja minimal. Ini juga berlaku untuk pencadangan, snapshot, dan replika.

Enkripsi saat istirahat.

Otentikasi dikendalikan oleh kebijakan IAM, dan pemberian tag memungkinkan kontrol lebih lanjut atas apa yang boleh dilakukan pengguna dan pada sumber daya apa.

Panggilan API yang digunakan oleh semua layanan cloud dicatat di CloudTrail.

Manajemen Kata Sandi Terbatas sisi klien tersedia melalui parameter rds.restrict_password_commands.

Pencadangan dan Pemulihan PostgreSQL di AWS Aurora

Cadangan diaktifkan secara default dan tidak dapat dinonaktifkan. Mereka menyediakan pemulihan point-in-time menggunakan snapshot harian penuh sebagai cadangan dasar.

Memulihkan dari cadangan otomatis memiliki beberapa kelemahan:waktu untuk memulihkan mungkin beberapa jam dan kehilangan data mungkin sampai 5 menit sebelum pemadaman. Penerapan Multi-AZ Amazon RDS memecahkan masalah ini dengan mempromosikan replika baca ke primer, tanpa kehilangan data.

Snapshot Basis Data cepat dan tidak memengaruhi kinerja cluster. Mereka dapat disalin atau dibagikan dengan pengguna lain.

Mengambil snapshot hampir seketika:

Waktu cuplikan.

Memulihkan snapshot juga cepat. Bandingkan dengan PITR:

Cadangan dan snapshot disimpan di S3 yang menawarkan daya tahan sebelas 9.

Selain backup dan snapshot, Aurora PostgreSQL memungkinkan database untuk dikloning. Ini adalah metode yang efisien untuk membuat salinan kumpulan data besar. Misalnya, mengkloning data multi-terabyte hanya membutuhkan waktu beberapa menit dan tidak ada dampak kinerja.

Aurora PostgreSQL - Demo Pemulihan Point-in-Time

Menghubungkan ke kluster:

~ $ 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.

Mengisi tabel dengan data:

[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)

Mulai pemulihan:

Pemulihan Point-in-Time:memulai pemulihan.

Setelah pemulihan selesai, masuk dan periksa:

~ $ 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)

Praktik Terbaik

Pemantauan dan Audit

Mengintegrasikan aliran aktivitas database dengan pemantauan pihak ketiga untuk memantau aktivitas database untuk kepatuhan dan persyaratan peraturan.
Layanan database yang terkelola sepenuhnya tidak berarti kurangnya tanggung jawab — tentukan metrik untuk memantau CPU, RAM, Ruang Disk, Jaringan, dan Koneksi Database.
Aurora PostgreSQL terintegrasi dengan alat pemantauan standar AWS CloudWatch, serta menyediakan monitor tambahan untuk Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication, dan juga untuk Metrik RDS yang dapat dikelompokkan lebih lanjut berdasarkan Dimensi RDS.
Memantau Rata-rata DB Sesi Aktif Dimuat dengan Tunggu tanda-tanda overhead koneksi, kueri SQL yang memerlukan penyetelan, pertentangan sumber daya, atau kelas instans DB berukuran kecil.
Siapkan Notifikasi Acara.
Konfigurasikan parameter log kesalahan.
Pantau perubahan konfigurasi pada komponen cluster database:instance, grup subnet, snapshot, grup keamanan.

Replikasi

Gunakan partisi tabel asli untuk beban kerja yang melebihi kelas instans DB dan kapasitas penyimpanan maksimum

Enkripsi

Database terenkripsi harus memiliki cadangan yang diaktifkan untuk memastikan data dapat dipulihkan jika kunci enkripsi dicabut.

Akun Utama

Jangan gunakan psql untuk mengubah kata sandi pengguna utama.

Ukuran

Pertimbangkan untuk menggunakan kelas instance yang berbeda dalam sebuah cluster untuk mengurangi biaya.

Grup Parameter

Sesuaikan dengan menggunakan Grup Parameter untuk menghemat $$$.

Demo Grup Parameter

Setelan saat ini:

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

Buat grup parameter baru dan atur nilai lebar cluster baru:

Memperbarui cluster shared_buffers secara luas.

Kaitkan grup parameter khusus dengan cluster:

Nyalakan ulang penulis dan periksa nilainya:

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

Setel zona waktu lokal

Secara default, zona waktu dalam UTC:

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

Menyetel zona waktu baru:

Mengonfigurasi zona waktu

Dan kemudian periksa:

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

Perhatikan bahwa daftar nilai zona waktu yang diterima oleh Amazon Aurora bukanlah kumpulan zona waktu yang ditemukan di PostgreSQL upstream.

Tinjau parameter instance yang ditimpa oleh parameter cluster
Gunakan alat perbandingan grup parameter.

Snapshot

Hindari biaya penyimpanan tambahan dengan berbagi snapshot dengan akun lain untuk memungkinkan pemulihan ke lingkungan masing-masing.

Pemeliharaan

Ubah jendela pemeliharaan default sesuai dengan jadwal organisasi.

Kegagalan

Tingkatkan waktu pemulihan dengan mengonfigurasi Cluster Cache Management.
Turunkan nilai kernel TCP keepalive pada klien dan konfigurasikan cache DNS aplikasi dan TTL, dan string koneksi PostgreSQL.

Awas DBA!

Selain batasan yang diketahui, hindari, atau waspadai hal-hal berikut:

Enkripsi

Setelah database dibuat, status enkripsi tidak dapat diubah.

Aurora Tanpa Server

Saat ini, Aurora Serverless versi PostgreSQL hanya tersedia dalam pratinjau terbatas.

Kueri Paralel

Amazon Parallel Query tidak tersedia, meskipun fitur dengan nama yang sama tersedia sejak PostgreSQL 9.6.

Endpoint

Dari Manajemen Koneksi Amazon:

5 Titik Akhir Kustom per cluster
Nama Endpoint Khusus tidak boleh lebih dari 63 karakter
Nama Endpoint Cluster unik dalam region yang sama
Seperti yang terlihat pada tangkapan layar di atas (aurora-custom-endpoint-details) READER dan APAPUN jenis endpoint khusus tidak tersedia, gunakan CLI
Titik Akhir Khusus tidak mengetahui bahwa replika menjadi tidak tersedia untuk sementara

Replikasi

Saat mempromosikan Replika ke Utama, koneksi melalui Titik Akhir Pembaca dapat terus diarahkan untuk sementara waktu ke Replika yang dipromosikan.
Replika lintas wilayah tidak didukung
Saat dirilis pada akhir November 2017, pratinjau Multi-Master Amazon Aurora masih belum tersedia untuk PostgreSQL
Perhatikan penurunan performa saat replikasi logis diaktifkan di cluster.
Replikasi Logis memerlukan mesin PostgreSQL 10.6 yang berjalan dan dipublikasikan atau yang lebih baru.

Penyimpanan

Penyimpanan yang dialokasikan maksimum tidak menyusut saat data dihapus, begitu pula ruang yang diperoleh kembali dengan memulihkan dari snapshot. Satu-satunya cara untuk mendapatkan kembali ruang adalah dengan melakukan dump logis ke dalam cluster baru.

Pencadangan dan Pemulihan

Retensi cadangan tidak diperpanjang saat kluster dihentikan.
Periode retensi maksimum adalah 35 hari — gunakan snapshot manual untuk periode retensi yang lebih lama.
pemulihan point-in-time memulihkan ke cluster DB baru.
gangguan singkat pembacaan selama failover ke replika.
Skenario Pemulihan Bencana tidak tersedia lintas wilayah.

Snapshot

Memulihkan dari snapshot akan membuat titik akhir baru (snapshot hanya dapat dipulihkan ke cluster baru).
Setelah pemulihan snapshot, titik akhir kustom harus dibuat ulang.
Memulihkan dari cuplikan akan menyetel ulang zona waktu lokal ke UTC.
Memulihkan dari snapshot tidak mempertahankan grup keamanan khusus.
Snapshot dapat dibagikan dengan maksimal 20 ID akun AWS.
Snapshot tidak dapat dibagikan antar wilayah.
Snapshot tambahan selalu disalin sebagai snapshot lengkap, antar wilayah dan dalam wilayah yang sama.
Menyalin cuplikan di seluruh wilayah tidak mempertahankan grup parameter non-default.

Penagihan

Tagihan 10 menit berlaku untuk instans baru, serta mengikuti perubahan kapasitas (komputasi, atau penyimpanan).

Otentikasi

Menggunakan otentikasi basis data IAM memberlakukan batasan jumlah koneksi per detik.
Akun master memiliki hak istimewa pengguna super tertentu yang dicabut.

Memulai dan Menghentikan

Dari Ikhtisar Menghentikan dan Menatap Cluster Aurora DB:

Kluster tidak dapat dibiarkan berhenti tanpa batas karena dimulai secara otomatis setelah 7 hari.
Instans DB individu tidak dapat dihentikan.

Upgrade

Upgrade versi utama di tempat tidak didukung.
Perubahan grup parameter untuk instans DB dan cluster DB membutuhkan waktu setidaknya 5 menit untuk diterapkan.

Kloning

15 klon per database (asli atau salinan).
Klon tidak dihapus saat menghapus basis data sumber.

Penskalaan

Penskalaan Otomatis mengharuskan semua replika tersedia.
Hanya ada `satu kebijakan penskalaan otomatis`_ per metrik per cluster.
Penskalaan horizontal instans DB primer (kelas instans) tidak sepenuhnya otomatis. Sebelum penskalaan kluster memicu failover otomatis ke salah satu replika. Setelah penskalaan selesai, instance baru harus dipromosikan secara manual dari pembaca ke penulis:Instans baru tertinggal dalam mode pembaca setelah kelas instans DB berubah.

Pemantauan

Menerbitkan log PostgreSQL ke CloudWatch memerlukan versi mesin database minimum 9.6.6 dan 10.4.
Hanya beberapa metrik Aurora yang tersedia di Konsol RDS dan metrik lainnya memiliki nama dan unit pengukuran yang berbeda.
Secara default, log Pemantauan yang Disempurnakan disimpan di CloudWatch selama 30 hari.
Metrik Cloudwatch dan Enhanced Monitoring akan berbeda, karena keduanya mengumpulkan data dari hypervisor dan masing-masing agen yang berjalan di instance.
Performance Insights_ menggabungkan metrik di semua database dalam Instans DB.
Pernyataan SQL dibatasi hingga 500 karakter jika dilihat dengan CLI dan API AWS Performance Insights.

Migrasi

Hanya Snapshot DB RDS yang tidak terenkripsi yang dapat dienkripsi saat tidak digunakan.
Migrasi menggunakan teknik Aurora Read Replica membutuhkan waktu beberapa jam per TiB.

Ukuran

Kelas instans terkecil yang tersedia adalah db.t3.medium dan db.r5.24xlarge terbesar. Sebagai perbandingan, mesin MySQL menawarkan db.t2.small dan db.t2.medium, namun tidak ada db.r5.24xlarge di kisaran atas.
batas atas max_connections adalah 262.143.

Pengelolaan Paket Kueri

Pernyataan di dalam fungsi PL/pgSQL tidak didukung.

Migrasi

Aurora PostgreSQL tidak menyediakan layanan migrasi langsung, melainkan tugas dipindahkan ke produk AWS khusus, yaitu AWS DMS.

Kesimpulan

Sebagai pengganti drop-in yang terkelola sepenuhnya untuk PostgreSQL upstream, Amazon Aurora PostgreSQL memanfaatkan teknologi yang mendukung cloud AWS untuk menghilangkan kerumitan yang diperlukan untuk menyiapkan layanan seperti penskalaan otomatis, penyeimbangan beban kueri, data tingkat rendah replikasi, pencadangan tambahan, dan enkripsi.

Arsitektur dan pendekatan konservatif untuk memutakhirkan mesin PostgreSQL memberikan kinerja dan stabilitas yang dicari oleh organisasi dari kecil hingga besar.

Keterbatasan yang melekat hanyalah bukti bahwa membangun Basis Data sebagai Layanan skala besar adalah tugas yang kompleks, meninggalkan Penyedia Hosting PostgreSQL yang sangat terspesialisasi dengan ceruk pasar yang dapat mereka manfaatkan.