From be4fc617c888ee0c07edb8b646f3b2b064d75535 Mon Sep 17 00:00:00 2001 From: Kaveh Vahedipour Date: Thu, 29 Aug 2019 16:37:57 +0200 Subject: [PATCH] renaming parameters --- 3.5/backup-restore.md | 2 +- 3.5/programs-arangobackup-examples.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/3.5/backup-restore.md b/3.5/backup-restore.md index 4ebd5f30c6..625a278916 100644 --- a/3.5/backup-restore.md +++ b/3.5/backup-restore.md @@ -88,7 +88,7 @@ hot backup the following is done: all locks are released again to allow writes to continue. If it is not possible to acquire all local locks in the same period, and this continues for an extended, configurable amount of time, the coordinator gives - up. With the `forceBackup` option set to `true`, it proceeds instead + up. With the `allowInconsistent` option set to `true`, it proceeds instead to create a potentially non-consistent hot backup. - **On each database server** create a new local directory under `/backups/_`. diff --git a/3.5/programs-arangobackup-examples.md b/3.5/programs-arangobackup-examples.md index cb32e84739..74fa3c0a54 100644 --- a/3.5/programs-arangobackup-examples.md +++ b/3.5/programs-arangobackup-examples.md @@ -43,9 +43,9 @@ acquisition of the global write transaction lock. One is that one can configure how long the system tries to get the global write transaction lock before it reports failure. This is the `--max-wait-for-lock` option. Its value must be a number in seconds and the default is 120 -seconds. The second is the `--force` option, whose default is `false`. +seconds. The second is the `--allow-inconsistent` option, whose default is `false`. If set to `false`, the operation is considered to have failed if the -maximal waiting time for the lock is exceeded. If `--force` is set to +maximal waiting time for the lock is exceeded. If `--allow-inconsistent` is set to `true`, the system will take a potentially non-consistent hot backup when the timeout is exceeded.