From 1a5e858b96ba0607a1c6d7e3031e00944f55bab4 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Fri, 16 Jan 2015 13:49:10 +0200 Subject: [PATCH] Fix indentation in docs --- doc/src/sgml/ref/pg_rewind.sgml | 166 ++++++++++++++++---------------- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml index 9e1bca9559..1e5a1349c9 100644 --- a/doc/src/sgml/ref/pg_rewind.sgml +++ b/doc/src/sgml/ref/pg_rewind.sgml @@ -41,45 +41,45 @@ PostgreSQL documentation Description - pg_rewind is a tool for synchronizing a PostgreSQL cluster - with another copy of the same cluster, after the clusters' timelines have - diverged. A typical scenario is to bring an old master server back online - after failover, as a standby that follows the new master. + pg_rewind is a tool for synchronizing a PostgreSQL cluster + with another copy of the same cluster, after the clusters' timelines have + diverged. A typical scenario is to bring an old master server back online + after failover, as a standby that follows the new master. - The result is equivalent to replacing the target data directory with the - source one. All files are copied, including configuration files. The - advantage of pg_rewind over taking a new base backup, or - tools like rsync, is that pg_rewind does - not require reading through all unchanged files in the cluster. That makes - it a lot faster when the database is large and only a small portion of it - differs between the clusters. + The result is equivalent to replacing the target data directory with the + source one. All files are copied, including configuration files. The + advantage of pg_rewind over taking a new base backup, or + tools like rsync, is that pg_rewind does + not require reading through all unchanged files in the cluster. That makes + it a lot faster when the database is large and only a small portion of it + differs between the clusters. - pg_rewind examines the timeline histories of the source - and target clusters to determine the point where they diverged, and - expects to find WAL in the target cluster's pg_xlog directory - reaching all the way back to the point of divergence. In the typical - failover scenario where the target cluster was shut down soon after the - divergence, that is not a problem, but if the target cluster had run for a - long time after the divergence, the old WAL files might not be present - anymore. In that case, they can be manually copied from the WAL archive to - the pg_xlog directory. Fetching missing files from a WAL - archive automatically is currently not supported. + pg_rewind examines the timeline histories of the source + and target clusters to determine the point where they diverged, and + expects to find WAL in the target cluster's pg_xlog directory + reaching all the way back to the point of divergence. In the typical + failover scenario where the target cluster was shut down soon after the + divergence, that is not a problem, but if the target cluster had run for a + long time after the divergence, the old WAL files might not be present + anymore. In that case, they can be manually copied from the WAL archive to + the pg_xlog directory. Fetching missing files from a WAL + archive automatically is currently not supported. - When the target server is started up for the first time after running - pg_rewind, it will go into recovery mode and replay all - WAL generated in the source server after the point of divergence. - If some of the WAL was no longer available in the source server when - pg_rewind was run, and thereforce could not be copied by - pg_rewind session, it needs to be made available when the - target server is started up. That can be done by creating a - recovery.conf file in the target data directory with a - suitable restore_command. + When the target server is started up for the first time after running + pg_rewind, it will go into recovery mode and replay all + WAL generated in the source server after the point of divergence. + If some of the WAL was no longer available in the source server when + pg_rewind was run, and thereforce could not be copied by + pg_rewind session, it needs to be made available when the + target server is started up. That can be done by creating a + recovery.conf file in the target data directory with a + suitable restore_command. @@ -95,33 +95,33 @@ PostgreSQL documentation - - This option specifies the target data directory that is synchronized - with the source. The target server must shut down cleanly before - running pg_rewind - + + This option specifies the target data directory that is synchronized + with the source. The target server must shut down cleanly before + running pg_rewind + - - Specifies a source data directory to synchronize the target with. - When + + Specifies a source data directory to synchronize the target with. + When - - Specifies a libpq connection string to connect to the source - PostgreSQL server to synchronize the target with. - The server must be up and running, and must not be in recovery mode. - + + Specifies a libpq connection string to connect to the source + PostgreSQL server to synchronize the target with. + The server must be up and running, and must not be in recovery mode. + @@ -129,9 +129,9 @@ PostgreSQL documentation - - Do everything except actually modifying the target directory. - + + Do everything except actually modifying the target directory. + @@ -187,9 +187,9 @@ PostgreSQL documentation Environment - When @@ -197,41 +197,41 @@ PostgreSQL documentation Theory of operation - The basic idea is to copy everything from the new cluster to the old - cluster, except for the blocks that we know to be the same. + The basic idea is to copy everything from the new cluster to the old + cluster, except for the blocks that we know to be the same. - - - Scan the WAL log of the old cluster, starting from the last checkpoint - before the point where the new cluster's timeline history forked off - from the old cluster. For each WAL record, make a note of the data - blocks that were touched. This yields a list of all the data blocks - that were changed in the old cluster, after the new cluster forked off. - - - - - Copy all those changed blocks from the new cluster to the old cluster. - - - - - Copy all other files like clog, conf files etc. from the new cluster - to old cluster. Everything except the relation files. - - - - - Apply the WAL from the new cluster, starting from the checkpoint - created at failover. (Strictly speaking, pg_rewind - doesn't apply the WAL, it just creates a backup label file indicating - that when PostgreSQL is started, it will start replay - from that checkpoint and apply all the required WAL.) - - - + + + Scan the WAL log of the old cluster, starting from the last checkpoint + before the point where the new cluster's timeline history forked off + from the old cluster. For each WAL record, make a note of the data + blocks that were touched. This yields a list of all the data blocks + that were changed in the old cluster, after the new cluster forked off. + + + + + Copy all those changed blocks from the new cluster to the old cluster. + + + + + Copy all other files like clog, conf files etc. from the new cluster + to old cluster. Everything except the relation files. + + + + + Apply the WAL from the new cluster, starting from the checkpoint + created at failover. (Strictly speaking, pg_rewind + doesn't apply the WAL, it just creates a backup label file indicating + that when PostgreSQL is started, it will start replay + from that checkpoint and apply all the required WAL.) + + + -- 2.39.5