PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Ikhtisar Penawaran Amazon RDS &Aurora untuk PostgreSQL

Layanan AWS PostgreSQL berada di bawah payung RDS, yang merupakan penawaran DaaS Amazon untuk semua mesin database yang dikenal.

Layanan database terkelola menawarkan keuntungan tertentu yang menarik bagi pelanggan yang mencari kemandirian dari pemeliharaan infrastruktur, dan konfigurasi yang sangat tersedia. Seperti biasa, tidak ada satu ukuran yang cocok untuk semua solusi. Opsi yang tersedia saat ini disorot di bawah ini:

Aurora PostgreSQL

Halaman FAQ Amazon Aurora memberikan detail penting yang perlu dipertimbangkan sebelum mendalami produk. Misalnya, kita mengetahui bahwa lapisan penyimpanan divirtualisasikan dan berada di sistem penyimpanan tervirtualisasi berpemilik yang didukung oleh SSD.

Harga

Dalam hal harga, harus diperhatikan bahwa Aurora PostgreSQL tidak tersedia di AWS Tingkat Gratis.

Kompatibilitas

Halaman FAQ yang sama memperjelas bahwa Amazon tidak mengklaim 100% kompatibilitas PostgreSQL. Sebagian besar (penekanan saya) dari aplikasi akan baik-baik saja, mis. rasa AWS PostgreSQL kompatibel dengan kabel dengan PostgreSQL 9.6. Hasilnya, Wireshark PostgreSQL Dissector akan bekerja dengan baik.

Kinerja

Performa juga ditautkan ke jenis instans, misalnya jumlah maksimum koneksi secara default dikonfigurasi berdasarkan ukuran instans.

Juga penting dalam hal kompatibilitas adalah ukuran halaman yang telah disimpan di 8KiB yang merupakan ukuran halaman default PostgreSQL. Berbicara tentang halaman, ada baiknya mengutip FAQ:“Tidak seperti mesin database tradisional, Amazon Aurora tidak pernah mendorong halaman database yang dimodifikasi ke lapisan penyimpanan, yang menghasilkan penghematan konsumsi IO lebih lanjut. ” Hal ini dimungkinkan karena Amazon mengubah cara cache halaman dikelola, memungkinkannya tetap berada di memori jika terjadi kegagalan database. Fitur ini juga menguntungkan restart database setelah crash, memungkinkan pemulihan terjadi lebih cepat daripada metode tradisional memutar ulang log.

Menurut FAQ yang dirujuk di atas, Aurora PostgreSQL memberikan tiga kali kinerja PostgreSQL pada operasi SELECT dan UPDATE. Sesuai White Paper PostgreSQL Benchmark Amazon, alat yang digunakan untuk mengukur kinerja adalah pgbench dan sysbench. Yang menonjol adalah ketergantungan kinerja pada jenis instans, pemilihan wilayah, dan kinerja jaringan. Ingin tahu mengapa INSERT tidak disebutkan? Itu karena kepatuhan PostgreSQL ACID ("C") mengharuskan catatan yang diperbarui dibuat menggunakan penghapusan diikuti dengan penyisipan.

Untuk memanfaatkan sepenuhnya peningkatan kinerja, Amazon merekomendasikan agar aplikasi dirancang untuk berinteraksi dengan database menggunakan kueri dan transaksi bersamaan dalam jumlah besar . Faktor penting ini, sering diabaikan sehingga menyebabkan kinerja buruk yang disalahkan pada implementasi.

Batas

Ada beberapa batasan yang harus dipertimbangkan saat merencanakan migrasi:

  • large_pages tidak dapat diubah, namun diaktifkan secara default:

    template1=> select aurora_version();
     aurora_version
    ----------------
     1.0.11
    (1 row)
    
    template1=> show huge_pages ;
     huge_pages
    ------------
     on
    (1 row)
  • pg_hba tidak dapat digunakan karena memerlukan restart server. Sebagai catatan, itu pasti salah ketik dalam dokumentasi Amazon, karena PostgreSQL hanya perlu dimuat ulang. Alih-alih mengandalkan pg_hba, administrator perlu menggunakan Grup Keamanan AWS, dan GRANT PostgreSQL.
  • Perincian PITR adalah 5 menit.
  • Replikasi lintas wilayah saat ini tidak tersedia untuk PostgreSQL.
  • Ukuran maksimum tabel adalah 64TiB
  • Hingga 15 replika baca

Skalabilitas

Menaikkan dan menurunkan skala instans database saat ini merupakan proses manual, yang dapat dilakukan melalui AWS Console atau CLI, meskipun penskalaan otomatis sedang berjalan, namun, menurut FAQ Amazon Aurora, itu hanya akan tersedia untuk MySQL.

Sumber daya komputasi penskalaan log peristiwa

Untuk menskalakan secara horizontal, aplikasi harus memanfaatkan AWS SDK API, misalnya untuk mencapai failover cepat.

Ketersediaan Tinggi

Beralih ke ketersediaan tinggi, jika terjadi kegagalan node utama, Aurora PostgreSQL menyediakan titik akhir cluster sebagai catatan DNS A, yang secara otomatis diperbarui secara internal untuk menunjuk ke replika yang dipilih untuk menjadi master.

Cadangan

Perlu disebutkan bahwa jika database dihapus, snapshot cadangan manual apa pun akan disimpan, sementara snapshot otomatis dihapus.

Replikasi

Karena replika berbagi penyimpanan dasar yang sama dengan instans utama, secara teori, jeda replikasi berada dalam kisaran milidetik.

Amazon merekomendasikan replika baca untuk mengurangi durasi failover. Dengan replika baca dalam keadaan siaga, proses failover memakan waktu sekitar 30 detik, sedangkan tanpa replika membutuhkan waktu hingga 15 menit.

Kabar baik lainnya adalah bahwa Replikasi logis juga didukung, seperti yang ditunjukkan pada halaman 22.

Meskipun FAQ Amazon Aurora tidak memberikan detail tentang replikasi seperti halnya untuk MySQL, Praktik Terbaik Aurora PostgreSQL menyediakan kueri yang berguna untuk memverifikasi status replikasi:

select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();

Kueri di atas menghasilkan:

-[ RECORD 1 ]--------------+-------------------------------------
server_id                  | testdb
session_id                 | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd           | 46640889
cur_replay_latency_in_usec | 8830
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id                  | testdb-us-east-1b
session_id                 | MASTER_SESSION_ID
highest_lsn_rcvd           |
cur_replay_latency_in_usec |
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:55-07

Karena replikasi adalah topik yang sangat penting, ada baiknya menyiapkan tes pgbench seperti yang diuraikan dalam kertas putih benchmark yang dirujuk di atas:

[[email protected] ~]$ whoami
ec2-user

[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/

[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8

Petunjuk: Hindari pengetikan yang tidak perlu dengan membuat file pgpass dan mengekspor host, database, dan variabel lingkungan pengguna, misalnya:

[[email protected] ~]#  tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1

[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:password

Jalankan perintah inisialisasi data:

[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres

Saat inisialisasi data sedang berjalan, tangkap jeda replikasi menggunakan SQL di atas yang dipanggil dari dalam skrip berikut:

while : ; do
   psql -t -q \
      -c 'select server_id, session_id, highest_lsn_rcvd,
                 cur_replay_latency_in_usec, now(), last_update_timestamp
                 from aurora_replica_status();' postgres
   sleep 1
done

Memfilter output screenlog melalui perintah berikut:

[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
                     513116   2018-07-30 04:30:44.394729+00   2018-07-30 04:30:43+00
                     529294   2018-07-30 04:20:54.261741+00   2018-07-30 04:20:53+00
                     544139   2018-07-30 04:41:57.538566+00   2018-07-30 04:41:57+00
                    1001902   2018-07-30 04:42:54.80136+00   2018-07-30 04:42:53+00
                    2376951   2018-07-30 04:38:06.621681+00   2018-07-30 04:38:06+00
                    2376951   2018-07-30 04:38:07.672919+00   2018-07-30 04:38:07+00
                    5365719   2018-07-30 04:36:51.608983+00   2018-07-30 04:36:50+00
                    5365719   2018-07-30 04:36:52.912731+00   2018-07-30 04:36:51+00
                    6308586   2018-07-30 04:45:22.951966+00   2018-07-30 04:45:21+00
                    8210986   2018-07-30 04:46:14.575385+00   2018-07-30 04:46:13+00

Ternyata replikasi tertinggal sebanyak 8 detik!

Pada catatan terkait, metrik AWS CloudWatch AuroraReplicaLagMaximum tidak setuju dengan hasil dari perintah SQL di atas. Saya ingin tahu alasannya, jadi masukan sangat kami hargai.

RDS CloudWatch grafik jeda replika maks

Keamanan

  • Enkripsi tersedia dan harus diaktifkan saat database dibuat, karena tidak dapat diubah setelahnya.

Pemecahan Masalah

Bagian singkat ini adalah bagian yang penting Pastikan bahwa work_mem PostgreSQL disetel dengan tepat sehingga operasi pengurutan tidak menulis data ke disk.

Penyiapan

Cukup ikuti wizard penyiapan di AWS Console:

  1. Buka Amazon RDS konsol manajemen.

    Konsol manajemen RDS
  2. Pilih Amazon Aurora dan PostgreSQL edisi.

    Penyihir Aurora PostgreSQL
  3. Tentukan detail DB dan perhatikan batasan kata sandi Aurora PostgreSQL:

    Master Password must be at least eight characters long, as in
    "mypassword". Can be any printable ASCII character except "/", """, or "@".
    Detail database wizard Aurora PostgreSQL
  4. Konfigurasikan opsi basis data:

    • Saat tulisan ini dibuat, hanya PostgreSQL 9.6 yang tersedia. Gunakan PostgreSQL di Amazon RDS jika Anda memerlukan dukungan untuk versi yang lebih baru, termasuk pratinjau beta.
  5. Konfigurasikan prioritas failover, dan pilih jumlah replika.

    Deskripsi foto
  6. Setel retensi cadangan (maksimum 35 hari).

    Retensi cadangan wizard Aurora PostgreSQL
  7. Pilih jadwal perawatan. Pembaruan versi minor otomatis tersedia, namun penting untuk memverifikasi dengan dukungan AWS apakah jadwal patch mereka dapat dipercepat atau tidak jika proyek PostgreSQL merilis pembaruan mendesak apa pun. Sebagai contoh, dibutuhkan lebih dari dua bulan bagi AWS untuk mendorong pembaruan 10-05-2018.

    Jadwal pemeliharaan wizard Aurora PostgreSQL
  8. Jika database telah berhasil dibuat, tautan ke petunjuk tentang cara menghubungkannya akan ditampilkan:

    Pengaturan wizard Aurora PostgreSQL selesai

Menghubungkan ke database

Tinjau instruksi terperinci untuk opsi koneksi yang tersedia, berdasarkan penyiapan infrastruktur. Dalam skenario paling sederhana, koneksi dilakukan melalui instans EC2 publik.

Catatan:Klien harus kompatibel dengan PostgreSQL 9.6.3 atau yang lebih baru.

[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Pemantauan

Amazon menyediakan berbagai metrik untuk memantau database, contoh di bawah ini menunjukkan metrik instans:

Metrik instans RDSUnduh Whitepaper Today Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola dan menskalakan PostgreSQLUnduh Whitepaper

RDS untuk PostgreSQL

Ini adalah penawaran yang memungkinkan lebih banyak perincian dalam hal pilihan konfigurasi. Misalnya, berbeda dengan Aurora yang menggunakan sistem penyimpanan berpemilik, RDS menawarkan penyimpanan yang dapat dikonfigurasi menggunakan volume EBS yang dapat berupa SSD Tujuan Umum (GP2), atau IOPS yang Disediakan, atau magnetis (tidak disarankan).

Untuk membantu penginstalan besar, yang memerlukan penyesuaian yang tidak tersedia dalam penawaran Aurora, Amazon baru-baru ini merilis rekomendasi Praktik terbaik, hanya tersedia untuk RDS.

Ketersediaan tinggi harus dikonfigurasi secara manual (atau otomatis menggunakan salah satu alat AWS yang dikenal) dan disarankan untuk menyiapkan penerapan Multi-AZ.

Replikasi diimplementasikan menggunakan replikasi asli PostgreSQL.

Ada beberapa batasan untuk instans DB PostgreSQL yang perlu dipertimbangkan.

Dengan mengingat catatan di atas, inilah panduan untuk menyiapkan lingkungan Multi-AZ PostgreSQL RDS:

  1. Dari Konsol Manajemen RDS mulai wizard

    Wizard PostgreSQL RDS
  2. Pilih antara penyiapan produksi dan pengembangan.

    Pemilihan kasus penggunaan database wizard PostgreSQL RDS
  3. Masukkan detail tentang cluster database baru Anda.

    Detail DB wizard PostgreSQL RDS Pengaturan basis data wizard PostgreSQL RDS
  4. Di halaman berikutnya, siapkan jaringan, keamanan, dan jadwal pemeliharaan:

    Pengaturan lanjutan wizard PostgreSQL RDS Keamanan dan pemeliharaan wizard PostgreSQL RDS

Kesimpulan

Layanan Amazon RDS untuk PostgreSQL mencakup RDS PostgreSQL dan Aurora PostgreSQL, keduanya merupakan penawaran DaaS terkelola. Dikemas dengan banyak fitur dan penyimpanan backend yang solid, mereka memiliki beberapa keterbatasan dibandingkan pengaturan tradisional, namun, dengan perencanaan yang matang, penawaran ini dapat memberikan rasio fungsionalitas biaya yang seimbang. Amazon RDS for PostgreSQL ditargetkan untuk pengguna yang membutuhkan lebih banyak opsi untuk mengonfigurasi lingkungan mereka, dan umumnya lebih mahal. Sebagian besar pengguna akan mendapat manfaat dari memulai dengan Aurora PostgreSQL dan melanjutkan ke konfigurasi yang lebih kompleks.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Migrasi Rails:Bigint di PostgreSQL tampaknya gagal?

  2. tidak ada entri FROM-klausa untuk tabel Grupo cakephp

  3. Bagaimana cara membuat database postgresql saya menggunakan susunan case-insensitive?

  4. Tidak ada driver yang cocok ditemukan saat menyertakan driver yang dibutuhkan dengan maven-assembly-plugin

  5. Rails, PostgreSQL, dan Pemicu Sejarah