diff --git a/doc/filelist.sgml b/doc/filelist.sgml index 986eba3f..2d08b9b5 100644 --- a/doc/filelist.sgml +++ b/doc/filelist.sgml @@ -50,12 +50,12 @@ + - diff --git a/doc/repmgr.sgml b/doc/repmgr.sgml index 2d97709d..beebefbd 100644 --- a/doc/repmgr.sgml +++ b/doc/repmgr.sgml @@ -80,10 +80,10 @@ Using repmgrd + &repmgrd-overview; &repmgrd-automatic-failover; &repmgrd-configuration; &repmgrd-demonstration; - &repmgrd-cascading-replication; &repmgrd-network-split; &repmgrd-witness-server; &repmgrd-pausing; diff --git a/doc/repmgrd-automatic-failover.sgml b/doc/repmgrd-automatic-failover.sgml index ee3556eb..2695881a 100644 --- a/doc/repmgrd-automatic-failover.sgml +++ b/doc/repmgrd-automatic-failover.sgml @@ -13,5 +13,35 @@ providing monitoring information about the state of each standby. + + + repmgrd + cascading replication + + + + cascading replication + repmgrd + + + repmgrd and cascading replication + + Cascading replication - where a standby can connect to an upstream node and not + the primary server itself - was introduced in PostgreSQL 9.2. &repmgr; and + repmgrd support cascading replication by keeping track of the relationship + between standby servers - each node record is stored with the node id of its + upstream ("parent") server (except of course the primary server). + + + In a failover situation where the primary node fails and a top-level standby + is promoted, a standby connected to another standby will not be affected + and continue working as normal (even if the upstream standby it's connected + to becomes the primary node). If however the node's direct upstream fails, + the "cascaded standby" will attempt to reconnect to that node's parent + (unless failover is set to manual in + repmgr.conf). + + + diff --git a/doc/repmgrd-cascading-replication.sgml b/doc/repmgrd-cascading-replication.sgml deleted file mode 100644 index 7d4dfbc3..00000000 --- a/doc/repmgrd-cascading-replication.sgml +++ /dev/null @@ -1,24 +0,0 @@ - - - repmgrd - cascading replication - - - repmgrd and cascading replication - - Cascading replication - where a standby can connect to an upstream node and not - the primary server itself - was introduced in PostgreSQL 9.2. &repmgr; and - repmgrd support cascading replication by keeping track of the relationship - between standby servers - each node record is stored with the node id of its - upstream ("parent") server (except of course the primary server). - - - In a failover situation where the primary node fails and a top-level standby - is promoted, a standby connected to another standby will not be affected - and continue working as normal (even if the upstream standby it's connected - to becomes the primary node). If however the node's direct upstream fails, - the "cascaded standby" will attempt to reconnect to that node's parent - (unless failover is set to manual in - repmgr.conf). - - diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml index 1afdc618..da692e80 100644 --- a/doc/repmgrd-configuration.sgml +++ b/doc/repmgrd-configuration.sgml @@ -406,9 +406,6 @@ - - - diff --git a/doc/repmgrd-overview.sgml b/doc/repmgrd-overview.sgml new file mode 100644 index 00000000..1d2d7fae --- /dev/null +++ b/doc/repmgrd-overview.sgml @@ -0,0 +1,17 @@ + + + + repmgrd + overview + + + repmgrd overview + + + repmgrd ("replication manager daemon") + is a management and monitoring daemon which runs + on each node in a replication cluster. It can automate actions such as + failover and updating standbys to follow the new primary, as well as + providing monitoring information about the state of each standby. + +