Bagikan melalui

Membaca replika di server fleksibel Azure Database for PostgreSQL

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Fitur replika baca memungkinkan Anda mereplikasi data dari instans server fleksibel Azure Database for PostgreSQL ke replika baca-saja. Replika diperbarui secara asinkron dengan teknologi replikasi fisik asli mesin PostgreSQL. Replikasi streaming dengan menggunakan slot replikasi merupakan mode operasi default. Jika perlu, pengiriman log berbasis file digunakan untuk mengejar ketinggalan. Anda dapat mereplikasi dari server utama maksimal lima replika.

Replika adalah server baru yang Anda kelola mirip dengan instans server fleksibel Azure Database for PostgreSQL reguler. Untuk setiap replika baca, Anda akan ditagih atas komputasi yang disediakan dalam vCore dan penyimpanan dalam GB/bulan.

Pelajari cara membuat replika baca.

Kapan harus menggunakan replika baca

Fitur replika baca membantu meningkatkan performa dan skala beban kerja intensif baca. Beban kerja baca dapat diisolasi ke replika, sementara beban kerja tulis dapat diarahkan ke yang utama. Replika baca juga dapat disebarkan di wilayah yang berbeda dan dapat dipromosikan ke server baca-tulis jika pemulihan bencana diperlukan.

Skenario umumnya adalah meminta BI dan beban kerja analitik menggunakan replika baca sebagai sumber data untuk pelaporan.

Karena bersifat baca-saja, replika tidak mengurangi beban kapasitas tulis pada replika utama secara langsung.

Pertimbangan

Replika baca terutama dirancang untuk skenario di mana kueri offloading bermanfaat, dan sedikit jeda dapat dikelola. Mereka dioptimalkan untuk memberikan pembaruan mendekati real time dari primer untuk sebagian besar beban kerja, menjadikannya solusi yang sangat baik untuk skenario baca-berat. Namun, penting untuk dicatat bahwa mereka tidak ditujukan untuk skenario replikasi sinkron yang memerlukan akurasi data hingga menit. Meskipun data pada replika akhirnya menjadi konsisten dengan primer, mungkin ada penundaan, yang biasanya berkisar dari beberapa detik hingga menit, dan dalam beberapa beban kerja berat atau skenario latensi tinggi, penundaan ini dapat diperpanjang hingga berjam-jam. Biasanya, replika baca di wilayah yang sama dengan primer memiliki lebih sedikit jeda daripada geo-replika, karena yang terakhir sering menangani latensi yang diinduksi jarak geografis. Untuk wawasan lebih lanjut tentang implikasi performa replikasi geografis, lihat artikel Geo-replikasi . Data pada replika akhirnya selaras dengan data di server utama. Gunakan fitur tersebut untuk beban kerja yang dapat mengakomodasi penundaan ini.

Catatan

Untuk sebagian besar beban kerja, replika baca menawarkan pembaruan hampir real-time dari primer. Namun, dengan beban kerja utama intensif penulisan berat yang persisten, jeda replikasi dapat terus tumbuh dan mungkin hanya dapat mengejar ketinggalan dengan yang utama. Ini juga dapat meningkatkan penggunaan penyimpanan di primer karena file WAL hanya dihapus setelah diterima di replika. Jika situasi ini berlanjut, menghapus dan membuat ulang replika baca setelah beban kerja intensif penulisan selesai, Anda dapat membawa replika kembali ke keadaan yang baik untuk jeda. Replika baca asinkron tidak sesuai untuk beban kerja tulis berat tersebut. Saat mengevaluasi replika baca untuk aplikasi Anda, pantau jeda pada replika untuk siklus beban kerja aplikasi lengkap melalui waktu puncak dan non-puncaknya untuk menilai kemungkinan jeda dan RTO/RPO yang diharapkan di berbagai titik siklus beban kerja.

Membuat replika

Server utama untuk server fleksibel Azure Database for PostgreSQL dapat disebarkan di wilayah mana pun yang mendukung layanan. Anda dapat membuat replika server utama dalam wilayah yang sama atau di berbagai wilayah Azure global tempat server fleksibel Azure Database for PostgreSQL tersedia. Kemampuan untuk membuat replika sekarang meluas ke beberapa wilayah Azure khusus. Lihat artikel Replikasi geografis untuk daftar wilayah khusus tempat Anda dapat membuat replika.

Saat Anda memulai alur kerja buat replika, instans server fleksibel Azure Database for PostgreSQL kosong dibuat. Server baru diisi dengan data di server utama. Untuk pembuatan replika di wilayah yang sama, pendekatan rekam jepret digunakan. Oleh karena itu, waktu pembuatan tidak tergantung pada ukuran data. Geo-replika dibuat menggunakan cadangan dasar instans utama, yang kemudian ditransmisikan melalui jaringan; oleh karena itu, waktu pembuatan mungkin berkisar dari menit hingga beberapa jam, tergantung pada ukuran utama.

Replika hanya dianggap berhasil dibuat ketika dua kondisi terpenuhi: seluruh cadangan instans utama harus disalin ke replika, dan log transaksi harus disinkronkan tanpa jeda 1 GB.

Untuk mencapai operasi pembuatan yang berhasil, hindari membuat replika selama waktu beban transaksional yang tinggi. Misalnya, Anda harus menghindari pembuatan replika saat bermigrasi dari sumber lain ke server fleksibel Azure Database for PostgreSQL atau selama operasi beban massal yang berat. Jika Anda memigrasikan data atau memuat data dalam jumlah besar saat ini, yang terbaik adalah menyelesaikan tugas ini terlebih dahulu. Setelah menyelesaikannya, Anda kemudian dapat mulai menyiapkan replika. Setelah migrasi atau operasi beban massal selesai, periksa apakah ukuran log transaksi telah kembali ke ukuran normalnya. Biasanya, ukuran log transaksi harus dekat dengan nilai yang ditentukan dalam parameter server max_wal_size untuk instans Anda. Anda dapat melacak jejak penyimpanan log transaksi menggunakan metrik Penyimpanan Log Transaksi yang Digunakan , yang memberikan wawasan tentang jumlah penyimpanan yang digunakan oleh log transaksi. Dengan memantau metrik ini, Anda dapat memastikan bahwa ukuran log transaksi berada dalam rentang yang diharapkan dan bahwa proses pembuatan replika mungkin dimulai.

Penting

Replika Baca saat ini didukung untuk tingkat komputasi server Tujuan Umum dan Memori yang Dioptimalkan. Tingkat komputasi server burstable tidak didukung.

Penting

Saat melakukan operasi pembuatan, penghapusan, dan promosi replika, server utama akan memasuki status pembaruan. Selama waktu ini, operasi manajemen server seperti memodifikasi parameter server, mengubah opsi ketersediaan tinggi, atau menambahkan atau menghapus firewall tidak akan tersedia. Penting untuk dicatat bahwa status pembaruan hanya memengaruhi operasi manajemen server dan tidak memengaruhi operasi data plane . Ini berarti bahwa server database Anda akan tetap berfungsi penuh dan dapat menerima koneksi, serta melayani lalu lintas baca dan tulis.

Pelajari cara membuat replika siap baca.

Manajemen konfigurasi

Saat menyiapkan replika baca untuk server fleksibel Azure Database for PostgreSQL, penting untuk memahami konfigurasi server yang dapat disesuaikan, yang diwarisi dari primer, dan batasan terkait apa pun.

Konfigurasi yang diwariskan

Saat replika baca dibuat, replika tersebut mewarisi konfigurasi server tertentu dari server utama. Konfigurasi ini dapat diubah baik selama pembuatan replika atau setelah disiapkan. Namun, pengaturan tertentu, seperti cadangan geografis, tidak akan direplikasi ke replika baca.

Konfigurasi selama pembuatan replika

  • Tingkat, ukuran penyimpanan: Untuk operasi "promosikan ke server utama", harus sama dengan yang utama. Untuk operasi "promosikan ke server independen dan hapus dari replikasi", bisa sama atau lebih tinggi dari yang utama.
  • Tingkat performa (IOPS): Dapat disesuaikan.
  • Enkripsi data: Dapat disesuaikan, termasuk berpindah dari kunci yang dikelola layanan ke kunci yang dikelola pelanggan.

Konfigurasi pasca pembuatan

  • Aturan firewall: Dapat ditambahkan, dihapus, atau dimodifikasi.
  • Tingkat, ukuran penyimpanan: Untuk operasi "promosikan ke server utama", harus sama dengan yang utama. Untuk operasi "promosikan ke server independen dan hapus dari replikasi", bisa sama atau lebih tinggi dari yang utama.
  • Tingkat performa (IOPS): Dapat disesuaikan.
  • Metode autentikasi: Dapat disesuaikan, opsi termasuk beralih dari autentikasi PostgreSQL ke Microsoft Entra.
  • Parameter server: Sebagian besar dapat disesuaikan. Namun, mereka yang memengaruhi ukuran memori bersama harus selaras dengan skenario utama, terutama untuk skenario potensial "promosikan ke server utama". Untuk operasi "promosikan ke server independen dan hapus dari replikasi", parameter ini harus sama atau melebihi yang ada di primer.
  • Jadwal pemeliharaan: Dapat disesuaikan.

Fitur yang tidak didukung pada replika baca

Fungsi tertentu dibatasi untuk server utama dan tidak dapat disiapkan pada replika baca. Ini termasuk:

  • Pencadangan, termasuk cadangan geografis.
  • Ketersediaan tinggi (HA)

Jika instans server fleksibel Azure Database for PostgreSQL sumber Anda dienkripsi dengan kunci yang dikelola pelanggan, lihat dokumentasi untuk pertimbangan lain.

Menghubungkan ke replika

Saat Anda membuat replika, replika tersebut mewarisi aturan firewall atau titik akhir layanan jaringan virtual server utama. Aturan ini dapat diubah selama pembuatan replika dan pada titik waktu selanjutnya.

Replika mewarisi akun administrator dari server utama. Semua akun pengguna di server utama direplikasi ke replika baca. Anda hanya dapat tersambung ke replika baca dengan menggunakan akun pengguna yang tersedia di server utama.

Ada dua metode untuk terhubung ke replika:

  • Langsung ke Instans Replika: Anda dapat terhubung ke replika menggunakan nama host dan akun pengguna yang valid, seperti yang Anda lakukan pada instans server fleksibel Azure Database for PostgreSQL biasa. Untuk server bernama myreplica
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Di perintah, masukkan kata sandi untuk akun pengguna.

Selain itu, untuk memudahkan proses koneksi, portal Azure menyediakan string koneksi yang siap digunakan. Ini dapat ditemukan di halaman Sambungkan . Mereka mencakup libpq variabel dan string koneksi yang disesuaikan untuk konsol bash.

  • Melalui Titik Akhir Virtual: Ada metode koneksi alternatif menggunakan titik akhir virtual, seperti yang dirinci dalam artikel Titik akhir virtual. Dengan menggunakan titik akhir virtual, Anda dapat mengonfigurasi titik akhir baca-saja untuk secara konsisten menunjuk ke replika, terlepas dari server mana yang saat ini memegang peran replika.

Pantau replikasi

Fitur replika baca di server fleksibel Azure Database for PostgreSQL bergantung pada mekanisme slot replikasi. Keuntungan utama dari slot replikasi adalah bahwa mereka secara otomatis menyesuaikan jumlah log transaksi (segmen WAL) yang diperlukan oleh semua server replika. Ini membantu mencegah replika tidak sinkron karena menghindari penghapusan segmen WAL pada primer sebelum dikirim ke replika. Kerugian dari pendekatan ini adalah risiko kehabisan ruang pada primer jika slot replikasi tetap tidak aktif untuk waktu yang lama. Dalam situasi seperti itu, primer mengakumulasi file WAL yang menyebabkan pertumbuhan inkremental penggunaan penyimpanan. Ketika penggunaan penyimpanan mencapai 95% atau jika kapasitas yang tersedia kurang dari 5 GiB, server secara otomatis dialihkan ke mode baca-saja untuk menghindari kesalahan yang terkait dengan situasi disk-penuh.
Oleh karena itu, memantau status jeda replikasi dan slot replikasi sangat penting untuk replika baca.

Sebaiknya atur aturan pemberitahuan untuk penyimpanan yang digunakan atau persentase penyimpanan, dan untuk jeda replikasi, ketika melebihi ambang batas tertentu sehingga Anda dapat secara proaktif bertindak, meningkatkan ukuran penyimpanan, dan menghapus replika baca yang tertinggal. Misalnya, Anda dapat mengatur pemberitahuan jika persentase penyimpanan melebihi penggunaan 80%, dan jika jeda replika lebih tinggi dari 5 menit. Metrik Penyimpanan Log Transaksi yang Digunakan menunjukkan kepada Anda jika akumulasi file WAL adalah alasan utama penggunaan penyimpanan yang berlebihan.

Pemantauan metrik

Server fleksibel Azure Database for PostgreSQL menyediakan metrik berikut untuk memantau replikasi.

Anda dapat menggunakan metrik yang ditingkatkan untuk pemantauan dan pemberitahuan tentang replikasi baca.

Mengaktifkan metrik lanjutan

  • Sebagian besar metrik baru ini dinonaktifkan secara default. Namun, ada beberapa pengecualian, yang diaktifkan secara default. Kolom paling kanan dalam tabel berikut menunjukkan apakah setiap metrik diaktifkan secara default atau tidak.
  • Untuk mengaktifkan metrik yang tidak diaktifkan secara default, atur parameter metrics.collector_database_activity server ke ON. Parameter ini bersifat dinamis dan tidak memerlukan mulai ulang instans.
Replikasi Logis
Nama tampilan ID metrik Satuan Deskripsi Dimensi Default diaktifkan
Keterlambatan Replikasi Logis Maksimal logical_replication_delay_in_bytes Bita Keterlambatan maksimum di seluruh slot replikasi logika. Tidak berlaku Ya
Replikasi
Nama tampilan ID metrik Satuan Deskripsi Dimensi Default diaktifkan
Lag Replikasi Fisik Maks physical_replication_delay_in_bytes Bita Lag maksimum di semua slot replikasi fisik asinkron. Tidak berlaku Ya
Baca Lag Replika physical_replication_delay_in_seconds Detik Baca lag replika dalam hitung detik. Tidak berlaku Ya

Untuk mempelajari selengkapnya, lihat artikel cara membaca replika.

Metrik Max Physical Replication Lag menunjukkan lag dalam byte antara replika utama dan yang paling tertinggal. Metrik ini hanya berlaku dan tersedia di server utama, dan hanya akan tersedia jika setidaknya salah satu replika baca terhubung ke replika utama. Informasi jeda juga ada ketika replika sedang dalam proses mengejar ketinggalan dengan primer, selama pembuatan replika, atau ketika replikasi menjadi tidak aktif.

Metrik Lag Replika Baca menunjukkan waktu sejak transaksi terakhir diputar ulang. Misalnya jika tidak ada transaksi yang terjadi di server utama Anda, dan transaksi terakhir diputar ulang 5 detik yang lalu, maka Lag Replika Baca menunjukkan penundaan 5 detik. Metrik ini hanya berlaku dan tersedia pada replika.

Atur pemberitahuan untuk memberi tahu Anda saat lag replika mencapai nilai yang tidak dapat diterima untuk beban kerja Anda.

Untuk wawasan lebih lanjut, kueri server utama secara langsung untuk mendapatkan jeda replikasi pada semua replika.

Catatan

Jika server utama atau replika baca dimulai ulang, waktu yang diperlukan untuk memulai ulang dan mengejar ketinggalan direpresentasikan dalam metrik Lag Replika.

Status replikasi

Untuk memantau kemajuan dan status replikasi dan mempromosikan operasi, lihat kolom Status replikasi di portal Azure. Kolom ini terletak di halaman replikasi dan menampilkan berbagai status yang memberikan wawasan tentang kondisi replika baca saat ini dan tautannya ke primer. Untuk pengguna yang mengandalkan API Azure Resource Manager, saat memanggil GetReplica API, status muncul sebagai ReplicationState di replica tas properti.

Berikut adalah nilai yang mungkin:

Status replikasi Deskripsi Promosikan pesanan Membaca urutan pembuatan replika
Mengonfigurasi ulang Menunggu dimulainya tautan replika-primer. Mungkin tetap lebih lama jika replika atau wilayahnya tidak tersedia, misalnya, karena bencana. 1 T/A
Bawaan Replika baca sedang disediakan dan replikasi antara kedua server belum dimulai. Hingga provisi selesai, Anda tidak dapat tersambung ke replika baca. T/A 1
Memperbarui Konfigurasi server sedang dalam persiapan setelah tindakan yang dipicu seperti promosi atau pembuatan replika baca. 2 2
Penangkapan File WAL sedang diterapkan pada replika. Durasi untuk fase ini selama promosi tergantung pada opsi sinkronisasi data yang dipilih - direncanakan atau dipaksakan. 3 3
Aktif Status sehat, menunjukkan bahwa replika baca telah berhasil terhubung ke primer. Jika server dihentikan tetapi berhasil tersambung sebelumnya, status tetap aktif. 4 4
Rusak Status tidak sehat, menunjukkan operasi promosi mungkin gagal, atau replika tidak dapat terhubung ke primer karena alasan tertentu. Silakan hilangkan replika dan buat ulang replika untuk menyelesaikan ini." T/A T/A

Pelajari cara memantau replikasi.

Pertimbangan

Bagian ini merangkum pertimbangan tentang fitur replika baca. Pertimbangan berikut berlaku.

  • Operasi daya: Operasi daya, termasuk tindakan mulai dan hentikan , dapat diterapkan ke server utama dan replika. Namun, untuk mempertahankan integritas sistem, urutan tertentu harus diikuti. Sebelum menghentikan replika baca, pastikan server utama dihentikan terlebih dahulu. Saat memulai operasi, mulai tindakan mulai pada server replika sebelum memulai server utama.
  • Jika server memiliki replika baca, maka replika baca harus dihapus terlebih dahulu sebelum menghapus server utama.
  • Peningkatan versi utama di tempat di server fleksibel Azure Database for PostgreSQL memerlukan penghapusan replika baca apa pun yang saat ini diaktifkan di server. Setelah replika dihapus, server utama dapat ditingkatkan ke versi utama yang diinginkan. Setelah peningkatan selesai, Anda dapat membuat ulang replika untuk melanjutkan proses replikasi.
  • Premium SSD v2: Pada rilis saat ini, jika server utama menggunakan Premium SSD v2 untuk penyimpanan, pembuatan replika baca tidak didukung.
  • Mereset kata sandi admin: Mereset kata sandi admin di server replika saat ini tidak didukung. Selain itu, memperbarui kata sandi admin bersama dengan mempromosikan operasi replika dalam permintaan yang sama juga tidak didukung. Jika Anda ingin melakukan ini, Anda harus terlebih dahulu mempromosikan server replika, lalu memperbarui kata sandi di server yang baru dipromosikan secara terpisah.

Replika baru

Replika baca dibuat sebagai instans server fleksibel Azure Database for PostgreSQL baru. Server yang sudah ada tidak dapat dibuat menjadi replika. Anda tidak dapat membuat replika replika baca lain, yaitu replikasi berskala tidak didukung.

Pemindahan sumber daya

Pengguna dapat membuat replika baca di grup sumber daya yang berbeda dari replika utama. Namun, memindahkan replika baca ke grup sumber daya lain setelah pembuatannya tidak didukung. Selain itu, memindahkan replika ke langganan yang berbeda, dan memindahkan replika utama yang memiliki replika baca ke grup sumber daya atau langganan lain, tidak didukung.

Pertumbuhan otomatis penyimpanan

Saat mengonfigurasi replika baca untuk instans server fleksibel Azure Database for PostgreSQL, penting untuk memastikan bahwa pengaturan autogrow penyimpanan pada replika cocok dengan server utama. Fitur autogrow penyimpanan memungkinkan penyimpanan database meningkat secara otomatis untuk mencegah kehabisan ruang, yang dapat menyebabkan pemadaman database. Berikut cara mengelola pengaturan autogrow penyimpanan secara efektif:

  • Anda dapat mengaktifkan autogrow penyimpanan pada replika apa pun terlepas dari pengaturan server utama.
  • Jika pertumbuhan otomatis penyimpanan diaktifkan di server utama, itu juga harus diaktifkan pada replika untuk memastikan konsistensi dalam perilaku penskalaan penyimpanan.
  • Untuk mengaktifkan pertumbuhan otomatis penyimpanan pada primer, Anda harus terlebih dahulu mengaktifkannya pada replika. Urutan operasi ini sangat penting untuk menjaga integritas replikasi.
  • Sebaliknya, jika Anda ingin menonaktifkan autogrow penyimpanan, mulailah dengan menonaktifkannya di server utama sebelum replika untuk menghindari komplikasi replikasi.

Cadangkan dan Pulihkan

Saat mengelola cadangan dan pemulihan untuk instans server fleksibel Azure Database for PostgreSQL Anda, penting untuk mengingat peran server saat ini dan sebelumnya dalam skenario promosi yang berbeda. Berikut hal-hal penting untuk diingat:

Promosikan ke server utama

  1. Tidak ada cadangan yang diambil dari replika baca: Cadangan tidak pernah diambil dari server replika baca, terlepas dari peran mereka sebelumnya.

  2. Preservasi cadangan sebelumnya: Jika server pernah menjadi primer dan memiliki cadangan yang diambil selama periode tersebut, cadangan tersebut dipertahankan. Mereka akan dipertahankan hingga periode retensi yang ditentukan pengguna.

  3. Pulihkan Pembatasan Operasi: Bahkan jika pencadangan sebelumnya ada untuk server yang telah beralih ke replika baca, operasi pemulihan dibatasi. Anda hanya dapat memulai operasi pemulihan ketika server telah dipromosikan kembali ke peran utama.

Untuk kejelasan, berikut adalah tabel yang mengilustrasikan poin-poin ini:

Peran server Pencadangan diambil Pulihkan yang diperbolehkan
Primer Ya Ya
Replika baca Tidak Tidak
Replika baca dipromosikan ke primer Ya Ya

Promosikan ke server independen dan hapus dari replikasi

Meskipun server adalah replika baca, tidak ada cadangan yang diambil. Namun, setelah dipromosikan ke server independen, server yang dipromosikan dan server utama memiliki cadangan yang diambil, dan pemulihan diizinkan pada keduanya.

Jaringan

Replika baca mendukung semua opsi jaringan yang didukung oleh Azure Database for PostgreSQL Flexible Server.

Penting

Komunikasi dua arah antara server utama dan replika baca sangat penting untuk penyiapan server fleksibel Azure Database for PostgreSQL. Harus ada ketentuan untuk mengirim dan menerima lalu lintas pada port tujuan 5432 dalam subnet jaringan virtual Azure.

Persyaratan di atas tidak hanya memfasilitasi proses sinkronisasi tetapi juga memastikan berfungsinya mekanisme promosi di mana replika mungkin perlu berkomunikasi dalam urutan terbalik - dari replika ke primer - terutama selama promosi ke operasi utama. Selain itu, koneksi ke akun penyimpanan Azure yang menyimpan arsip Write-Ahead Logging (WAL) harus diizinkan untuk menegakkan durabilitas data dan memungkinkan proses pemulihan yang efisien.

Untuk informasi selengkapnya tentang cara mengonfigurasi akses privat (integrasi jaringan virtual) untuk replika baca Anda dan memahami implikasi untuk replikasi di seluruh wilayah Azure dan jaringan virtual dalam konteks jaringan privat, lihat Replikasi di seluruh wilayah Azure dan jaringan virtual dengan halaman jaringan privat.

Mitigasi masalah slot replikasi

Dalam kasus yang jarang terjadi, jeda tinggi yang disebabkan oleh slot replikasi dapat menyebabkan peningkatan penggunaan penyimpanan di server utama karena akumulasi file WAL. Jika penggunaan penyimpanan mencapai 95% atau kapasitas yang tersedia berada di bawah 5 GiB, server secara otomatis beralih ke mode baca-saja untuk mencegah kesalahan penuh disk.

Karena mempertahankan kesehatan dan fungsionalitas server utama adalah prioritas, dalam kasus tepi seperti itu, slot replikasi mungkin dihilangkan untuk memastikan server utama tetap beroperasi untuk lalu lintas baca dan tulis. Jadi, replikasi beralih ke mode pengiriman log berbasis file, yang dapat mengakibatkan jeda replikasi yang lebih tinggi.

Sangat penting untuk memantau penggunaan penyimpanan dan lag replikasi dengan cermat dan mengambil tindakan yang diperlukan untuk mengurangi potensi masalah sebelum meningkat.

Parameter server

Ketika replika baca dibuat, replika tersebut mewarisi parameter server dari server utama. Hal ini untuk memastikan titik awal yang konsisten dan andal. Namun, setiap perubahan pada parameter server di server utama yang dibuat setelah membuat replika baca tidak direplikasi secara otomatis. Perilaku ini menawarkan keuntungan dari penyetelan individu replika baca, seperti meningkatkan performanya untuk operasi baca intensif tanpa memodifikasi parameter server utama. Meskipun ini memberikan opsi fleksibilitas dan kustomisasi, ini juga mengharuskan manajemen yang cermat dan manual untuk menjaga konsistensi antara primer dan replikanya ketika keseragaman parameter server diperlukan.

Administrator dapat mengubah parameter server pada server replika baca dan mengatur nilai yang berbeda dari pada server utama. Satu-satunya pengecualian adalah parameter yang mungkin memengaruhi pemulihan replika, yang disebutkan juga di bagian "Penskalaan" di bawah ini: max_connections, , max_prepared_transactionsmax_locks_per_transaction, max_wal_senders, max_worker_processes. Untuk memastikan pemulihan replika baca mulus dan tidak mengalami batasan memori bersama, parameter khusus ini harus selalu diatur ke nilai yang setara dengan atau lebih besar dari yang dikonfigurasi di server utama.

Sisik

Anda bebas untuk meningkatkan dan menurunkan skala komputasi (vCores), mengubah tingkat layanan dari Tujuan Umum ke Memori yang Dioptimalkan (atau sebaliknya) dan meningkatkan penyimpanan, tetapi peringatan berikut berlaku.

Untuk penskalaan komputasi:

  • Server fleksibel Azure Database for PostgreSQL mengharuskan beberapa parameter pada replika lebih besar dari atau sama dengan pengaturan pada primer untuk memastikan bahwa replika tidak kehabisan memori bersama selama pemulihan. Parameter yang terpengaruh adalah: max_connections, , max_prepared_transactions, max_locks_per_transaction, max_wal_sendersmax_worker_processes.

  • Peningkatan skala: Pertama, tingkatkan skala komputasi replika, lalu tingkatkan skala utama.

  • Menurunkan skala: Pertama-tama turunkan skala komputasi utama, lalu turunkan skala replika.

  • Komputasi pada primer harus selalu sama atau lebih kecil dari komputasi pada replika terkecil.

Untuk penskalaan penyimpanan:

  • Peningkatan skala: Pertama-tama tingkatkan penyimpanan replika, lalu tingkatkan skala utama.

  • Ukuran penyimpanan pada primer harus selalu sama atau lebih kecil dari ukuran penyimpanan pada replika terkecil.

Konten terkait