diff --git a/HISTORY b/HISTORY
index 78f64c3a..fa1f46c4 100644
--- a/HISTORY
+++ b/HISTORY
@@ -1,7 +1,8 @@
-
4.1.1 2018-??-??
repmgr: truncate version string, if necessary; GitHub #490 (Ian)
repmgr: improve messages emitted during "standby promote" (Ian)
+ repmgr: "standby clone" - don't copy external config files in --dry-run
+ mode; GitHub #491 (Ian)
repmgrd: ensure that sending SIGHUP always results in the log file
being reopened; GitHub #485 (Ian)
repmgrd: report version number *after* logger initialisation; GitHub #487 (Ian)
diff --git a/doc/repmgr-standby-clone.sgml b/doc/repmgr-standby-clone.sgml
index e4095c08..fa754834 100644
--- a/doc/repmgr-standby-clone.sgml
+++ b/doc/repmgr-standby-clone.sgml
@@ -49,7 +49,7 @@
not be copied by default. &repmgr; can copy these files, either to the same
location on the standby server (provided appropriate directory and file permissions
are available), or into the standby's data directory. This requires passwordless
- SSH access to the primary server. Add the option --copy-external-config-files
+ SSH access to the primary server. Add the option
to the repmgr standby clone command; by default files will be copied to
the same path as on the upstream server. Note that the user executing repmgr
must have write access to those directories.
@@ -59,12 +59,29 @@
--copy-external-config-files=pgdata, but note that
any include directives in the copied files may need to be updated.
+
+
+
+ When executing repmgr standby clone with the
+ aand
+ options, &repmgr; will check the SSH connection to the source node, but
+ will not verify whether the files can actually be copied.
+
+
+ During the actual clone operation, a check will be made before the database itself
+ is cloned to determine whether the files can actually be copied; if any problems are
+ encountered, the clone operation will be aborted, enabling the user to fix
+ any issues before retrying the clone operation.
+
+
+
For reliable configuration file management we recommend using a
configuration management tool such as Ansible, Chef, Puppet or Salt.
+
diff --git a/repmgr-action-standby.c b/repmgr-action-standby.c
index 86a14021..3ac147ec 100644
--- a/repmgr-action-standby.c
+++ b/repmgr-action-standby.c
@@ -471,6 +471,7 @@ do_standby_clone(void)
termPQExpBuffer(&msg);
r = test_ssh_connection(runtime_options.host, runtime_options.remote_user);
+
if (r != 0)
{
log_error(_("remote host \"%s\" is not reachable via SSH - unable to copy external configuration files"),
@@ -498,32 +499,41 @@ do_standby_clone(void)
termPQExpBuffer(&msg);
+
/*
* Here we'll attempt an initial test copy of the detected external
* files, to detect any issues before we run the base backup.
*
* Note this will exit with an error, unless -F/--force supplied.
*
+ * We don't do this during a --dry-run as it may introduce unexpected changes
+ * on the local node; during an actual clone operation, any problems with
+ * copying files will be detected early and the operation aborted before
+ * the actual database cloning commences.
+ *
* TODO: put the files in a temporary directory and move to their final
* destination once the database has been cloned.
*/
- if (runtime_options.copy_external_config_files_destination == CONFIG_FILE_SAMEPATH)
+ if (runtime_options.dry_run == false)
{
- /*
- * Files will be placed in the same path as on the source server;
- * don't delete after copying.
- */
- copy_configuration_files(false);
+ if (runtime_options.copy_external_config_files_destination == CONFIG_FILE_SAMEPATH)
+ {
+ /*
+ * Files will be placed in the same path as on the source server;
+ * don't delete after copying.
+ */
+ copy_configuration_files(false);
- }
- else
- {
- /*
- * Files will be placed in the data directory - delete after copying.
- * They'll be copied again later; see TODO above.
- */
- copy_configuration_files(true);
+ }
+ else
+ {
+ /*
+ * Files will be placed in the data directory - delete after copying.
+ * They'll be copied again later; see TODO above.
+ */
+ copy_configuration_files(true);
+ }
}
}