Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Datastream menggunakan log transaksi WAL (Write Ahead Log) PostgreSQL untuk
membaca streaming PostgreSQL. Log disimpan dalam file WAL di server database.
Setiap data dalam log WAL mewakili satu perubahan pada data sebenarnya di salah satu
tabel dalam database.
Menetapkan parameter konfigurasi untuk file WAL PostgreSQL
Sebaiknya terapkan setelan konfigurasi berikut ke database PostgreSQL Anda:
max_slot_wal_keep_size: tetapkan parameter ini (hanya tersedia untuk PostgreSQL
13 dan yang lebih baru) untuk membatasi jumlah penyimpanan yang digunakan oleh slot replikasi.
Hal ini sangat penting untuk transaksi yang berjalan lama, yang dalam
kasus ekstrem, dapat menyebabkan ukuran file WAL menghabiskan seluruh penyimpanan
dan membuat database error.
statement_timeout: tetapkan parameter ini ke nilai yang dipilih untuk mengurangi
latensi yang disebabkan oleh transaksi yang berjalan lama. Anda juga dapat menggunakan
statement_timeout sebagai tindakan pencegahan alternatif untuk database yang
tidak mendukung max_slot_wal_keep_size.
wal_sender_timeout: tetapkan parameter ini ke 0 (untuk menonaktifkan waktu tunggu) atau ke nilai yang lebih besar dari atau sama dengan 10 menit.
Jika Anda berencana membuat lebih dari 10 aliran data, atau jumlah slot replikasi
logika yang digunakan oleh resource lain selain jumlah aliran data
yang direncanakan melebihi 10, pastikan untuk mengubah parameter berikut:
max_replication_slots: meningkatkan nilai parameter ini, bergantung pada
jumlah slot replikasi yang ditetapkan untuk database Anda (Anda memerlukan 1
slot replikasi per aliran). Anda hanya dapat menetapkan max_replication_slots
saat server dimulai.
max_wal_senders: meningkatkan nilai parameter ini, sehingga
lebih besar dari nilai parameter max_replication_slots.
Anda hanya dapat menetapkan max_wal_senders saat memulai server.
Mengoptimalkan file log WAL
Untuk menghindari latensi tinggi pada streaming dan pertumbuhan cepat dalam ukuran file log WAL saat mereplikasi data dari sumber PostgreSQL, pertimbangkan untuk menerapkan tindakan pencegahan berikut:
Hindari operasi besar yang berjalan lama karena dapat meningkatkan
ukuran file WAL Anda secara signifikan.
Gunakan tabel UNLOGGED atau TEMPORARY selama operasi batch.
Periksa konfigurasi WAL Anda dan pertimbangkan untuk mengurangi frekuensi pemeriksaan.
Untuk mengetahui informasi selengkapnya, lihat
Konfigurasi WAL
Periksa operasi DELETE yang besar dan pertimbangkan untuk menggantinya dengan
operasi TRUNCATE. Tindakan ini dapat mengurangi data file WAL secara signifikan,
tetapi Anda harus berhati-hati, karena Datastream tidak mereplikasi
operasi TRUNCATE.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-12 UTC."],[[["\u003cp\u003eDatastream utilizes the PostgreSQL WAL transaction log, stored in WAL files, to capture changes made to the database tables.\u003c/p\u003e\n"],["\u003cp\u003eSetting the \u003ccode\u003emax_slot_wal_keep_size\u003c/code\u003e parameter is recommended to prevent the WAL file from consuming excessive storage, especially during long-running transactions, though it is not supported by certain databases like Cloud SQL and AlloyDB.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003estatement_timeout\u003c/code\u003e parameter can be configured to mitigate latency from prolonged transactions, serving as an alternative control for databases not supporting \u003ccode\u003emax_slot_wal_keep_size\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eIf you need more than 10 streams, you must adjust the \u003ccode\u003emax_replication_slots\u003c/code\u003e and \u003ccode\u003emax_wal_senders\u003c/code\u003e parameters based on the number of streams or replication slots you are using in your database.\u003c/p\u003e\n"],["\u003cp\u003eSetting \u003ccode\u003ewal_sender_timeout\u003c/code\u003e to \u003ccode\u003e0\u003c/code\u003e or a value of 10 minutes or greater is advised for better performance.\u003c/p\u003e\n"]]],[],null,["# Work with PostgreSQL database WAL log files\n\nDatastream uses the PostgreSQL WAL (Write Ahead Log) transaction log to\nread PostgreSQL streams. The log is stored in WAL files on the database server.\nEach record in the WAL log represents a single change to the actual data in one\nof the tables in the database.\n\nSet configuration parameters for PostgreSQL WAL files\n-----------------------------------------------------\n\nIt is recommended that you apply the following configuration settings to your\nPostgreSQL database:\n\n- `max_slot_wal_keep_size`: set this parameter (available only for PostgreSQL\n 13 and above) to limit the amount of storage used by the replication slot.\n This is particularly important for long-running transactions, which, in\n extreme cases, can lead to the WAL file size taking up the entire storage\n and crashing the database.\n\n | **Note:** Some managed databases, such as Cloud SQL and AlloyDB for PostgreSQL, don't support `max_slot_wal_keep_size`.\n- `statement_timeout`: set this parameter to a selected value to reduce\n latency caused by long-running transactions. You can also use\n `statement_timeout` as an alternative precaution measure for databases that\n don't support `max_slot_wal_keep_size`.\n\n- `wal_sender_timeout`: set this parameter to `0` (to disable the\n timeout) or to a value greater than or equal to 10 minutes.\n\nIf you plan to create more than 10 streams, or the number of logical replication\nslots that is used by other resources in addition to the number of planned\nstreams exceeds 10, make sure to modify the following parameters:\n\n- `max_replication_slots`: increase the value of this parameter, depending on\n the number of replication slots set for your database (you need 1\n replication slot per stream). You can only set `max_replication_slots`\n at server start.\n\n- `max_wal_senders`: increase the value of this parameter, so that it's\n greater than the value of the `max_replication_slots` parameter.\n You can only set `max_wal_senders` when you start the server.\n\nOptimize WAL log files\n----------------------\n\nTo avoid high latency of your streams and rapid growth in the size of WAL log\nfiles when replicating data from a PostgreSQL source, consider applying the\nfollowing precautions:\n\n- Avoid large long-running operations because they can significantly increase the size of your WAL file.\n- Use `UNLOGGED` or `TEMPORARY` tables during batch operations.\n- Check your WAL configuration and consider reducing the checkpoint frequency. For more information, see [WAL configuration](https://www.postgresql.org/docs/current/wal-configuration.html)\n- Check for large `DELETE` operations and consider replacing them with `TRUNCATE` operations. Doing this can significantly reduce WAL file data, however you need to be cautious, because Datastream doesn't replicate `TRUNCATE` operations.\n\nWhat's next\n-----------\n\n- Learn more about [PostgreSQL as a\n source](/datastream/docs/sources-postgresql).\n- Learn more about [configuring a source PostgreSQL\n database](/datastream/docs/configure-your-source-postgresql-database)."]]
