ux_standby — 对创建一个UXDB热备服务器提供支持
ux_standby [option...] archivelocation nextwalfile walfilepath [restartwalfile]
ux_standby用于支持创建一个“热备”数据库服务器。它被设计为一个可以随时投入生产的程序，以及一个可定制的模板供你进行特定的修改。
ux_standby被设计成一个等待着的restore_command，它被用来把一次标准的归档恢复变成一次热备操作。还需要一些其他的配置，所有这些配置都在主服务器手册中有相应的描述。
要配置一台后备服务器去使用ux_standby，可以把下面的内容放在recovery.conf配置文件中：
restore_command = 'ux_standby archiveDir %f %p %r'
其中archiveDir是 WAL 段文件应该被存储的目录。
如果指定了restartwalfile（通常用%r宏指定），那么所有在逻辑上位于这个文件之前的 WAL 文件都将被从archivelocation中移除。这使需要被保留的文件数最小化，与此同时能够保持崩溃重启的能力。如果archivelocation对于这个特定后备服务器是一个瞬态区域，使用这个参数是合适的，但当archivelocation是一个长期 WAL 归档区域时则不是合适的。
ux_standby假定archivelocation是一个拥有服务器的用户可读的目录。如果指定了restartwalfile（或者-k），archivelocation目录必须也是可写的。
当主服务器失效时，有两种方式转移到一个“热备”数据库服务器：
在智能失效备援中，服务器在应用归档中可用的所有 WAL 文件之后被提升。即便后备服务器落后于主服务器，这也会导致零数据丢失，但是如果有很多未应用的 WAL，在后备服务器准备好之前就需要比较长的时间。要触发一次智能失效备援，创建一个包含单词smart的触发文件，或者只创建一个空文件。
在快速失效备援中，服务器被立即提升。归档中任何还未被应用的 WAL 文件将被忽略，并且这些文件中的所有事务都会丢失。要触发一次快速失效备援，创建一个触发文件并且把单词fast写在其中。ux_standby也能被配置为在一段定义好的区间内没有新 WAL 文件出现时自动执行一次快速失效备援。
ux_standby接受下列命令行参数：
-c 使用cp或者copy命令来存储来自归档的 WAL 文件。这是唯一支持的行为，因此这个选项是无用的。
-d 在stderr上打印大量调试日志输出。
-k 从archivelocation移除文件，这样当前 WAL 文件之前不超过这么多个 WAL 文件会被保留在归档中。零（默认值）意味着不从archivelocation移除任何文件。如果指定了restartwalfile，这个参数将被安静地忽略，因为那种说明方法对于决定正确的归档切断点更为精确。这个参数的使用已经被废弃，指定一个restartwalfile参数更加安全和有效。一个太小的值可能导致后备服务器的重启仍需要已经被移除的文件，而一个太大的值则浪费归档空间。
-r maxretries 设定拷贝命令失败时重试的最大次数（默认为 3）。在每一次失败后，澳门游戏平台注册网站等待sleeptime * num_retries，这样等待时间会逐步增加。因此默认情况下，澳门游戏平台注册网站将等待 5 秒、10 秒、15秒，然后向后备服务器报告失败。这将被解释为恢复的终点并且该后备服务器将会完全被提升。
-s sleeptime设置在检查要被恢复的 WAL 文件在归档中是否可用的测试之间休眠的秒数（最高 60，默认为 5）。
-t triggerfile 指定一个触发文件，它的出现将会导致失效备援。澳门游戏平台注册网站推荐使用一个有结构的文件名，这样可以避免在同一个系统上有多个服务器存在时无法确定是要触发哪个服务器。例如可以用/tmp/uxsql.trigger.5432。
-V--version打印ux_standby版本并退出。
-w maxwaittime设置等待下一个 WAL 文件的最大秒数，之后将会执行一次快速失效备援。设置为 0 （默认值）表示永远等待。
-?--help显示有关ux_standby的命令行参数，然后退出。
在 Linux 或 Unix 系统上，你可能会使用：
archive_command = 'cp %p .../archive/%f' restore_command = 'ux_standby -d -s 2 -t /tmp/uxsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/uxsql.trigger.5442'
其中归档目录被物理防止在后备服务器上，因此archive_command通过 NFS 访问它，但是那些文件对于后备服务器是本地的（启用ln）。这将：
在standby.log中产生调试输出
在检查下一个 WAL 文件的可用性之间睡眠 2 秒
只有当一个名为/tmp/uxsql.trigger.5442的触发文件出现时停止等待并且根据其内容执行失效备援
在恢复结束时移除触发文件
从归档目录中移除不再需要的文件
在 Windows 上，你可能会用：
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'ux_standby -d -s 5 -t C:\uxsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\uxsql.trigger.5442'
注意archive_command中的反斜线需要被双写，但是在restore_command或者recovery_end_command中不需要。这将：
使用copy命令恢复来自归档的 WAL 文件
在standby.log中产生调试输出
在检查下一个 WAL 文件的可用性之间睡眠 5 秒
只有当一个名为C:\uxsql.trigger.5442的触发文件出现时停止等待并且根据其内容执行失效备援
在恢复结束时移除触发文件
从归档目录中移除不再需要的文件
Windows 上的copy命令在文件被完全拷贝之前就会设置最终的文件尺寸，这通常会迷惑ux_standby。因此一旦看到正确的文件尺寸，ux_standby会等待sleeptime秒。GNUWin32 的cp只会在文件拷贝完成后设置文件尺寸。
由于 Windows 的例子在两端都使用copy，一个或者两个服务器可能通过网络访问归档目录。