max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum slot replikasi yang ditentukan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. Slot replikasi akan ditandai sebagai gagal, dan segmen akan dilepaskan untuk dihapus atau didaur ulang jika ruang sebanyak itu ditempati oleh WAL pada disk. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum slot replikasi yang ditentukan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. Slot replikasi akan ditandai sebagai gagal, dan segmen akan dilepaskan untuk dihapus atau didaur ulang jika ruang sebanyak itu ditempati oleh WAL pada disk. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_slot_wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran WAL maksimum yang dapat dicadangkan oleh slot replikasi. |
| Jenis data |
bilangan bulat |
| Nilai standar |
-1 |
| Nilai yang diizinkan |
-1 |
| Jenis parameter |
baca-saja |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_size
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur ukuran file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
400 |
| Nilai yang diizinkan |
400 |
| Jenis parameter |
baca-saja |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_segments
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
25 |
| Nilai yang diizinkan |
25 |
| Jenis parameter |
baca-saja |
| Documentation |
|
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Menentukan jumlah maksimum slot replikasi yang dapat didukung server. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
2-262143 |
| Jenis parameter |
statik |
| Documentation |
max_replication_slots |
Catatan khusus Azure
Nilai default untuk max_replication_slots parameter adalah 10. Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4 max_replication_slots agar ketersediaan tinggi berfungsi dengan baik.
Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_replication_slots menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_replication_slot. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
max_wal_senders
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah maksimum proses pengirim WAL yang berjalan secara bersamaan. |
| Jenis data |
bilangan bulat |
| Nilai standar |
10 |
| Nilai yang diizinkan |
5-100 |
| Jenis parameter |
statik |
| Documentation |
max_wal_senders |
Catatan khusus Azure
Nilai default untuk parameter server max_wal_senders yang ditetapkan saat Anda menyediakan instans Azure Database for PostgreSQL server fleksibel tidak boleh dikurangi menjadi kurang dari 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ketika mempertimbangkan kebutuhan untuk meningkatkan max_wal_senders ke nilai yang jauh lebih tinggi untuk dapat mengatasi replikasi logis dari sejumlah besar tabel, ingatlah poin-poin penting berikut:
- Mereplikasi sejumlah besar tabel secara logis tidak selalu memerlukan sejumlah besar pengirim WAL.
- Satu-satunya alasan mengapa Anda memerlukan pengirim WAL terpisah per tabel atau grup tabel adalah jika Anda memerlukan langganan terpisah untuk setiap tabel atau grup tersebut.
- Berapa pun jumlah pengirim WAL yang digunakan untuk replikasi fisik dan logis, mereka semua menjadi aktif sekaligus, setiap kali backend menulis sesuatu ke log write-ahead. Ketika itu terjadi, pengirim WAL yang ditetapkan untuk melakukan replikasi logis semuanya bersiap untuk:
- Dekodekan semua rekaman baru di WAL,
- Memfilter rekaman log yang tidak mereka minati,
- Replikasi data yang relevan dengan masing-masing dari mereka.
- Pengirim WAL mirip dengan koneksi dalam arti bahwa, jika mereka menganggur, tidak masalah berapa banyak yang ada. Namun, jika mereka aktif, mereka hanya akan bersaing untuk sumber daya yang sama dan performanya bisa menjadi sangat buruk. Ini terutama berlaku untuk pengirim dengan replikasi logis, karena decoding logis membutuhkan banyak sumber daya CPU. Setiap pekerja harus mendekode seluruh log write-ahead (WAL), meskipun hanya mereplikasi operasi yang memengaruhi satu tabel, dan itu mewakili persentase kecil dari semua data di log tersebut. Untuk replikasi fisik, tidak terlalu penting, karena pengirim WAL tidak mengonsumsi CPU begitu intensif, dan mereka cenderung dibatasi oleh bandwidth jaringan terlebih dahulu.
- Oleh karena itu, secara umum, lebih baik tidak memiliki lebih banyak pengirim WAL daripada vCore.
- Ini adalah praktik yang baik untuk menambahkan ruang bagi beberapa pengirim WAL tambahan untuk mengakomodasi pertumbuhan di masa depan atau lonjakan sementara dalam koneksi replikasi. Dua contoh berikut mungkin membantu mengilustrasikannya dengan lebih baik.
- Untuk server dengan 8 vCores, HA dimatikan, 2 replika baca, dan 3 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (0) + slot fisik untuk replika baca (2) + slot logis (3) + beberapa tambahan untuk pertumbuhan di masa mendatang, dan mempertimbangkan jumlah vCores yang tersedia (1) = 6.
- Untuk server dengan 16 vCores, HA diaktifkan, 4 replika baca, dan 5 slot replikasi logis, Anda mungkin ingin mengonfigurasi
max_wal_senders sebagai jumlah slot fisik untuk HA (2) + slot fisik untuk replika baca (4) + slot logis (5) + beberapa tambahan untuk pertumbuhan ke depan, mempertimbangkan vCores yang tersedia (2) = 13.
- Jika Anda mengaktifkan ketersediaan tinggi, Anda memerlukan minimal 4
max_wal_senders agar ketersediaan tinggi berfungsi dengan baik. Untuk server yang telah diaktifkan ketersediaan tingginya, dengan tambahan 5 replika baca dan 12 slot replikasi logis, Anda mungkin ingin mengonfigurasi max_wal_senders menjadi 21. Ini karena setiap replika baca dan setiap slot replikasi logis memerlukan satu max_wal_senders. Oleh karena itu, dibutuhkan total 1 (slot) * 5 (replika baca) + 12 (slot replikasi logis) + 4 (agar ketersediaan tinggi berfungsi dengan baik) = 21.
- Jika Anda masih menganggap bahwa nilai maksimum yang diizinkan untuk parameter ini terlalu rendah untuk kebutuhan Anda, hubungi kami, jelaskan skenario Anda secara rinci dan jelaskan apa yang Anda anggap bahwa akan menjadi nilai minimum yang dapat diterima yang Anda perlukan agar skenario Anda berkinerja dengan benar.
track_commit_timestamp
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengumpulkan waktu penerapan transaksi. |
| Jenis data |
Boolean |
| Nilai standar |
off |
| Nilai yang diizinkan |
on,off |
| Jenis parameter |
statik |
| Documentation |
catat_waktu_komit |
wal_keep_segments
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur jumlah file WAL yang disimpan untuk server siaga. |
| Jenis data |
bilangan bulat |
| Nilai standar |
25 |
| Nilai yang diizinkan |
25 |
| Jenis parameter |
baca-saja |
| Documentation |
|
wal_sender_timeout
| Attribute |
Nilai |
| Kategori |
Server Replikasi / Pengiriman |
| Description |
Mengatur waktu maksimum untuk menunggu replikasi WAL. |
| Jenis data |
bilangan bulat |
| Nilai standar |
60000 |
| Nilai yang diizinkan |
0-2147483647 |
| Jenis parameter |
dynamic |
| Documentation |
wal_sender_timeout |