pgsql: Cascading replication feature for streaming log-based replicatio
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
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/5286105800c7d5902f98f32e11b209c471c0c69c
Modified Files
--------------
doc/src/sgml/config.sgml | 127 ++++++++++------
doc/src/sgml/high-availability.sgml | 62 ++++++++-
src/backend/access/transam/xlog.c | 265 +++++++++++++++++++--------------
src/backend/postmaster/postmaster.c | 20 +++
src/backend/replication/basebackup.c | 5 +
src/backend/replication/syncrep.c | 7 +
src/backend/replication/walreceiver.c | 7 +-
src/backend/replication/walsender.c | 108 ++++++++++---
src/include/access/xlog.h | 6 +-
src/include/replication/walsender.h | 5 +-
10 files changed, 423 insertions(+), 189 deletions(-)
On Tue, Jul 19, 2011 at 11:44 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
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
Thanks a lot for the commit!
You added new GUC category "Sending Server(s)" into the doc. According to
this change, we need to change also guc.c and postgresql.conf.sample.
Attached patch does that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachments:
new_guc_category_v1.patchtext/x-patch; charset=US-ASCII; name=new_guc_category_v1.patchDownload
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***************
*** 557,562 **** const char *const config_group_names[] =
--- 557,564 ----
gettext_noop("Write-Ahead Log / Archiving"),
/* REPLICATION */
gettext_noop("Replication"),
+ /* REPLICATION_SENDING */
+ gettext_noop("Replication / Sending Server(s)"),
/* REPLICATION_MASTER */
gettext_noop("Replication / Master Server"),
/* REPLICATION_STANDBY */
***************
*** 1918,1924 **** static struct config_int ConfigureNamesInt[] =
},
{
! {"wal_keep_segments", PGC_SIGHUP, REPLICATION_MASTER,
gettext_noop("Sets the number of WAL files held for standby servers."),
NULL
},
--- 1920,1926 ----
},
{
! {"wal_keep_segments", PGC_SIGHUP, REPLICATION_SENDING,
gettext_noop("Sets the number of WAL files held for standby servers."),
NULL
},
***************
*** 1986,1992 **** static struct config_int ConfigureNamesInt[] =
{
/* see max_connections */
! {"max_wal_senders", PGC_POSTMASTER, REPLICATION_MASTER,
gettext_noop("Sets the maximum number of simultaneously running WAL sender processes."),
NULL
},
--- 1988,1994 ----
{
/* see max_connections */
! {"max_wal_senders", PGC_POSTMASTER, REPLICATION_SENDING,
gettext_noop("Sets the maximum number of simultaneously running WAL sender processes."),
NULL
},
***************
*** 1996,2002 **** static struct config_int ConfigureNamesInt[] =
},
{
! {"wal_sender_delay", PGC_SIGHUP, REPLICATION_MASTER,
gettext_noop("WAL sender sleep time between WAL replications."),
NULL,
GUC_UNIT_MS
--- 1998,2004 ----
},
{
! {"wal_sender_delay", PGC_SIGHUP, REPLICATION_SENDING,
gettext_noop("WAL sender sleep time between WAL replications."),
NULL,
GUC_UNIT_MS
***************
*** 2007,2013 **** static struct config_int ConfigureNamesInt[] =
},
{
! {"replication_timeout", PGC_SIGHUP, REPLICATION_MASTER,
gettext_noop("Sets the maximum time to wait for WAL replication."),
NULL,
GUC_UNIT_MS
--- 2009,2015 ----
},
{
! {"replication_timeout", PGC_SIGHUP, REPLICATION_SENDING,
gettext_noop("Sets the maximum time to wait for WAL replication."),
NULL,
GUC_UNIT_MS
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***************
*** 194,212 ****
# REPLICATION
#------------------------------------------------------------------------------
! # - Master Server -
! # These settings are ignored on a standby server
#max_wal_senders = 0 # max number of walsender processes
# (change requires restart)
#wal_sender_delay = 1s # walsender cycle time, 1-10000 milliseconds
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
- #vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
#replication_timeout = 60s # in milliseconds; 0 disables
#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all
# - Standby Servers -
--- 194,217 ----
# REPLICATION
#------------------------------------------------------------------------------
! # - Sending Server(s) -
! # These settings have effect on any server that is to send replication data
#max_wal_senders = 0 # max number of walsender processes
# (change requires restart)
#wal_sender_delay = 1s # walsender cycle time, 1-10000 milliseconds
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
#replication_timeout = 60s # in milliseconds; 0 disables
+
+ # - Master Server -
+
+ # These settings are ignored on a standby server
+
#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all
+ #vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
# - Standby Servers -
*** a/src/include/utils/guc_tables.h
--- b/src/include/utils/guc_tables.h
***************
*** 69,74 **** enum config_group
--- 69,75 ----
WAL_CHECKPOINTS,
WAL_ARCHIVING,
REPLICATION,
+ REPLICATION_SENDING,
REPLICATION_MASTER,
REPLICATION_STANDBY,
QUERY_TUNING,
On Tue, Jul 19, 2011 at 7:31 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Tue, Jul 19, 2011 at 11:44 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
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
Thanks a lot for the commit!
You added new GUC category "Sending Server(s)" into the doc. According to
this change, we need to change also guc.c and postgresql.conf.sample.
Attached patch does that.
Applied
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 19 July 2011 03:44, Simon Riggs <simon@2ndquadrant.com> wrote:
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
I've only just started looking at this.
In doc/src/sgml/config.sgml:
Note that in addition to these parameters,
<xref linkend="guc-wal-level"> must be set appropriately on the master
server, and may also want to enable WAL archiving as
well (see <xref linkend="runtime-config-wal-archiving">).
s/and may also/and you may also/
In doc/src/sgml/high-availability.sgml:
s/effected/affected/
Also: "i.e., set max_wal_senders, hot_standby and authentication option"
Doesn't sound right. Perhaps something like "... and configure
host-based authentication"
In src/backend/postmaster/postmaster.c:
(errmsg("terminating walsender all processes to force cascaded"
"standby(s) to update timeline and reconnect")));
s/walsender all/all walsender/
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sat, Oct 8, 2011 at 8:59 AM, Thom Brown <thom@linux.com> wrote:
s/and may also/and you may also/
This was already fixed in a later commit.
In doc/src/sgml/high-availability.sgml:
s/effected/affected/
I fixed this.
Also: "i.e., set max_wal_senders, hot_standby and authentication option"
Doesn't sound right. Perhaps something like "... and configure
host-based authentication"
I reworded this. See what you think.
In src/backend/postmaster/postmaster.c:
(errmsg("terminating walsender all processes to force cascaded"
"standby(s) to update timeline and reconnect")));s/walsender all/all walsender/
This has also been subsequently fixed. Nothing to see here, folks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10 October 2011 15:18, Robert Haas <robertmhaas@gmail.com> wrote:
On Sat, Oct 8, 2011 at 8:59 AM, Thom Brown <thom@linux.com> wrote:
s/and may also/and you may also/
This was already fixed in a later commit.
In doc/src/sgml/high-availability.sgml:
s/effected/affected/
I fixed this.
Also: "i.e., set max_wal_senders, hot_standby and authentication option"
Doesn't sound right. Perhaps something like "... and configure
host-based authentication"I reworded this. See what you think.
In src/backend/postmaster/postmaster.c:
(errmsg("terminating walsender all processes to force cascaded"
"standby(s) to update timeline and reconnect")));s/walsender all/all walsender/
This has also been subsequently fixed. Nothing to see here, folks.
Ah, didn't spot that some of this had already been addressed. Looks
good to me. Cheers.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company