如果主服务器失效，则后备服务器应该开始故障转移过程。

如果后备服务器失效，则不会有故障转移发生。如果后备服务器可以被重启（即使晚一点），由于可重启恢复的优势，那么恢复处理也能被立即重启。如果后备服务器不能被重启，则一个全新的后备服务器实例应该被创建。

如果主服务器失效并且后备服务器成为了新的主服务器，那么接下来旧的主服务器重启后，你必须有一种机制来通知旧的主服务器不再成为主服务器。有些时候这被称为STONITH（Shoot The Other Node In The Head，关闭其他节点），这对于避免出现两个系统都认为它们是主服务器的情况非常必要，那种情况将导致混乱并且最终导致数据丢失。

很多故障转移系统仅使用两个系统，主系统和后备系统，它们由某种心跳机制连接来持续验证两者之间的连接性和主系统的可用性。也可能会使用第三个系统（称为目击者服务器）来防止某些不当故障转移的情况，但是除非非常小心地建立它并且经过了严格地测试，额外的复杂度可能会使该工作得不偿失。

LightDB并不提供在主服务器上标识失败并且通知后备数据库服务器所需的系统软件。现在已有很多这样的工具并且很好地与成功的故障转移所需的操作系统功能整合在一起，例如 IP 地址迁移。

一旦发生到后备服务器的故障转移，就只有单一的一台服务器在操作。这被称为一种退化状态。之前的后备服务器现在是主服务器，但之前的主服务器处于关闭并且可能一直保持关闭。要回到正常的操作，一个后备服务器必须被重建，要么在之前的主系统起来时使用它重建，要么使用第三台（可能是全新的）服务器来重建。在大型实例上，lt_rewind功能可以被用来加速这个过程。一旦完成，主服务器和后备服务器可以被认为是互换了角色。某些人选择使用第三台服务器来为新的主服务器提供备份，直到新的后备服务器被重建，不过显然这会使得系统配置和操作处理更复杂。

因此，从主服务器切换到后备服务器可以很快，但是要求一些时间来重新准备故障转移集群。从主服务器到后备服务器的常规切换是有用的，因为它允许每个系统有常规的关闭时间来进行维护。这也可以作为一种对故障转移机制的测试，以保证在你需要它时它真地能够工作。我们推荐写一些管理过程来做这些事情。

要触发一台日志传送后备服务器的故障转移，运行lt_ctl promote，调用 pg_promote()，或者创建一个触发器文件，其文件名和路径由promote_trigger_file设置指定。 如果你正在规划使用lt_ctl promote或调用pg_promote()以进行故障转移，promote_trigger_file就不是必要的。 如果你正在建立只用于从主服务器分流只读查询而不是高可用性目的的报告服务器，你不需要提升它。

LightDB的高可用性默认使用keepalived提供虚拟IP，客户端连接虚拟IP而不是物理IP。当发生故障转移时，虚拟IP应该跟随正确的主服务器。然而，在特殊情况下，例如维护期间，您需要禁用自动故障转移，不希望虚拟IP移动。在这种情况下，您可以运行ltcluster service pause（详见ltcluster）以禁用自动故障转移。然后在主服务器上创建一个$LTDATA/primary.maintain文件，以防止虚拟IP自动移动。维护完成后，调用ltcluster service unpause以启用自动故障转移并删除$LTDATA/primary.maintain文件。

在ltcluster自动将备用服务器提升为主服务器后，将创建文件$LTDATA/standby.promotion以指示备用服务器已被提升。 如果出现多个主服务器（例如，在备用服务器被提升后，旧的主服务器恢复正常）， 则ltclusterd守护程序将保留具有$LTDATA/standby.promotion文件的数据库实例， 并停止没有此文件的主实例，以避免由多个主服务器引起的数据不一致风险。