Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 serupa dengan instans server biasa dari Azure Database for PostgreSQL yang fleksibel. 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 berfungsi untuk meningkatkan performa dan memperluas skala beban kerja yang intensif dalam membaca. Beban kerja baca dapat diisolasi ke replika, sementara beban kerja tulis dapat diarahkan ke server 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 memindahkan kueri bermanfaat, dan sedikit jeda dapat ditoleransi. Mereka dioptimalkan untuk memberikan pembaruan mendekati waktu nyata dari sumber utama untuk sebagian besar beban kerja, menjadikannya solusi terbaik yang banyak menuntut pembacaan. 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 yang berada di wilayah yang sama dengan replika utama memiliki jeda lebih sedikit daripada geo-replika, karena geo-replika sering mengalami 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.
Nota
Untuk sebagian besar beban kerja, replika baca menawarkan pembaruan hampir waktu nyata dari server utama. Namun, dengan beban kerja utama yang intensif penulisan berat secara persisten, kelambatan replikasi dapat terus meningkat dan mungkin hanya bisa menyusul beban utama tersebut. Ini juga dapat meningkatkan penggunaan penyimpanan di primer karena file WAL hanya dihapus setelah diterima di replika. Jika situasi ini berlanjut, dengan menghapus dan membuat ulang replika baca setelah beban kerja intensif penulisan selesai, Anda dapat mengembalikan replika ke kondisi yang optimal untuk memperbaiki jeda. Replika baca asinkron tidak sesuai untuk beban kerja tulis berat tersebut. Saat mengevaluasi replika baca untuk aplikasi Anda, pantau keterlambatan pada replika untuk siklus beban kerja aplikasi lengkap, mulai dari waktu puncak hingga waktu non-puncak, untuk menilai kemungkinan keterlambatan dan RTO/RPO yang diharapkan di berbagai titik siklus beban kerja.
Buat replika
Server utama untuk instans 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 Azure Database for PostgreSQL tersedia. Kemampuan untuk membuat replika sekarang meluas ke beberapa wilayah Azure di sovereign cloud. Lihat artikel Replikasi geografis untuk daftar wilayah sovereign cloud tempat Anda dapat membuat replika.
Saat Anda memulai alur kerja pembuatan replika, dibuatlah sebuah instans kosong server fleksibel Azure Database for PostgreSQL. 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 dari instans utama, yang kemudian ditransmisikan melalui jaringan. Oleh karena itu, waktu pembuatan mungkin berkisar dari menit hingga beberapa jam, tergantung pada ukuran instans 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 instans 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 keadaan 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 instans server fleksibel Azure Database for PostgreSQL, penting untuk memahami konfigurasi server yang dapat disesuaikan, yang diwarisi dari server utama, dan batasan terkait.
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
- Tier, ukuran penyimpanan: Untuk operasi "promosikan ke server primer", harus sama dengan server primer. Operasi "promosikan ke server independen dan menghapus dari sistem replikasi" bisa sama atau lebih tinggi dari server 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.
- Tier, ukuran penyimpanan: Untuk operasi "promosikan ke server primer", harus sama dengan server primer. Operasi "promosikan ke server independen dan menghapus dari sistem replikasi" bisa sama atau lebih tinggi dari server utama.
- Tingkat performa (IOPS): Dapat disesuaikan.
- metode Authentication: Dapat disesuaikan, opsi termasuk beralih dari autentikasi PostgreSQL ke Microsoft Entra.
- Parameter server: Sebagian besar dapat disesuaikan. Namun, yang memengaruhi ukuran memori bersama harus selaras dengan yang utama, terutama untuk skenario potensial "promosi menjadi 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 pengguna, lihat dokumentasi untuk pertimbangan lain.
Membuat replika baca berjenjang
Replika baca berkala dapat membantu mendistribusikan beban kerja baca, mengurangi beban di server utama. Menyebarkan replika baca di berbagai wilayah (replika baca lintas wilayah) dapat membantu mendistribusikan lalu lintas baca lebih dekat dengan pengguna di berbagai geografi. Anda dapat menambahkan replika baca berjenjang ke server Azure Database for PostgreSQL. Ini memungkinkan Anda membuat replika baca baru di atas replika baca yang ada, dengan replika baca yang ada bertindak sebagai sumber untuk tingkat berikutnya.
Replika baca tingkat pertama secara asinkron mereplikasi data dari server utama. Replika baca tingkat kedua kemudian dapat dibuat menggunakan replika tingkat pertama sebagai sumbernya, membentuk hierarki replikasi dua tingkat. Arsitektur ini meningkatkan skalabilitas, mendukung hingga 30 server replika baca dengan server utama yang memungkinkan hingga 5 replika baca, dan masing-masing replika tersebut mendukung 5 replika tambahan. Untuk menambahkan replika baca berjenjang ke instans server fleksibel Azure Database for PostgreSQL, pilih replika baca yang ada (dibuat dari server utama), dan navigasi ke tab 'Replikasi' dan klik 'Buat replika'.
Misalnya, server utama Anda dapat memiliki hingga 5 replika baca (tingkat 1). Salah satu dari ini, misalnya read-replica-1, dapat bertindak sebagai sumber untuk replika lain read-replica-2 yang menjadi bagian dari level 2.
Pertimbangan utama:
- Hingga 5 replika baca dapat dibuat per replika baca sumber, dengan dukungan untuk 2 tingkat replikasi.
- Operasi pengalihan didukung antara replika baca perantara (sumber) dan replika baca bertingkat.
- Peningkatan ke operasi utama tidak didukung untuk replika baca menengah dengan replika baca berantai.
- Titik akhir virtual tidak didukung untuk replikasi berjenjang.
- Replika baca bertingkat didukung pada replika perantara dengan PostgreSQL versi 14 ke atas.
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:
-
Direct ke Instans Replika: Anda dapat terhubung ke replika menggunakan nama host dan akun pengguna yang valid, seperti yang Anda lakukan pada instans server Azure Database for PostgreSQL fleksibel reguler. Untuk server bernama myreplica dengan nama pengguna admin myadmin, Anda dapat terhubung ke replika menggunakan
psql.
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 variabel libpq dan string koneksi yang disesuaikan untuk konsol bash.
- Melalui Titik Akhir Virtual: Ada metode koneksi alternatif menggunakan Titik Akhir Virtual, seperti yang dijelaskan 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 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, server utama 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 jeda replikasi dan status 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
layanan 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_activityserver keON. Parameter ini bersifat dinamis dan tidak memerlukan mulai ulang instans.
Replikasi Logis
| Nama tampilan | ID metrik | Unit | Description | Dimensi | Default diaktifkan |
|---|---|---|---|---|---|
| Keterlambatan Replikasi Logis Maksimal | logical_replication_delay_in_bytes |
Bita | Keterlambatan maksimum di seluruh slot replikasi logika. | Tidak berlaku | Yes |
Replikasi
| Nama tampilan | ID metrik | Unit | Description | Dimensi | Default diaktifkan |
|---|---|---|---|---|---|
| Lag Replikasi Fisik Maks | physical_replication_delay_in_bytes |
Bita | Lag maksimum di semua slot replikasi fisik asinkron. | Tidak berlaku | Yes |
| Baca Lag Replika | physical_replication_delay_in_seconds |
Detik | Baca lag replika dalam hitung detik. | Tidak berlaku | Yes |
Untuk mempelajari selengkapnya, lihat artikel cara membaca replika.
Metrik Max Physical Replication Lag menunjukkan keterlambatan dalam byte antara replika primer dan replika 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 Keterlambatan 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.
Nota
Jika server primer atau replika baca dimulai ulang, waktu yang diperlukan untuk memulai ulang dan mengejar ketinggalan tercermin dalam metrik Lag Replika.
Status replikasi
Untuk memantau kemajuan dan status replikasi dan mempromosikan operasi, lihat kolom Replication 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 API GetReplica, status muncul sebagai ReplicationState di tas properti replica.
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 | N/A |
| Penyediaan | Replika baca sedang disediakan dan replikasi antara kedua server belum dimulai. Hingga penyediaan selesai, Anda tidak dapat tersambung ke replika baca. | N/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 |
| Kerusakan | 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." | N/A | N/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 tindakan menghentikan, dapat diterapkan pada 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.
-
Tingkatkan versi utama untuk instans server fleksibel Azure Database for PostgreSQL mengharuskan menghapus replika baca dan replika baca berjenjang yang 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.
- 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
Sebuah read replica dibuat sebagai instans server fleksibel Azure Database for PostgreSQL yang baru. Server yang sudah ada tidak dapat dibuat menjadi replika.
Pemindahan sumber daya
Pengguna dapat membuat replika baca di grup sumber daya yang berbeda dari sumber utama. Namun, memindahkan replika baca ke grup sumber daya lain setelah pembuatannya tidak didukung. Selain itu, memindahkan replika ke langganan yang berbeda, dan memindahkan server utama yang memiliki replika baca ke grup sumber daya atau langganan lain, tidak didukung.
Pengembangan 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 penyimpanan autogrow memungkinkan penyimpanan database bertambah secara otomatis untuk mencegah kehabisan ruang, yang dapat mengakibatkan kerusakan database. Berikut cara mengelola pengaturan pertumbuhan otomatis penyimpanan secara efektif:
- Anda dapat mengaktifkan autogrow penyimpanan pada replika mana pun tanpa memandang 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 server utama, Anda harus terlebih dahulu mengaktifkannya pada replika data. Urutan operasi ini sangat penting untuk menjaga integritas replikasi.
- Sebaliknya, jika Anda ingin menonaktifkan peningkatan otomatis penyimpanan, mulailah dengan menonaktifkannya di server utama sebelum pada server replika untuk menghindari komplikasi replikasi.
Cadangkan dan Pulihkan
Saat mengelola pencadangan dan pemulihan untuk instans server fleksibel Azure Database for PostgreSQL Anda, penting untuk diingat peran server yang sekarang dan sebelumnya dalam skenario promosi yang berbeda. Berikut hal-hal penting untuk diingat:
Promosikan ke server utama
Tidak ada cadangan yang diambil dari replika baca: Cadangan tidak pernah diambil dari server replika baca, terlepas dari peran mereka di masa lalu.
Preservasi cadangan yang lampau: Jika server pernah berfungsi sebagai server primer dan memiliki cadangan yang dibuat selama periode tersebut, cadangan tersebut tetap dipertahankan. Mereka akan dipertahankan hingga periode retensi yang ditentukan pengguna.
Pembatasan Operasi Pemulihan: Bahkan jika cadangan sebelumnya tersedia untuk server yang telah beralih ke replika baca, operasi pemulihan tetap 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 | Pemulihan diizinkan |
|---|---|---|
| Primary | Yes | Yes |
| Replika baca | Tidak. | Tidak. |
| Replika baca dipromosikan menjadi instansi utama | Yes | Yes |
Promosikan ke server independen dan hapus dari replikasi
Meskipun server adalah replika baca, tidak ada cadangan yang dilakukan. Namun, setelah dipromosikan ke server independen, cadangan dibuat pada server yang dipromosikan dan server utama, dan pemulihan diizinkan pada kedua server tersebut.
Jaringan
Replika baca mendukung semua opsi jaringan yang didukung oleh instans server fleksibel Azure Database for PostgreSQL.
Penting
Komunikasi dua arah antara server utama dan replika baca sangat penting untuk penyiapan 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 halaman Replikasi di seluruh wilayah Azure dan jaringan virtual dengan 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_transactions, max_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. Sebelum menurunkan nilai parameter pada server replika baca, pastikan bahwa lag replikasi minimal atau replika sepenuhnya terjebak dengan server utama, untuk menghindari potensi masalah replikasi atau pemulihan.
Scale
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:
layanan Azure Database for PostgreSQL mengharuskan beberapa parameter pada replika lebih besar dari atau sama dengan pengaturan pada utama untuk memastikan bahwa replika tidak mengalami 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.