Bagikan melalui

Batasan di Azure Database for PostgreSQL

Bagian berikut menjelaskan kapasitas dan batas fungsional untuk instans server fleksibel Azure Database for PostgreSQL. Jika Anda ingin mempelajari tentang tingkat sumber daya (komputasi, memori, penyimpanan), lihat artikel komputasi dan penyimpanan .

Koneksi maksimum

Tabel berikut menunjukkan jumlah koneksi maksimum default untuk setiap tingkat harga dan konfigurasi vCore. Instans server fleksibel Azure Database for PostgreSQL mencadangkan 15 koneksi untuk replikasi fisik dan pemantauan instans server fleksibel Azure Database for PostgreSQL. Akibatnya, tabel mengurangi nilai untuk koneksi pengguna maksimum sebesar 15 dari total koneksi maksimum.

Nama produk vCore Ukuran memori Koneksi maksimum Koneksi pengguna maksimum
Mudah meledak
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1,718 1,703
B8ms 8 32 GiB 3.437 3,422
B12ms 12 48 GiB 5\.000 4,985
B16ms 16 64 GiB 5\.000 4,985
B20ms 20 80 GiB 5\.000 4,985
Tujuan Umum
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1,718 1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 GiB 3.437 3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 GiB 5\.000 4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GiB 5\.000 4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5\.000 4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GiB 5\.000 4,985
D96ds_v5 / D96ads_v5 96 384 GiB 5\.000 4,985
Memori dioptimalkan
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 GiB 3.437 3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 GiB 5\.000 4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GiB 5\.000 4,985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5\.000 4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5\.000 4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5\.000 4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5\.000 4,985
E96ds_v5 / E96ads_v5 96 672 GiB 5\.000 4,985

Slot koneksi yang dipesan, saat ini sebanyak 15, dapat berubah. Kami menyarankan untuk memverifikasi total koneksi yang dipesan secara teratur di server. Anda menghitung angka ini dengan menjumlahkan nilai reserved_connections parameter server dan superuser_reserved_connections . Jumlah maksimum koneksi pengguna yang tersedia adalah max_connections - (reserved_connections + superuser_reserved_connections).

Sistem menghitung nilai default untuk max_connections parameter server saat Anda menyediakan instans server fleksibel Azure Database for PostgreSQL, berdasarkan nama produk yang Anda pilih untuk komputasinya. Setiap perubahan pemilihan produk berikutnya pada komputasi yang mendukung instans tidak akan berpengaruh pada nilai default untuk parameter server instans tersebut max_connections . Kami menyarankan agar setiap kali Anda mengubah produk yang ditetapkan ke instans, Anda juga menyesuaikan nilai untuk max_connections parameter sesuai dengan nilai dalam tabel sebelumnya.

Mengubah nilai max_connections

Saat pertama kali menyiapkan instans server fleksibel Azure Database for Postgres, instans server fleksibel secara otomatis memutuskan jumlah koneksi tertinggi yang dapat ditangani secara bersamaan. Konfigurasi server Anda menentukan nomor ini dan Anda tidak dapat mengubahnya.

Namun, Anda dapat menggunakan max_connections pengaturan untuk menyesuaikan berapa banyak koneksi yang diizinkan pada waktu tertentu. Setelah mengubah pengaturan ini, Anda perlu memulai ulang server agar batas baru mulai berfungsi.

Perhatian

Meskipun dimungkinkan untuk meningkatkan nilai max_connections di luar pengaturan default, kami menyarankan untuk melawannya.

Instans mungkin mengalami kesulitan ketika beban kerja meluas dan menuntut lebih banyak memori. Ketika jumlah koneksi meningkat, penggunaan memori juga naik. Instans dengan memori terbatas mungkin menghadapi masalah seperti crash atau latensi tinggi. Meskipun nilai yang lebih tinggi mungkin max_connections dapat diterima ketika sebagian besar koneksi diam, itu dapat menyebabkan masalah performa yang signifikan setelah aktif.

Jika Anda memerlukan lebih banyak koneksi, kami sarankan Anda menggunakan PgBouncer, solusi Azure bawaan untuk manajemen kumpulan koneksi. Gunakan dalam mode transaksi. Untuk memulai, kami sarankan Anda menggunakan nilai konservatif dengan mengalikan vCore dalam rentang 2 hingga 5. Setelah itu, pantau pemanfaatan sumber daya dan performa aplikasi dengan cermat untuk memastikan kelancaran operasi. Untuk informasi terperinci tentang PgBouncer, lihat PgBouncer di Azure Database for PostgreSQL.

Saat koneksi melebihi batas, Anda mungkin menerima kesalahan berikut:

FATAL: sorry, too many clients already.

Saat Anda menggunakan instans server fleksibel Azure Database for PostgreSQL untuk database yang sibuk dengan sejumlah besar koneksi bersamaan, mungkin ada ketegangan yang signifikan pada sumber daya. Ketegangan ini dapat mengakibatkan pemanfaatan CPU yang tinggi, terutama ketika banyak koneksi dibuat secara bersamaan dan ketika koneksi memiliki durasi pendek (kurang dari 60 detik). Faktor-faktor ini dapat berdampak negatif pada performa database secara keseluruhan dengan meningkatkan waktu yang dihabiskan untuk memproses koneksi dan pemutusan sambungan.

Setiap koneksi dalam instans server fleksibel Azure Database for PostgreSQL, terlepas dari apakah itu menganggur atau aktif, menggunakan sejumlah besar sumber daya dari database Anda. Konsumsi ini dapat menyebabkan masalah performa di luar pemanfaatan CPU yang tinggi, seperti ketidakcocokan disk dan kunci. Artikel Jumlah Koneksi Database di Wiki PostgreSQL membahas artikel ini secara lebih rinci. Untuk mempelajari selengkapnya, lihat Mengidentifikasi dan menyelesaikan performa koneksi di Azure Postgres.

Batasan fungsional

Bagian berikut mencantumkan pertimbangan mengenai apa yang didukung dan yang tidak didukung untuk instans server fleksibel Azure Database for PostgreSQL Anda.

Operasi skala

  • Saat ini, peningkatan skala penyimpanan server memerlukan mulai ulang server.
  • Penyimpanan server hanya dapat diskalakan dalam kelipatan 2x. Lihat Penyimpanan untuk detailnya.
  • Saat ini kami tidak mendukung penurunan ukuran penyimpanan server. Satu-satunya cara untuk melakukan operasi ini adalah dengan mencadangkan dan memulihkannya ke instans server fleksibel Azure Database for PostgreSQL baru.

Storage

  • Setelah mengonfigurasi ukuran penyimpanan, Anda tidak dapat menguranginya. Anda harus membuat server baru dengan ukuran penyimpanan yang diinginkan, melakukan operasi pencadangan dan pemulihan manual, dan memigrasikan database Anda ke server baru.
  • Ketika penggunaan penyimpanan mencapai 95% atau jika kapasitas yang tersedia kurang dari 5 GiB (mana pun yang lebih), sistem secara otomatis mengalihkan server ke mode baca-saja untuk menghindari kesalahan yang terkait dengan situasi penuh disk. Dalam kasus yang jarang terjadi, jika tingkat pertumbuhan data melampaui waktu yang diperlukan untuk beralih ke mode baca-saja, server Anda mungkin masih kehabisan penyimpanan. Anda dapat mengaktifkan pertumbuhan otomatis penyimpanan untuk menghindari masalah ini dan secara otomatis menskalakan penyimpanan Anda berdasarkan tuntutan beban kerja Anda.
  • Sebaiknya atur aturan pemberitahuan untuk storage used atau storage percent ketika melebihi ambang batas tertentu sehingga Anda dapat secara proaktif mengambil tindakan seperti meningkatkan ukuran penyimpanan. Misalnya, Anda dapat mengatur pemberitahuan jika persentase penyimpanan melebihi penggunaan 80%.
  • Jika Anda menggunakan replikasi logis, Anda harus menghilangkan slot replikasi logis di server utama jika pelanggan yang sesuai tidak lagi ada. Jika tidak, file write-ahead logging (WAL) terakumulasi di primer dan mengisi penyimpanan. Jika penyimpanan melebihi ambang tertentu dan jika slot replikasi logis tidak digunakan (karena pelanggan yang tidak tersedia), instans server fleksibel Azure Database for PostgreSQL secara otomatis menghilangkan slot replikasi logis yang tidak digunakan. Tindakan ini melepaskan akumulasi file WAL dan mencegah server Anda menjadi tidak tersedia karena penyimpanan penuh.
  • Kami tidak mendukung pembuatan ruang tabel. Jika Anda membuat database, jangan berikan nama ruang tabel. Instans server fleksibel Azure Database untuk PostgreSQL menggunakan tablespace default yang diwarisi dari database template. Tidak aman untuk menyediakan ruang tabel seperti ruang tabel sementara, karena kami tidak dapat memastikan bahwa objek tersebut akan tetap persisten setelah peristiwa seperti restart server dan failover ketersediaan tinggi (HA).
  • Ketidaksesuaian Penggunaan Disk dan File Data Yatim Piatu: Dalam kasus yang jarang terjadi, PostgreSQL dapat meninggalkan file data yatim piatu pada disk—file yang tidak lagi memiliki entri yang sesuai dalam katalog sistem database (yang melacak semua tabel dan data). Ini dapat terjadi jika tabel dibuat dan diisi dalam transaksi yang gagal diselesaikan dengan sukses (misalnya, karena crash server atau gangguan), yang mengakibatkan ketidakcocokan antara ukuran yang dilaporkan database dan penggunaan disk aktual. Perilaku ini berasal dari basis kode komunitas PostgreSQL dan tidak spesifik untuk Azure. Komunitas PostgreSQL menyadari masalah ini dan sedang mengeksplorasi peningkatan untuk pembersihan otomatis dalam rilis mendatang. Untuk detail selengkapnya, lihat: PostgreSQL: File Yatim piatu di PostgreSQL. Ini dapat menyebabkan konsumsi disk atau penyimpanan yang tidak terduga tinggi.
    • Cara Mendeteksi: Membandingkan ukuran yang dilaporkan database (menggunakan kueri seperti SELECT pg_database_size('your_database')) dengan metrik portal Microsoft Azure untuk penggunaan disk aktual. Jika ada perbedaan yang signifikan, file yatim piatu mungkin menjadi penyebabnya. Jika demikian:
      • Jalankan VACUUM FULL pada tabel yang terpengaruh untuk merebut kembali ruang (catatan: ini intensif sumber daya, memerlukan kunci tabel, dan mungkin memerlukan downtime).
      • Atau, gunakan alat seperti ekstensi pg_repack atau pg_squeeze untuk reorganisasi tanpa waktu henti, tetapi uji di lingkungan non-produksi terlebih dahulu.
      • Pantau melalui metrik portal Microsoft Azure untuk ambang penggunaan disk. Jika masalah berlanjut atau Anda tidak yakin, hubungi Dukungan Azure untuk bantuan.
    • Cara Mencegah: Pastikan transaksi dikelola dengan benar dalam aplikasi Anda untuk meminimalkan operasi yang tidak lengkap. Pantau penggunaan disk secara teratur melalui metrik portal Microsoft Azure. Meningkatkan ke versi PostgreSQL terbaru yang didukung dapat mencakup perbaikan komunitas untuk masalah terkait.

Jaringan

  • Saat ini kami tidak mendukung pemindahan masuk dan keluar dari jaringan virtual.
  • Saat ini kami tidak mendukung menggabungkan akses publik dengan penyebaran di jaringan virtual.
  • Jaringan virtual tidak mendukung aturan firewall. Anda dapat menggunakan kelompok keamanan jaringan sebagai gantinya.
  • Server database akses publik dapat tersambung ke internet publik; misalnya, melalui postgres_fdw. Anda tidak dapat membatasi akses ini. Server di jaringan virtual dapat membatasi akses keluar melalui grup keamanan jaringan.

Ketersediaan tinggi

Zona ketersediaan

  • Saat ini kami tidak mendukung pemindahan server secara manual ke zona ketersediaan yang berbeda. Namun, dengan menggunakan zona ketersediaan pilihan sebagai zona siaga, Anda dapat mengaktifkan KETERSEDIAAN TINGGI. Setelah Anda membuat zona siaga, Anda dapat melakukan failover ke zona siaga tersebut, lalu menonaktifkan KETERSEDIAAN TINGGI.

Mesin postgres, ekstensi, dan PgBouncer

  • Instans server fleksibel Azure Database for PostgreSQL mendukung semua fitur mesin PostgreSQL, termasuk partisi, replikasi logis, dan pembungkus data asing.
  • Instans server fleksibel Azure Database for PostgreSQL mendukung semua contrib ekstensi dan banyak lagi. Untuk informasi selengkapnya, lihat Ekstensi PostgreSQL.
  • Server burstable saat ini tidak memiliki akses ke pengumpul koneksi PgBouncer bawaan.

Menghentikan/memulai operasi

  • Setelah Anda menghentikan instans server fleksibel Azure Database for PostgreSQL, instans tersebut secara otomatis dimulai setelah tujuh hari.

Pemeliharaan Terjadwal

  • Anda dapat mengubah jendela pemeliharaan kustom menjadi hari/waktu dalam seminggu. Namun, setiap perubahan yang Anda buat setelah menerima pemberitahuan pemeliharaan tidak akan berdampak pada pemeliharaan berikutnya. Perubahan hanya berlaku dengan pemeliharaan terjadwal bulanan berikut.

Pencadangan server

  • Sistem mengelola cadangan. Saat ini Anda tidak dapat menjalankan pencadangan secara manual. Sebaiknya gunakan pg_dump sebagai gantinya.

  • Rekam jepret pertama adalah cadangan penuh, dan rekam jepret berturut-turut adalah cadangan diferensial. Cadangan diferensial hanya mencadangkan data yang diubah sejak pencadangan rekam jepret terakhir.

    Misalnya, jika ukuran database Anda adalah 40 GB dan penyimpanan yang disediakan adalah 64 GB, cadangan rekam jepret pertama adalah 40 GB. Sekarang, jika Anda mengubah data 4 GB, ukuran cadangan rekam jepret diferensial berikutnya hanya akan menjadi 4 GB. Log transaksi (log write-ahead) terpisah dari cadangan penuh dan diferensial, dan diarsipkan terus menerus.

Pemulihan server

  • Saat Anda menggunakan fitur pemulihan titik waktu (PITR), sistem membuat server baru dengan konfigurasi komputasi dan penyimpanan yang sama dengan server asalnya.
  • Sistem memulihkan server database di jaringan virtual ke jaringan virtual yang sama saat Anda memulihkan dari cadangan.
  • Server baru yang dibuat selama proses pemulihan tidak memiliki aturan firewall yang ada di server asli. Anda perlu membuat aturan firewall secara terpisah untuk server baru.
  • Kami tidak mendukung pemulihan ke langganan lain. Sebagai solusinya, Anda dapat memulihkan server dalam langganan yang sama lalu memigrasikan server yang dipulihkan ke langganan lain.

Keamanan

  • Postgres 14 dan versi yang lebih baru menonaktifkan hashing MD5 dan sistem hash kata sandi Postgres asli menggunakan metode SCRAM-SHA-256 saja.

Konten terkait

  • Last updated on