本文档描述使用dragonboat的应用在部署上线以后的运维注意事项。请注意，不正确的运维方式将可能直接导致数据的永久性毁损。
- 建议使用ext4文件系统，其它文件系统未做任何测试。
- 必须使用本地硬盘，建议使用高写入寿命的企业级NVME固态硬盘，避免使用NFS、CIFS、Samba或Ceph等任何形式网络共享存储方式。
- Dragonboat所生成存储的数据绝不可通过直接文件、目录拷贝覆盖操作来进行备份与恢复。这将永久性损坏所涉及的Raft组。
- 每个Raft组已有多份副本，增加Raft组的副本数量是避免因部分节点故障失效而带来服务不可用及数据丢失的最好解决途径。比如，5个副本允许至少2个节点同时发生故障，它较3副本带来更高的数据安全与系统高可用性保障。
- 在个别节点发生故障后，如果多数派Quorum依旧存在、Raft组依旧可用，应该首先增加一个non-voting节点以开始立即同步Raft组状态，待同步完成后立刻将其升级为普通节点，然后通过成员变更移除故障节点。对于间歇性的可立即恢复的硬件故障，比如短暂的网络分区或系统掉电，可立即试图修复故障机器。
- 如发生磁盘损坏，比如发生磁盘相关数据的校验错，在排除系软件故障引起后，应立即停止该节点并替换磁盘，并通过上述组成员变更方法替换已永久故障的节点。在重启已确认磁盘故障的节点前，应确保已通过磁盘替换方式完全清空所有Dragonboat数据，且使用新磁盘的该节点应使用新的RaftAddress值，在IP或者DNS Name无法变更的情况下，可使用其它端口来确保RaftAddress被更新。
- 在极端情况下，当多数节点同时永久故障并无法修复时，Raft组将不可用。此时须使用github.com/lni/dragonboat/tools包提供的ImportSnapshot工具修复受损的Raft组。这需要用户日常定期使用NodeHost的ExportSnapshot方法导出并备份快照供此灾备用途。
- 在默认方式下，NodeHost每次重启后其RaftAddress不能变化，否则将报错。
- 如无法直接满足上述RaftAddress不变的要求，比如IP地址会在每次机器重启后因随机分配而变更，可考虑是否可以使用DNS Name并配合适当配置管理，来达到RaftAddress始终不变的要求。
- 如依旧无法按照上述方法满足RaftAddress不变的需求，可通过设置DefaultNodeRegistryEnabled项来开启gossip功能，它被设计用来处理动态的RaftAddress的场景，具体请参阅文档。
- 用户应该自行测试系统是否具备高可用性，并测试在不同数量规模与组合的节点失效情况下用户系统是否可以正确处理并保持Raft组的高可用。各类灾备维护应该是日常CI的一部分。