本节介绍了关于数据库复制的常见问题解答。
主节点与 NSX Advanced Load Balancer 集群断开连接时，会观察到什么情况？
以下是主节点与 NSX Advanced Load Balancer 集群断开连接时所观察到的情况：
由于未达到仲裁数，主节点重新启动并断开与 NSX Advanced Load Balancer 集群的连接。
其中一个从属节点发布一条消息，指出数据库复制未完成，因此无法成为主节点。
另一个从属节点将发布从主节点复制数据库 (DB replication from the leader) 消息，并成为主节点。
当 NSX Advanced Load Balancer 集群中的所有从属节点均无法完成数据库复制时，会发生什么情况？
在从属节点上，通过以下过程复制数据库：
检查是否可以启用数据库流复制。一般情况下，此操作应该会成功，因为 NSX Advanced Load Balancer 允许合理数量的 WAL 记录文件，可以满足此要求。如果此操作失败，或者这是首次将从属节点添加到集群，则从属节点会执行完整备份，这通常需要一段时间。
设置流复制后，NSX Advanced Load Balancer 每分钟都会监控复制是否在持续进行。如果连续五次检测到故障，则会声明复制失败并尝试进行完全复制。
尝试进行完全复制时，NSX Advanced Load Balancer 始终会将整个数据库数据目录完整复制到下一个目录中。只有在完成该操作后，才会移至数据库的当前目录。如果完整复制数据库文件的过程中出现故障，仍将有一个有效的当前目录。
在决定执行完整备份时，请务必记录此过程，以确保执行此过程的节点不会在此期间发生主节点故障时成为主节点。使用此方案时，从属节点必须始终保持同步，并且可以接替主节点。如果完全同步失败，安全机制将阻止节点接替主节点，但通过手动干预，您可以将其中一个从属节点提升为主节点。
尝试进行完全复制后，cluster_mgr 日志是否会每分钟显示一次同步？
可以在 /var/lib/avi/log/postgres_service_main.log 和 postgres_service_metrics.log 中找到完全复制过程的日志。
复制失败的常见原因有哪些？
永久性连接问题可能会导致复制失败。当从属节点上的 postgres 可以从其检查点恢复且位于主节点后面时，流复制始终会成功。在某些情况下，如果 postgres 未正常关闭，则可能无法从主节点进行复制。这将强制从主节点进行完整备份。
在数据库复制过程中，哪个目录是“当前”目录？哪个目录是“下一个”目录？
对于配置数据库：下一个目录是 /var/lib/postgresql/9.3/main_backup，当前目录是 /var/lib/postgresql/9.3/main/。
对于衡量指标数据库：下一个目录是 /var/lib/postgresql/9.3/pg_metrics/metrics_backup，当前目录是 /var/lib/postgresql/9.3/pg_metrics/metrics。
复制失败的症状有哪些？这些症状是否只能在主节点选举期间观察到？是否会为此类情况生成内部事件？
检测到复制失败时，会在 NSX Advanced Load Balancer 上观察到 DB REPLICATION FAILED 事件。
是否与集群融合有任何关系？如果有，具体在这方面做出了哪些最新改进？
当 NSX Advanced Load Balancer 检测到复制失败时，将触发完整备份。在此过程中，会通过 touch 在 /var/lib/avi/etc 中创建一个文件，以指示复制尚未完成。因此，如果发生融合，相应特定节点不会参与成为主节点。此外，此服务的状态将变为 COPYING_DB_FROM_LEADER，这会将节点状态从 CLUSTER_ACTIVE 更改为 CLUSTER_STARTING。整体集群状态不会显示为 CLUSTER_HA_ACTIVE。
最新版本的 NSX Advanced Load Balancer 是否仍在使用 zookeeper？如果没有使用，为什么它仍然在 NSX Advanced Load Balancer 上运行？发生了哪些变化？
最新版本的 NSX Advanced Load Balancer 不使用 zookeeper。运行 zookeeper 进程是为了实现向后兼容性。将先前版本的 NSX Advanced Load Balancer 升级到 17.2 后，控制器必须针对尚不在 17.2 中的 SE 在 ZK 中发布主节点信息。升级完成后，SE 将使用新方案发送主节点通知。之后，当所有升级都将从 17.2.x 进行时，将移除 ZK。
