Düzeltme Öner

Replikasyon

Bu bölümde verilen ayarlar dahili streaming replikasyon özelliğinin davranışını kontrol eder. Sunucular, primary ya da standby bir sunucu olabilir. Primary sunucular veri gönderebilir, standby ise replike verilerin alıcılarıdır. Standby sunucular Cascading replikasyon kullanıldığında alıcının (receiver) yanı sıra gönderici (senders) de olabilir.

Sending Sunucular

Bu başlıkta verilen parametreler, replike verileri bir veya daha fazla standby sunucuya gönderen sunucuda ayarlanır. Primary, her durumda gönderen bir sunucu olduğundan dolayı bu parametreler her zaman primary üzerinde ayarlanmalıdır. Bu parametrelerin rolü ve anlamı bir standby primary olduktan sonra değişmez.

max_wal_senders

type: integer default: 10 min: 0 max: 262143 context: postmaster restart: Gerektirir
<p>Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is 10. The value 0 means replication is disabled. Abrupt disconnection of a streaming client might leave an orphaned connection slot behind until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. Also, wal_level must be set to replica or higher to allow connections from standby servers.</p><p>When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server.</p>
Standby sunuculardan veya streaming tabanlı yedekleme istemcilerinden gelen maksimum senkron bağlantı sayısını (örneğin, aynı anda çalışan maksimum WAL sender süreci sayısı) belirtir. Öntanımlı değeri 10’dur. 0 değeri replikasyonun devre dışı bırakıldığı anlamına gelir. Bir streaming istemcisinin bağlantısının aniden kesilmesi, zaman aşımına ulaşılıncaya kadar orphan bir bağlantı slotuna sebep olabilir. Bu sebepten dolayı parametre, bağlantısı kesilen istemcilerin yeniden bağlanabilmesi için beklenen maksimum istemci sayısından fazla ayarlanmalıdır. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir. Standby sunucu bağlantılarına izin vermek için wal_level paremetresi replica veya daha yüksek seviyede ayarlanmalıdır.

Bir standby sunucuda bu parametreyi primary sunucudakiyle aynı veya daha yüksek bir değere ayarlamalısınız. Aksi takdirde standby sunucusunda sorgulara izin verilmeyecektir.

max_replication_slots

type: integer default: 10 min: 0 max: 262143 context: postmaster restart: Gerektirir
<p>Specifies the maximum number of replication slots (see streaming-replication-slots) that the server can support. The default is 10. This parameter can only be set at server start. Setting it to a lower value than the number of currently existing replication slots will prevent the server from starting. Also, wal_level must be set to replica or higher to allow replication slots to be used.</p>
Sunucunun destekleyebileceği maksimum replikasyon slotu sayısını belirtir. Öntanımlı değeri 10’dur. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir. Mevcut replikasyon slotlarının sayısından daha düşük bir değere ayarlamak, sunucunun başlamasını engeller. Ayrıca, replikasyon slotlarının kullanılmasına izin vermek için wal_level paremetresi replica veya daha yüksek seviyede ayarlanmalıdır

wal_keep_size

type: integer default: 0 MB min: 0 max: 2147483647 unit: MB context: sighup
<p>Specifies the minimum size of past log file segments kept in the pg_wal directory, in case a standby server needs to fetch them for streaming replication. If a standby server connected to the sending server falls behind by more than wal_keep_size megabytes, the sending server might remove a WAL segment still needed by the standby, in which case the replication connection will be terminated. Downstream connections will also eventually fail as a result. (However, the standby server can recover by fetching the segment from archive, if WAL archiving is in use.)</p><p>This sets only the minimum size of segments retained in pg_wal; the system might need to retain more segments for WAL archival or to recover from a checkpoint. If wal_keep_size is zero (the default), the system doesn’t keep any extra segments for standby purposes, so the number of old WAL segments available to standby servers is a function of the location of the previous checkpoint and status of WAL archiving. If this value is specified without units, it is taken as megabytes. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
pg_wal dizininde tutulan geçmiş log dosyası segmentlerinin minimum miktarını belirtir. Standby sunucu bunları streaming replikasyon için kullanır. Standby, sending sunucunundan wal_keep_size megabayttan daha fazla geride kalırsa, sending sunucu standby’ın ihtiyacı olan bir WAL segmentini silebilir. Bu durumda replikasyon bağlantısı sonlandırılır. (WAL arşivleme aktifse, standby sunucu segmentleri arşivden alarak kurtarabilir.)

Bu parametre yalnızca pg_wal‘da tutulan minimum segment boyutunu ayarlar. Sistemin WAL arşivleme veya bir checkpoint’ten kurtarmak için daha fazla segment tutması gerekebilir. wal_keep_size 0 ise (varsayılan), sistem standby amaçları için fazladan segment tutmaz. Bu değer birimsiz belirtilirse megabayt olarak alınır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

max_slot_wal_keep_size

type: integer default: -1 min: -1 max: 2147483647 unit: MB context: sighup
<p>Specify the maximum size of WAL files that replication slots are allowed to retain in the pg_wal directory at checkpoint time. If max_slot_wal_keep_size is -1 (the default), replication slots may retain an unlimited amount of WAL files. Otherwise, if restart_lsn of a replication slot falls behind the current LSN by more than the given size, the standby using the slot may no longer be able to continue replication due to removal of required WAL files. You can see the WAL availability of replication slots in pg_replication_slots.</p>
Replikasyon slotlarının checkpoint zamanında pg_wal dizininde tutmasına izin verilen maksimum WAL dosyası boyutunu belirtir.max_slot_wal_keep_size = -1 ayarında (varsayılan), replikasyon slotları sınırsız miktarda WAL dosyası tutabilir. Bir replikasyon slotunun restart_lsn değeri geçerli LSN’nin verilen boyuttan daha fazla gerisinde kalırsa slotu kullanan standby gerekli WAL dosyalarının silinmesinden dolayı replikasyona devam edemez. Replikasyon slotlarının WAL kullanabilirliğini pg_replication_slots ile görebilirsiniz.

wal_sender_timeout

type: integer default: 1 min min: 0 max: 2147483647 unit: ms context: user
<p>Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism.</p><p>With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection.</p>
Bu süreden daha uzun süre etkin olmayan replikasyon bağlantılarını sonlandırılır. Gönderen sunucunun standby’da bir çökmeyi veya ağ kesintisini algılaması için kullanışlıdır. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Öntanımlı değeri 60 saniyedir. 0 değeri, zaman aşımı mekanizmasını devre dışı bırakır.

Birden çok coğrafi konuma dağıtılmış bir kümede, her bir konum için farklı değerler kullanmak küme yönetiminde esneklik sağlar. Daha küçük bir değer, düşük gecikmeli ağ bağlantısına sahip bir standby’da hızlı arıza tespiti için kullanışlıdır. Daha büyük bir değer, yüksek gecikmeli ağ bağlantısıyla uzak bir konumda bulunan standby’ın sağlığını daha iyi değerlendirmeye yardımcı olur.

track_commit_timestamp

type: bool default: off context: postmaster restart: Gerektirir
<p>Record commit time of transactions. This parameter can only be set in postgresql.conf file or on the server command line. The default value is off.</p>
Transaction’ların commit süresini kaydeder. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir. Öntanımlı değeri off.

Primary Sunucu

Bu başlıkta verilen parametreler, replikasyon verilerini bir veya daha fazla standby sunucuya gönderecek olan master/primary sunucuda ayarlanır. Bu parametrelere ek olarak, wal_level‘ın primary sunucuda uygun şekilde ayarlanması gerekir. İsteğe bağlı olarak WAL arşivleme de etkinleştirilebilir bkz. Archiving. Standby sunucularda bu parametrelerin değerleri önemsizdir, ancak bir standby’ın primary sunucu olma senaryosuna hazırlık için standby sunucuda da ayarlanabilir.

synchronous_standby_names

type: string context: sighup
<p>Specifies a list of standby servers that can support synchronous replication, as described in synchronous-replication. There will be one or more active synchronous standbys; transactions waiting for commit will be allowed to proceed after these standby servers confirm receipt of their data. The synchronous standbys will be those whose names appear in this list, and that are both currently connected and streaming data in real-time (as shown by a state of streaming in the pg_stat_replication view). Specifying more than one synchronous standby can allow for very high availability and protection against data loss.</p><p>The name of a standby server for this purpose is the application_name setting of the standby, as set in the standby’s connection information. In case of a physical replication standby, this should be set in the primary_conninfo setting; the default is the setting of cluster_name if set, else walreceiver. For logical replication, this can be set in the connection information of the subscription, and it defaults to the subscription name. For other replication stream consumers, consult their documentation.</p><p>This parameter specifies a list of standby servers using either of the following syntaxes:[FIRST] num_sync ( standby_name [, …] )ANY num_sync ( standby_name [, …] )standby_name [, …] where num_sync is the number of synchronous standbys that transactions need to wait for replies from, and standby_name is the name of a standby server. FIRST and ANY specify the method to choose synchronous standbys from the listed servers.</p><p>The keyword FIRST, coupled with num_sync, specifies a priority-based synchronous replication and makes transaction commits wait until their WAL records are replicated to num_sync synchronous standbys chosen based on their priorities. For example, a setting of FIRST 3 (s1, s2, s3, s4) will cause each commit to wait for replies from three higher-priority standbys chosen from standby servers s1, s2, s3 and s4. The standbys whose names appear earlier in the list are given higher priority and will be considered as synchronous. Other standby servers appearing later in this list represent potential synchronous standbys. If any of the current synchronous standbys disconnects for whatever reason, it will be replaced immediately with the next-highest-priority standby. The keyword FIRST is optional.</p><p>The keyword ANY, coupled with num_sync, specifies a quorum-based synchronous replication and makes transaction commits wait until their WAL records are replicated to at leastnum_sync listed standbys. For example, a setting of ANY 3 (s1, s2, s3, s4) will cause each commit to proceed as soon as at least any three standbys of s1, s2, s3 and s4 reply.</p><p>FIRST and ANY are case-insensitive. If these keywords are used as the name of a standby server, its standby_name must be double-quoted.</p><p>The third syntax was used before PostgreSQL version 9.6 and is still supported. It’s the same as the first syntax with FIRST and num_sync equal to 1. For example, FIRST 1 (s1, s2) and s1, s2 have the same meaning: either s1 or s2 is chosen as a synchronous standby.</p><p>The special entry * matches any standby name.</p><p>There is no mechanism to enforce uniqueness of standby names. In case of duplicates one of the matching standbys will be considered as higher priority, though exactly which one is indeterminate.</p><p>Each standby_name should have the form of a valid SQL identifier, unless it is *. You can use double-quoting if necessary. But note that standby_names are compared to standby application names case-insensitively, whether double-quoted or not.</p><p>If no synchronous standby names are specified here, then synchronous replication is not enabled and transaction commits will not wait for replication. This is the default configuration. Even when synchronous replication is enabled, individual transactions can be configured not to wait for replication by setting the synchronous_commit parameter to local or off.</p><p>This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Senkron replikasyon destekleyen standby sunucu listesini belirtir. Herhangi bir anda bir veya daha fazla aktif senkron standby olabilir. Bu standby sunucular verilerin alındığını onayladıktan sonra commit için bekleyen transaction’lara izin verir. Mevcut bağlı ve gerçek zamanlı streaming verisi olan senkron standby’lar listede ismi verilenlerden olacaktır. (pg_stat_replication view’ı streaming durumunu gösterir). Birden fazla senkron standby’in belirtilmesi, yüksek erişebilirliği (HA) ve veri kaybına karşı koruma sağlar. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

vacuum_defer_cleanup_age

type: integer default: 0 min: 0 max: 1000000 context: sighup
<p>Specifies the number of transactions by which VACUUM and HOT updates will defer cleanup of dead row versions. The default is zero transactions, meaning that dead row versions can be removed as soon as possible, that is, as soon as they are no longer visible to any open transaction. You may wish to set this to a non-zero value on a primary server that is supporting hot standby servers, as described in hot-standby. This allows more time for queries on the standby to complete without incurring conflicts due to early cleanup of rows. However, since the value is measured in terms of number of write transactions occurring on the primary server, it is difficult to predict just how much additional grace time will be made available to standby queries. This parameter can only be set in the postgresql.conf file or on the server command line.</p><p>You should also consider setting hot_standby_feedback on standby server(s) as an alternative to using this parameter.</p><p>This does not prevent cleanup of dead rows which have reached the age specified by old_snapshot_threshold.</p>
Varsa, VACUUM ve HOT temizlemesinin ertelenmesi gereken transaction sayısı. Varsayılan sıfır transaction’dır, dead row sürümleri mümkün olan en kısa sürede, yani açık transaction’lar tarafından visible olmaktan çıkar çıkmaz kaldırılır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

Standby Sunucular

Bu başlıkta verilen ayarlar replikasyon verilerini alan standby sunucunun davranışını kontrol eder.

primary_conninfo

type: string context: sighup
<p>Specifies a connection string to be used for the standby server to connect with a sending server. This string is in the format described in libpq-connstring. If any option is unspecified in this string, then the corresponding environment variable (see libpq-envars) is checked. If the environment variable is not set either, then defaults are used.</p><p>The connection string should specify the host name (or address) of the sending server, as well as the port number if it is not the same as the standby server’s default. Also specify a user name corresponding to a suitably-privileged role on the sending server (see streaming-replication-authentication). A password needs to be provided too, if the sender demands password authentication. It can be provided in the primary_conninfo string, or in a separate ~/.pgpass file on the standby server (use replication as the database name). Do not specify a database name in the primary_conninfo string.</p><p>This parameter can only be set in the postgresql.conf file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting (except if primary_conninfo is an empty string). This setting has no effect if the server is not in standby mode.</p>
Standby sunucunun gönderen sunucuya bağlanması için kullanılan bağlantı dizesini belirtir. Bu dize burada açıklanan formattadır. Bu dizede herhangi bir seçenek belirtilmediğinde ilgili ortam değişkeni kontrol edilir. Ortam değişkeni de ayarlanmadıysa varsayılanlar kullanılır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

primary_slot_name

type: string context: sighup
<p>Optionally specifies an existing replication slot to be used when connecting to the sending server via streaming replication to control resource removal on the upstream node (see streaming-replication-slots). This parameter can only be set in the postgresql.conf file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting. This setting has no effect if primary_conninfo is not set or the server is not in standby mode.</p>
Gönderen sunucuda kullanılacak replikasyon slotu adını ayarlar. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir. WAL receiver süreci çalışırken bu parametre değiştirilirse, bu sürecin kapanması için sinyal gönderilir ve yeni ayarla tekrar başlatılması beklenir. primary_conninfo ayarlanmamışsa veya sunucu standby modunda değilse bu ayarın hiçbir etkisi yoktur.

promote_trigger_file

type: string context: sighup
<p>Specifies a trigger file whose presence ends recovery in the standby. Even if this value is not set, you can still promote the standby using pg_ctl promote or calling pg_promote(). This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Standby modunda recovery’i sona erdiren bir trigger dosyası belirtir. Bu değer ayarlandan standby pg_ctl promote ve pg_promote () ile promote edilebilir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

hot_standby

type: bool default: on context: postmaster restart: Gerektirir
<p>Specifies whether or not you can connect and run queries during recovery, as described in hot-standby. The default value is on. This parameter can only be set at server start. It only has effect during archive recovery or in standby mode.</p>
Recovery sırasında bağlantılara ve sorgulara izin verir. Hot Standby‘de açıklandığı gibi recovery sırasında bağlanıp sorgu çalıştırıp çalıştırmayacağınızı ayarlar. Öntanımlı değeri on‘dur. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir. Archive recovery sırasında ve standby modunda etkilidir.

max_standby_archive_delay

type: integer default: 30 s min: -1 max: 2147483647 unit: ms context: sighup
<p>When Hot Standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in hot-standby-conflict. max_standby_archive_delay applies when WAL data is being read from WAL archive (and is therefore not current). If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the postgresql.conf file or on the server command line.</p><p>Note that max_standby_archive_delay is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply any one WAL segment’s data. Thus, if one query has resulted in significant delay earlier in the WAL segment, subsequent conflicting queries will have much less grace time.</p>
Bu parametre Hot standby etkin olduğunda işlenen WAL verileriyle çakışan standby sorgularını iptal etmeden önce standby sunucunun maksimum gecikmesini ayarlar. WAL verileri WAL arşivinden okunduğunda uygulanır. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Öntanımlı 30 saniyedir. -1 değeri, standby’ın çakışan sorguların tamamlanması için sonsuza kadar beklemesine izin verir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

max_standby_streaming_delay

type: integer default: 30 s min: -1 max: 2147483647 unit: ms context: sighup
<p>When Hot Standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in hot-standby-conflict. max_standby_streaming_delay applies when WAL data is being received via streaming replication. If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the postgresql.conf file or on the server command line.</p><p>Note that max_standby_streaming_delay is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply WAL data once it has been received from the primary server. Thus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again.</p>
Bu parametre Hot Standby etkin olduğunda işlenen WAL verileriyle çakışan standby sorgularını iptal etmeden önce standby sunucunun maksimum gecikmesini ayarlar. max_standby_streaming_delay, WAL verileri streaming replikasyon yoluyla alındığında uygulanır. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Öntanımlı değeri 30 saniyedir. -1 değeri, çakışan sorguların tamamlanması için standby’ın sonsuza kadar beklemesine izin verir. Bu parametre yalnızca postgresql.conf dosyasında ve sunucu komut satırından ayarlanabilir.

wal_receiver_create_temp_slot

type: bool default: off context: sighup
<p>Specifies whether the WAL receiver process should create a temporary replication slot on the remote instance when no permanent replication slot to use has been configured (using primary_slot_name). The default is off. This parameter can only be set in the postgresql.conf file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting.</p>
Kalıcı bir slot yapılandırılmamışsa (primary_slot_name kullanarak) bir WAL alıcısının geçici bir replikasyon slotu oluşturup oluşturmayacağını belirler. Varsayılan olarak kapalıdır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir. WAL receiver süreci çalışırken bu parametre değiştirilirse, bu sürecin kapanması için sinyal gönderilerek yeni ayarla tekrar başlatılması beklenir.

wal_receiver_status_interval

type: integer default: 10 s min: 0 max: 2147483 unit: s context: sighup
<p>Specifies the minimum frequency for the WAL receiver process on the standby to send information about replication progress to the primary or upstream standby, where it can be seen using the pg_stat_replication view. The standby will report the last write-ahead log location it has written, the last position it has flushed to disk, and the last position it has applied. This parameter’s value is the maximum amount of time between reports. Updates are sent each time the write or flush positions change, or at least as often as specified by this parameter. Thus, the apply position may lag slightly behind the true position. If this value is specified without units, it is taken as seconds. The default value is 10 seconds. Setting this parameter to zero disables status updates completely. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Primary ve upstream standby’a replikasyon ilerlemesi hakkında bilgi gönderen standby üzerindeki WAL receiver sürecinin durum raporları arasındaki maksimum aralığı ayarlar. Bu bilgiler pg_stat_replication view’ı kullanılarak görüntülenir. Standby, yazdığı son WAL kaydının konumunu, diske flush edilen yer ve uyguladığı son konumu raporlar. Parametrenin değeri bu raporlar arasındaki maksimum süredir. Değişiklikler, yazma veya flush konumları her değiştiğinde veya bu parametre ile belirtilen sıklıkta gönderilir. Bu nedenle, uygulama konumu gerçek konumun biraz gerisinde kalabilir. Bu değer birimsiz belirtilirse saniye olarak alınır. Öntanımlı değeri 10 saniyedir. Bu parametrenin 0 olarak ayarlanması, durum değişikliklerini tamamen devre dışı bırakır. Bu parametre yalnızca postgresql.conf dosyasında ve sunucu komut satırından ayarlanabilir.

hot_standby_feedback

type: bool default: off context: sighup
<p>Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby. This parameter can be used to eliminate query cancels caused by cleanup records, but can cause database bloat on the primary for some workloads. Feedback messages will not be sent more frequently than once per wal_receiver_status_interval. The default value is off. This parameter can only be set in the postgresql.conf file or on the server command line.</p><p>If cascaded replication is in use the feedback is passed upstream until it eventually reaches the primary. Standbys make no other use of feedback they receive other than to pass upstream.</p><p>This setting does not override the behavior of old_snapshot_threshold on the primary; a snapshot on the standby which exceeds the primary’s age threshold can become invalid, resulting in cancellation of transactions on the standby. This is because old_snapshot_threshold is intended to provide an absolute limit on the time which dead rows can contribute to bloat, which would otherwise be violated because of the configuration of a standby.</p>
Bir hot standby’ın yürütülen sorgular hakkında primary veya upstream standby’a geri bildirim gönderip göndermeyeceğini ayarlar. Bu parametre, temizleme kayıtlarından kaynaklı sorgu iptallerini ortadan kaldırmak için kullanılır. Bazı iş yüklerinde primary veritabanı şişmesine neden olabilir. Geri bildirim mesajları, her bir wal_receiver_status_interval‘da bir defadan fazla gönderilmez. Varsayılan değeri off‘dur. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

Cascaded replikasyon kullanımında, geri bildirim primary’e ulaşana kadar upstream’e iletilir. Standby’lar aldıkları geri bildirimi, upstream’e göndermek dışında hiçbir şekilde kullanmaz.

wal_receiver_timeout

type: integer default: 1 min min: 0 max: 2147483647 unit: ms context: sighup
<p>Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Bu parametrede belirtilen süreden daha uzun süre etkin olmayan replikasyon bağlantılarını sonlandırır. Alıcı standby sunucunun primary düğüm çökmesi veya ağ kesintisini algılaması için kullanışlıdır. Birimsiz belirtilirse milisaniye olarak alınır. Öntanımlı değeri 60 saniyedir. 0 değeri, zaman aşımı mekanizmasını devre dışı bırakır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

wal_retrieve_retry_interval

type: integer default: 5 s min: 1 max: 2147483647 unit: ms context: sighup
<p>Specifies how long the standby server should wait when WAL data is not available from any sources (streaming replication, local pg_wal or WAL archive) before trying again to retrieve WAL data. If this value is specified without units, it is taken as milliseconds. The default value is 5 seconds. This parameter can only be set in the postgresql.conf file or on the server command line.</p><p>This parameter is useful in configurations where a node in recovery needs to control the amount of time to wait for new WAL data to be available. For example, in archive recovery, it is possible to make the recovery more responsive in the detection of a new WAL log file by reducing the value of this parameter. On a system with low WAL activity, increasing it reduces the amount of requests necessary to access WAL archives, something useful for example in cloud environments where the amount of times an infrastructure is accessed is taken into account.</p>
Standby sunucunun, herhangi bir kaynakta (streaming replikasyon, yerel ‘pg_wal’ veya WAL arşivi) WAL verileri hazır olmadığında beklenecek süreyi belirtir. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Ötanımlı değeri 5 saniyedir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

Archive recovery’de, bu parametre değerini azaltarak yeni WAL log dosyası tespitinde recovery’i daha duyarlı hale getirmek mümkündür. Düşük WAL etkinliğine sahip bir sistemde bu değeri artırmak, WAL arşivine erişim istek miktarını azaltır. Bu, altyapıya erişme miktarının hesaba katıldığı bulut ortamlarında faydalıdır.

recovery_min_apply_delay

type: integer default: 0 ms min: 0 max: 2147483647 unit: ms context: sighup
<p>By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to 5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the master. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay.</p><p>It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on master and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on master and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers.</p><p>The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied.</p><p>The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting.</p><p>This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases except crash recovery. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the master; use both together with care. <p>Synchronous replication is affected by this setting when synchronous_commit is set to remote_apply; every COMMIT will need to wait to be applied.</p></p><p>This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Bir standby sunucu varsayılan olarak WAL kayıtlarını gönderen sunucudan mümkün olan en kısa sürede yeniler. Verilerin gecikmeli bir kopyasına sahip olmak veri kaybı hatalarını düzeltmek için faydalı olabilir. Bu parametre recovery’i belirli bir süre geciktirmenizi sağlar. Örneğin, bu parametreyi 5min olarak ayarlarsanız standby, her transaction commit’ini yalnızca standby’daki sistem süresi primary tarafından bildirilen commit süresinden en az beş dakika geçtiğinde replay eder. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Varsayılan sıfırdır, gecikme yoktur.

Sunucular arasındaki replikasyon gecikmesinin bu parametrenin değerini aşması durumunda herhangi bir gecikme eklenmez. Gecikmenin, primary’de yazılan WAL zaman damgası ile standby’daki saat arasında hesaplandığını unutmayın. Ağ gecikmesi veya cascading replikasyon yapılandırmaları sebepli aktarımdaki gecikmeler mevcut bekleme süresini önemli ölçüde azaltabilir. Primary ve standby’daki sistem saatleri senkronize değilse kayıtlar beklenenden daha erken uygulanabilir.

Gecikme, yalnızca transaction commit’leri için WAL kayıtlarında meydana gelir. Diğer kayıtlar olabildiğince çabuk replay edilir. Bu bir problem değildir çünkü MVCC visibility kuralları, ilgili commit kaydı uygulanana kadar etkilerinin görünür olmamasını sağlar.

Gecikme, recovery sırasında veritabanı tutarlı bir duruma ulaştığında, standby promote edilene veya tetiklenene kadar gerçekleşir ve sonrasında standby daha fazla beklemeden recovery’i sonlandırır.

Bu parametre yalnızca postgresql.conf dosyasında veya sunucu komut satırında ayarlanabilir.

Subscribers

Bu başlıkta verilen ayarlar logical replikasyon subscriber davranışını kontrol eder. publisher değerleri konu dışıdır.

max_logical_replication_workers

type: integer default: 4 min: 0 max: 262143 context: postmaster restart: Gerektirir
<p>Specifies maximum number of logical replication workers. This includes both apply workers and table synchronization workers.</p><p>Logical replication workers are taken from the pool defined by max_worker_processes.</p><p>The default value is 4.</p>
Maksimum logical replikasyon worker sayısını belirtir. Bu, hem apply hem de tablo senkronizasyon worker’ları kapsar. Logical replikasyon worker, max_worker_processes tarafından tanımlanan havuzdan alınır. Öntanımlı değer 4’tür.

max_sync_workers_per_subscription

type: integer default: 2 min: 0 max: 262143 context: sighup
<p>Maximum number of synchronization workers per subscription. This parameter controls the amount of parallelism of the initial data copy during the subscription initialization or when new tables are added.</p><p>Currently, there can be only one synchronization worker per table.</p><p>The synchronization workers are taken from the pool defined by max_logical_replication_workers.</p><p>The default value is 2.</p>
Her bir subscription için maksimum senkronizasyon worker’ı sayısı belirtir. Bu parametre, subscription başlatma sırasında veya yeni tablolar eklendiğinde ilk veri kopyasının parallelism miktarını kontrol eder. Şu an için her tablo başına yalnızca bir senkronizasyon worker’ı olabilir. Senkronizasyon worker’ları max_logical_replication_workers tarafından tanımlanan havuzdan alınır. Öntanımlı değeri 2’dir.

Kaynak:

[1]. PostgreSQL Documentation

[2]. postgresqlco.nf