From 5286105800c7d5902f98f32e11b209c471c0c69c Mon Sep 17 00:00:00 2001 From: Simon Riggs Date: Tue, 19 Jul 2011 03:40:03 +0100 Subject: Cascading replication feature for streaming log-based replication. Standby servers can now have WALSender processes, which can work with either WALReceiver or archive_commands to pass data. Fully updated docs, including new conceptual terms of sending server, upstream and downstream servers. WALSenders terminated when promote to master. Fujii Masao, review, rework and doc rewrite by Simon Riggs --- doc/src/sgml/config.sgml | 127 ++++++++++++++++++++++-------------- doc/src/sgml/high-availability.sgml | 62 +++++++++++++++++- 2 files changed, 139 insertions(+), 50 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index afa087a3465..6091105a860 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1962,24 +1962,26 @@ SET ENABLE_SEQSCAN TO OFF; These settings control the behavior of the built-in streaming replication feature (see - ). - Some parameters must be set on the master server, while others must be - set on the standby server(s) that will receive replication data. + ). Servers will be either a + Master or a Standby server. Masters can send data, while Standby(s) + are always receivers of replicated data. When cascading replication + (see ) is used, Standby server(s) + can also be senders, as well as receivers. + Parameters are mainly for Sending and Standby servers, though some + parameters have meaning only on the Master server. Settings may vary + across the cluster without problems if that is required. - - Master Server + + Sending Server(s) - These parameters can be set on the primary server that is + These parameters can be set on any server that is to send replication data to one or more standby servers. - Note that in addition to these parameters, - must be set appropriately on the master - server, and you will typically want to enable WAL archiving as - well (see ). - The values of these parameters on standby servers are irrelevant, - although you may wish to set them there in preparation for the - possibility of a standby becoming the master. + The master is always a sending server, so these parameters must + always be set on the master. + The role and meaning of these parameters does not change after a + standby becomes the master. @@ -2034,10 +2036,11 @@ SET ENABLE_SEQSCAN TO OFF; pg_xlog directory, in case a standby server needs to fetch them for streaming replication. Each segment is normally 16 megabytes. If a standby - server connected to the primary falls behind by more than - wal_keep_segments segments, the primary might remove + server connected to the sending server falls behind by more than + wal_keep_segments segments, the sending server might remove a WAL segment still needed by the standby, in which case the - replication connection will be terminated. (However, the standby + 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.) @@ -2050,42 +2053,13 @@ SET ENABLE_SEQSCAN TO OFF; 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. This parameter has no effect on restartpoints. + archiving. This parameter can only be set in the postgresql.conf file or on the server command line. - - vacuum_defer_cleanup_age (integer) - - vacuum_defer_cleanup_age configuration parameter - - - - 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 . 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. - - - You should also consider setting hot_standby_feedback - as an alternative to using this parameter. - - - - replication_timeout (integer) @@ -2095,7 +2069,7 @@ SET ENABLE_SEQSCAN TO OFF; Terminate replication connections that are inactive longer than the specified number of milliseconds. This is useful for - the primary server to detect a standby crash or network outage. + the sending server to detect a standby crash or network outage. 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. @@ -2110,6 +2084,26 @@ SET ENABLE_SEQSCAN TO OFF; + + + + + Master Server + + + These parameters can be set on the master/primary server that is + to send replication data to one or more standby servers. + Note that in addition to these parameters, + must be set appropriately on the master + server, and may also want to enable WAL archiving as + well (see ). + The values of these parameters on standby servers are irrelevant, + although you may wish to set them there in preparation for the + possibility of a standby becoming the master. + + + + synchronous_standby_names (string) @@ -2161,6 +2155,35 @@ SET ENABLE_SEQSCAN TO OFF; + + vacuum_defer_cleanup_age (integer) + + vacuum_defer_cleanup_age configuration parameter + + + + 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 . 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. + + + You should also consider setting hot_standby_feedback + on standby server(s) as an alternative to using this parameter. + + + + @@ -2261,7 +2284,7 @@ SET ENABLE_SEQSCAN TO OFF; Specifies the minimum frequency for the WAL receiver process on the standby to send information about replication progress - to the primary, where it can be seen using the + to the primary or upstream standby, where it can be seen using the pg_stat_replication view. The standby will report the last transaction log position it has written, the last position it @@ -2276,7 +2299,7 @@ SET ENABLE_SEQSCAN TO OFF; The default value is 10 seconds. - When is enabled on the primary, + When is enabled on a sending server, wal_receiver_status_interval must be enabled, and its value must be less than the value of replication_timeout. @@ -2291,6 +2314,7 @@ SET ENABLE_SEQSCAN TO OFF; 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. @@ -2299,6 +2323,11 @@ SET ENABLE_SEQSCAN TO OFF; off. This parameter can only be set in the postgresql.conf file or on the server command line. + + 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. + diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 0d3baa04bcd..674bfb80102 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -877,8 +877,66 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' network delay, or that the standby is under heavy load. + + + + Cascading Replication + + + Cascading Replication + + + + The cascading replication feature allows a standby server to accept replication + connections and stream WAL records to other standbys, acting as a relay. + This can be used to reduce the number of direct connections to the master + and also to minimise inter-site bandwidth overheads. + + + A standby acting as both a receiver and a sender is known as a cascading + standby. Standbys that are more directly connected to the master are known + as upstream servers, while those standby servers further away are downstream + servers. Cascading replication does not place limits on the number or + arrangement of downstream servers, though each standby connects to only + one upstream server which eventually links to a single master/primary + server. + + + + A cascading standby sends not only WAL records received from the + master but also those restored from the archive. So even if the replication + connection in some upstream connection is terminated, streaming replication + continues downstream for as long as new WAL records are available. + + + + Cascading replication is currently asynchronous. Synchronous replication + (see ) settings have no effect on + cascading replication at present. + + + + Hot Standby feedback propagates upstream, whatever the cascaded arrangement. + + + + Promoting a cascading standby terminates the immediate downstream replication + connections which it serves. This is because the timeline becomes different + between standbys, and they can no longer continue replication. The + effected standby(s) may reconnect to reestablish streaming replication. + + + + To use cascading replication, set up the cascading standby so that it can + accept replication connections, i.e., set max_wal_senders, + hot_standby and authentication option (see + and ). + Also set primary_conninfo in the downstream standby to point + to the cascading standby. + + Synchronous Replication @@ -955,7 +1013,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' confirmation that the commit record has been received. These parameters allow the administrator to specify which standby servers should be synchronous standbys. Note that the configuration of synchronous - replication is mainly on the master. + replication is mainly on the master. Named standbys must be directly + connected to the master; the master knows nothing about downstream + standby servers using cascaded replication. -- cgit v1.2.3