我有两个在 dnsmadeeasy 中配置了故障转移的 cpanel 服务器（A->B）。我现在已经设置了一个 rsync 来从 A->B 每 4 小时同步一次 /home/account 文件夹。
所以当 A 发生故障时，B 接管服务器 A 中 4 小时的积压数据。
我的问题是当 A 从故障中恢复正常时，B 中的 rsync 会覆盖来自 A 的数据，因为 rsync 是 A->B。
我想知道在第一次故障转移后防止 rsync 运行的最佳方法是什么，以便我可以手动处理 rsync。我正在考虑一个 shell 脚本，它将尝试访问服务器 A 中的文本文件，如果导致失败将停止 cron 运行。
这是处理这个问题的好方法，还是有更简单的方法？
【问题讨论】：
嗯，我在办公室的一组服务器上做了类似的事情。我发现运行良好的概述只是运行一个 cron 脚本，它将每个其他服务器的状态保存在一个临时状态文件中，并通过调用 ping 来更新状态。
具体来说，该例程通过维护要包含在检查中的主机列表来工作。每个主机（与运行 cron 作业的机器匹配的名称除外）在 /tmp 目录中维护一个名为 hoststatus.$HOSTNAME 的状态文件。每个状态文件包含up 或down。 （如果状态文件不存在，则在检查过程中创建并假设）。状态文件本身提供了一种本地方法，可以在运行任何脚本之前检查每个远程主机的状态。
检查状态的 cron 作业读取每个远程主机的状态文件并将状态提供给 case 语句。对于状态为up 的case，使用ping -c1 hostname 调用远程主机。如果 ping 成功，则脚本退出（远程主机已启动）。如果 ping 失败，则脚本等待 20 秒（以确保遥控器没有重新启动，等等。然后再次检查。如果第二次调用成功，则状态保持为 up 并且脚本退出。如果第二次调用ping失败，等待20秒重复，重新测试。如果第三次测试失败，则写入状态文件down，认为远程主机宕机。
继续 case 语句，如果初始状态为 down，则使用 ping 进行简单检查。如果成功，则状态更改为up，如果失败，则保持down。
还会保留反映每次状态更改的日志文件，以提供服务器可用性的运行历史记录。
类似的东西对你有用。如果服务器A 宕机，服务器B 可以用类似rsynchold.hostA 的类似方式编写一个简单的日志，在A->B 或B->A 之间运行rsync 之前检查该日志。这将允许您在失败后对第一个 rsync 进行手动干预——此时您可以重置 rsynchold.hostA 文件。
这并不优雅，但在过去几年中证明它相当万无一失。
【讨论】：