diff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c index e4136f9..8fcb85c 100644 --- a/contrib/pg_standby/pg_standby.c +++ b/contrib/pg_standby/pg_standby.c @@ -520,7 +520,7 @@ usage(void) printf(" -w MAXWAITTIME max seconds to wait for a file (0=no limit) (default=0)\n"); printf(" -?, --help show this help, then exit\n"); printf("\n" - "Main intended use as restore_command in recovery.conf:\n" + "Main intended use as restore_command in postgresql.conf:\n" " restore_command = 'pg_standby [OPTION]... ARCHIVELOCATION %%f %%p %%r'\n" "e.g.\n" " restore_command = 'pg_standby /mnt/server/archiverdir %%f %%p %%r'\n"); diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 6eaed1e..2df0dc6 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1190,8 +1190,15 @@ SELECT pg_stop_backup(); - Create a recovery command file recovery.conf in the cluster - data directory (see ). You might + Set up recovery parameters in postgresql.conf (see + and + ). + + + + + Create a recovery trigger file recovery.trigger + in the cluster data directory. You might also want to temporarily modify pg_hba.conf to prevent ordinary users from connecting until you are sure the recovery was successful. @@ -1203,7 +1210,7 @@ SELECT pg_stop_backup(); recovery be terminated because of an external error, the server can simply be restarted and it will continue recovery. Upon completion of the recovery process, the server will rename - recovery.conf to recovery.done (to prevent + recovery.trigger to recovery.done (to prevent accidentally re-entering recovery mode later) and then commence normal database operations. @@ -1219,12 +1226,11 @@ SELECT pg_stop_backup(); - The key part of all this is to set up a recovery configuration file that - describes how you want to recover and how far the recovery should - run. You can use recovery.conf.sample (normally - located in the installation's share/ directory) as a - prototype. The one thing that you absolutely must specify in - recovery.conf is the restore_command, + The key part of all this is to set up recovery parameters that + specify how you want to recover and how far the recovery should + run. The one thing that you absolutely must specify in + postgresql.conf to recover from the backup is + the restore_command, which tells PostgreSQL how to retrieve archived WAL file segments. Like the archive_command, this is a shell command string. It can contain %f, which is @@ -1286,7 +1292,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' If you want to recover to some previous point in time (say, right before the junior DBA dropped your main transaction table), just specify the - required stopping point in recovery.conf. You can specify + required stopping point in postgresql.conf. You can specify the stop point, known as the recovery target, either by date/time, named restore point or by completion of a specific transaction ID. As of this writing only the date/time and named restore point options @@ -1383,8 +1389,9 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' The default behavior of recovery is to recover along the same timeline that was current when the base backup was taken. If you wish to recover into some child timeline (that is, you want to return to some state that - was itself generated after a recovery attempt), you need to specify the - target timeline ID in recovery.conf. You cannot recover into + was itself generated after a recovery attempt), you need to set + to the + target timeline ID in postgresql.conf. You cannot recover into timelines that branched off earlier than the base backup. diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 10e3186..d3abac9 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -18131,7 +18131,7 @@ postgres=# select pg_start_backup('label_goes_here'); pg_create_restore_point creates a named transaction log record that can be used as recovery target, and returns the corresponding transaction log location. The given name can then be used with - to specify the point up to which + to specify the point up to which recovery will proceed. Avoid creating multiple restore points with the same name, since recovery will stop at the first one whose name matches the recovery target. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index a1a9532..011f4db 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -591,7 +591,7 @@ protocol to make nodes agree on a serializable transactional order. In standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive - (see ) or directly from the master + (see ) or directly from the master over a TCP connection (streaming replication). The standby server will also attempt to restore any WAL found in the standby cluster's pg_wal directory. That typically happens after a server @@ -660,8 +660,8 @@ protocol to make nodes agree on a serializable transactional order. To set up the standby server, restore the base backup taken from primary server (see ). Create a recovery - command file recovery.conf in the standby's cluster data - directory, and turn on standby_mode. Set + signal file recovery.trigger in the standby's cluster data + directory. Turn on standby_mode and set restore_command to a simple command to copy files from the WAL archive. If you plan to have multiple standby servers for high availability purposes, set recovery_target_timeline to @@ -697,7 +697,7 @@ protocol to make nodes agree on a serializable transactional order. If you're using a WAL archive, its size can be minimized using the parameter to remove files that are no + linkend="guc-archive-cleanup-command"> parameter to remove files that are no longer required by the standby server. The pg_archivecleanup utility is designed specifically to be used with archive_cleanup_command in typical single-standby @@ -708,7 +708,7 @@ protocol to make nodes agree on a serializable transactional order. - A simple example of a recovery.conf is: + A simple example of standby settings is: standby_mode = 'on' primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' @@ -766,8 +766,8 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r' To use streaming replication, set up a file-based log-shipping standby server as described in . The step that turns a file-based log-shipping standby into streaming replication - standby is setting primary_conninfo setting in the - recovery.conf file to point to the primary server. Set + standby is setting primary_conninfo to + point to the primary server. Set and authentication options (see pg_hba.conf) on the primary so that the standby server can connect to the replication pseudo-database on the primary @@ -827,15 +827,14 @@ host replication foo 192.168.1.100/32 md5 The host name and port number of the primary, connection user name, - and password are specified in the recovery.conf file. + and password are specified in primary_conninfo. The password can also be set in the ~/.pgpass file on the standby (specify replication in the database field). For example, if the primary is running on host IP 192.168.1.50, port 5432, the account name for replication is foo, and the password is foopass, the administrator - can add the following line to the recovery.conf file on the - standby: + can set primary_conninfo on the standby like this: # The standby connects to the primary that is running on host 192.168.1.50 @@ -940,7 +939,7 @@ postgres=# SELECT * FROM pg_replication_slots; (1 row) To configure the standby to use this slot, primary_slot_name - should be configured in the standby's recovery.conf. + should be configured in the standby's postgresql.conf. Here is a simple example: standby_mode = 'on' @@ -1417,8 +1416,8 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)' To trigger failover of a log-shipping standby server, run pg_ctl promote or create a trigger - file with the file name and path specified by the trigger_file - setting in recovery.conf. If you're planning to use + file with the file name and path specified by the trigger_file. + If you're planning to use pg_ctl promote to fail over, trigger_file is not required. If you're setting up the reporting servers that are only used to offload read-only queries from the primary, not for high @@ -1463,8 +1462,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)' The magic that makes the two loosely coupled servers work together is simply a restore_command used on the standby that, when asked for the next WAL file, waits for it to become available from - the primary. The restore_command is specified in the - recovery.conf file on the standby server. Normal recovery + the primary. Normal recovery processing would request a file from the WAL archive, reporting failure if the file was unavailable. For standby processing it is normal for the next WAL file to be unavailable, so the standby must wait for @@ -1551,8 +1549,14 @@ if (!triggered) + Create a recovery trigger file recovery.signal + in the standby's cluster data directory. + + + + Begin recovery on the standby server from the local WAL - archive, using a recovery.conf that specifies a + archive, specifying a restore_command that waits as described previously (see ). @@ -2048,9 +2052,9 @@ if (!triggered) Administrator's Overview - If hot_standby is turned on in - postgresql.conf and there is a recovery.conf - file present, the server will run in Hot Standby mode. + If hot_standby is turned on + and there is a recovery.signal or + standby.signal present, the server will run in Hot Standby mode. However, it may take some time for Hot Standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries diff --git a/doc/src/sgml/pgstandby.sgml b/doc/src/sgml/pgstandby.sgml index 80c6f60..c9e6185 100644 --- a/doc/src/sgml/pgstandby.sgml +++ b/doc/src/sgml/pgstandby.sgml @@ -46,8 +46,8 @@ To configure a standby - server to use pg_standby, put this into its - recovery.conf configuration file: + server to use pg_standby, specify + like this: restore_command = 'pg_standby archiveDir %f %p %r' diff --git a/doc/src/sgml/ref/pgarchivecleanup.sgml b/doc/src/sgml/ref/pgarchivecleanup.sgml index abe01be..dc29854 100644 --- a/doc/src/sgml/ref/pgarchivecleanup.sgml +++ b/doc/src/sgml/ref/pgarchivecleanup.sgml @@ -38,8 +38,8 @@ To configure a standby - server to use pg_archivecleanup, put this into its - recovery.conf configuration file: + server to use pg_archivecleanup, specify + like this: archive_cleanup_command = 'pg_archivecleanup archivelocation %r' @@ -47,7 +47,7 @@ archive_cleanup_command = 'pg_archivecleanup archivelocation %r' files should be removed. - When used within , all WAL files + When used within archive_cleanup_command, all WAL files logically preceding the value of the %r argument will be removed from archivelocation. This minimizes the number of files that need to be retained, while preserving crash-restart capability. Use of diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml index edacfbf..cfef818 100644 --- a/doc/src/sgml/release-9.1.sgml +++ b/doc/src/sgml/release-9.1.sgml @@ -9811,7 +9811,7 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400 These named restore points can be specified as recovery targets using the new recovery.conf setting - recovery_target_name. + recovery_target_name. @@ -9843,8 +9843,7 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400 - Allow recovery.conf + Allow recovery.conf to use the same quoting behavior as postgresql.conf (Dimitri Fontaine) diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index 472c1f6..4237a66 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -6,7 +6,7 @@ Typical markup: &<> use & escapes PostgreSQL postgresql.conf, pg_hba.conf, - recovery.conf + recovery.trigger [A-Z][A-Z_ ]+[A-Z_] , , , [A-Za-z_][A-Za-z0-9_]+() -[-A-Za-z_]+