Menskalakan sumber daya di Azure Database for PostgreSQL

Instans server fleksibel Azure Database for PostgreSQL mendukung opsi penskalaan vertikal dan horizontal.

Penskalaan Vertikal

Anda dapat menskalakan instans Anda secara vertikal dengan menambahkan lebih banyak sumber daya ke instans server fleksibel Azure Database for PostgreSQL Anda. Anda dapat menambah atau mengurangi jumlah CPU dan memori yang ditetapkan untuknya.

Throughput jaringan instans Anda bergantung pada nilai yang Anda pilih untuk CPU dan memori.

Setelah membuat instans server fleksibel Azure Database for PostgreSQL, Anda dapat menskalakan secara independen:

• Tingkat komputasi dan SKU.
• Tingkat dan ukuran penyimpanan.
• Periode retensi cadangan.

Anda dapat meningkatkan atau menurunkan skala tingkat komputasi antara Burstable, General Purpose, dan Memory Optimized untuk menyesuaikan dengan kebutuhan beban kerja Anda. Di setiap tingkatan ini, Anda dapat memilih dari berbagai pilihan perangkat keras yang telah dikonfigurasi sebelumnya dari generasi yang berbeda dengan berbagai jumlah CPU dan jumlah memori yang diinstal. Anda dapat memilih opsi yang mendukung persyaratan sumber daya sambil menjaga biaya operasional Anda berkurang dan disesuaikan dengan kebutuhan Anda.

Anda dapat menskalakan jumlah vCore dan memasang memori ke atas atau ke bawah. Anda juga dapat mengonfigurasi tingkat penyimpanan ke atas atau ke bawah untuk mengakomodasi persyaratan throughput dan IOPS yang diminta beban kerja Anda. Anda hanya dapat meningkatkan ukuran penyimpanan. Tergantung pada kebutuhan Anda, Anda dapat menambah atau mengurangi periode retensi cadangan antara 7 hingga 35 hari.

Anda dapat menskalakan sumber daya ini dengan menggunakan beberapa antarmuka. Misalnya, Anda dapat menggunakan portal Microsoft Azure atau Azure CLI.

Catatan

Setelah Anda meningkatkan ukuran penyimpanan yang ditetapkan ke instans, Anda tidak dapat menyusutkannya ke ukuran yang lebih kecil.

Penskalaan horizontal

Kluster elastis Azure Database for PostgreSQL memungkinkan Anda untuk menskalakan database Anda secara horizontal untuk mendukung beban kerja data yang melampaui kemampuan satu instans database. Kluster elastis juga memungkinkan potensi untuk menjalankan operasi paralel secara bersamaan di semua node dalam kluster, secara signifikan meningkatkan throughput dan membuka latensi ultra-rendah. Kluster elastis menawarkan dua model pemecahan tabel: sharding berbasis baris dan sharding berbasis skema.

Membaca penskalaan replika

Pendekatan lain untuk menskalakan instans Anda secara horizontal adalah dengan membuat replika baca. Replika baca memungkinkan Anda menskalakan beban kerja baca ke instans server fleksibel Azure Database for PostgreSQL yang terpisah. Ini tidak memengaruhi performa dan ketersediaan instans utama.

Dalam penyiapan yang diskalakan secara horizontal, Anda juga dapat meningkatkan kapasitas instans utama dan replika baca secara vertikal.

Saat Anda mengubah jumlah vCore atau tingkat komputasi, instans dimulai ulang sehingga perangkat keras baru yang ditetapkan mulai menjalankan beban kerja server Anda. Selama waktu ini, sistem beralih ke jenis server baru. Tidak ada koneksi baru yang dapat dibuat, dan semua transaksi yang tidak dilakukan digulung balik.

Waktu keseluruhan yang diperlukan untuk menghidupkan ulang server Anda tergantung pada proses pemulihan crash dan aktivitas database pada saat mulai ulang. Mulai ulang biasanya memakan waktu satu menit atau kurang, tetapi bisa beberapa menit. Waktu tergantung pada aktivitas transaksional ketika mulai ulang dimulai.

Jika aplikasi Anda sensitif terhadap hilangnya transaksi dalam penerbangan yang mungkin terjadi selama penskalaan komputasi, terapkan pola coba lagi transaksi.

Menskalakan penyimpanan tidak memerlukan menghidupkan ulang server dalam banyak kasus. Untuk informasi selengkapnya, lihat opsi penyimpanan di Azure Database for PostgreSQL.

Perubahan periode retensi cadangan adalah operasi online.

Untuk meningkatkan waktu restart, lakukan operasi skala di luar jam sibuk. Pendekatan itu mengurangi waktu yang diperlukan untuk menghidupkan ulang server database.

Penskalaan waktu henti mendekati nol

Penskalaan waktu henti mendekati nol adalah fitur yang dirancang untuk meminimalkan waktu henti saat Anda memodifikasi tingkat penyimpanan dan komputasi. Jika Anda mengubah jumlah vCore atau mengubah tingkat komputasi, server akan memulai ulang untuk menerapkan konfigurasi baru. Selama transisi ke server baru ini, tidak ada koneksi baru yang dapat dibuat.

Biasanya, proses ini dapat memakan waktu antara 2 hingga 10 menit dengan penskalakan reguler. Dengan fitur penskalakan waktu henti mendekati nol, durasi ini dikurangi menjadi kurang dari 30 detik. Pengurangan waktu henti selama sumber daya penskalaan ini meningkatkan ketersediaan keseluruhan instans database Anda.

Cara kerjanya

Saat Anda memperbarui instans server fleksibel Azure Database for PostgreSQL dalam skenario penskalaan, layanan membuat komputer virtual baru untuk server Anda dengan konfigurasi yang diperbarui. Kemudian disinkronkan dengan komputer virtual yang saat ini menjalankan instans Anda, lalu beralih ke komputer virtual baru dengan gangguan singkat. Kemudian proses latar belakang menghilangkan komputer virtual lama.

Proses ini memungkinkan pembaruan yang mulus dengan waktu henti minimal dan secara otomatis dipicu saat Anda mengubah tingkat penyimpanan atau komputasi. Anda tidak perlu mengambil tindakan apa pun untuk menggunakan kemampuan ini. Kemampuan ini didukung untuk instans server fleksibel HA dan non-HA Azure Database for PostgreSQL.

Untuk konfigurasi yang diskalakan secara horizontal, yang terdiri dari server utama dan satu atau beberapa replika baca, operasi penskalaan harus mengikuti urutan tertentu untuk memastikan konsistensi data dan meminimalkan waktu henti. Untuk detail tentang urutan tersebut, lihat penskalaan dengan replika baca.

Catatan

Penskalaan waktu henti mendekati nol adalah jenis operasi default . Ketika batasan berikut ditemui, sistem beralih ke penskalaan reguler, yang melibatkan lebih banyak waktu henti dibandingkan dengan penskalaan waktu henti mendekati nol.

Ekspektasi waktu henti yang tepat

• Durasi waktu henti: Dalam kebanyakan kasus, waktu henti berkisar antara 10 hingga 30 detik.
• Pertimbangan lain: Setelah peristiwa penskalaan, ada periode DNS Time-To-Live (TTL) yang melekat sekitar 30 detik. Proses penskalakan tidak secara langsung mengontrol periode ini. Ini adalah bagian standar dari perilaku DNS. Dari perspektif aplikasi, total waktu henti yang dialami selama penskalaan bisa berada di kisaran 40 hingga 60 detik.

Pertimbangan dan batasan

• Agar penskalaan waktu henti mendekati nol berfungsi, izinkan semua koneksi masuk dan keluar antara alamat IP di subnet yang didelegasikan, saat Anda menggunakan jaringan terintegrasi jaringan virtual. Jika Anda tidak mengizinkan koneksi ini, proses penskalaan hampir tanpa waktu henti tidak akan berfungsi, dan penskalaan terjadi melalui alur kerja penskalaan standar.
• Penskalakan waktu henti mendekati nol tidak berfungsi jika ada batasan kapasitas regional atau batas kuota pada langganan Anda.
• Penskalaan waktu henti mendekati nol tidak berfungsi untuk server replika, karena hanya didukung di server utama. Untuk server replika, operasi penskalaan secara otomatis melalui proses reguler.
• Penskalakan waktu henti mendekati nol tidak berfungsi jika server yang disuntikkan jaringan virtual tidak memiliki alamat IP yang dapat digunakan yang memadai di subnet yang didelegasikan. Jika Anda memiliki server mandiri, diperlukan satu alamat IP tambahan. Untuk instans dengan ketersediaan tinggi diaktifkan, diperlukan dua alamat IP tambahan.
• Slot replikasi logis tidak dipertahankan selama peristiwa failover waktu henti hampir nol. Untuk mempertahankan slot replikasi logis dan memastikan konsistensi data setelah operasi skala, gunakan ekstensi pg_failover_slot . Untuk informasi selengkapnya, lihat mengaktifkan ekstensi pg_failover_slots dalam instans server fleksibel.
• Penskalakan waktu henti mendekati nol tidak berfungsi dengan tabel yang tidak di-unlogged. Jika Anda menggunakan tabel tanpa pencatatan log untuk salah satu data, Anda akan kehilangan semua data dalam tabel tersebut setelah penskalakan dengan waktu henti mendekati nol.
• Mendekati nol tidak berfungsi jika Anda menskalakan komputasi server Anda dari atau ke ukuran komputasi 1 atau 2 vCore tingkat Burstable.

Konten terkait

• Mengelola Azure Database for PostgreSQL