最近有朋友的链不出块了，找我定位问题。最后分析，大都是由于链的数据被破坏了，导致区块链无法自动恢复数据。请注意，这里的链数据被破坏，指的是这条链上的所有节点数据都有问题。
节点数据被损坏，最直接的原因是由于 CITA 系统正在写磁盘过程中被异常中断，而常见的情况有：
- 节点停电 （收到过多次反馈）。
- 磁盘空间不足 （收到过两次反馈）。
- 磁盘被损坏 （尝未收到过类似反馈）。
大家也许会感到奇怪，CITA 明明是一个数据多副本的高可用系统，即使有一两个节点数据出问题，系统是能够自动从其它节点恢复数据的；但却偏偏出现了整条链的数据不可用。其实，这是由于大家不小心把一个高可用的软件部署成了一个单点系统。下面我就来数数这些不小心的杀手，看看你中了哪个？
Top 1: 将所有 4 个 CITA 节点部署在一个 Docker 容器中
这是最明显的一个单点系统部署方案。为了演示的方便，CITA 在 快速入门 中给的就是这种方案。这样可以很快地获得一个 CITA 链的测试环境，但它是一个非常明显的一个单点系统。一旦这个 docker 容器被 kill 掉，就相当于 4 个 CITA 节点同时被关机，就会出现上面所说的链数据被破坏的情况。反正是自己本地的测试环境嘛，最简单的处理方案就是直接删除所有节点下的数据，重新来过。
Top 2: 将所有 4 个节点部署在同一个物理机上
这种部署方案没有第一种那么明显，但也是一个单点的部署。也曾有朋友找过我们定位类似的问题，他的部署问题比我想象中要隐蔽；他在同一台物理机上运行了 4 个虚拟机，在每个虚拟机中部署一个 CITA 节点。
这个问题定位了蛮久的，最后才知道是 4 个虚拟机部署在同一个物理机上，而这个物理机突然断电了。这其实也是一个单点系统，一旦物理机出现宕机，整条链的数据也会同时出现问题。
Top 3: 多个节点部署在不同计算单元中，而数据却指向同一远端磁盘卷
有位朋友希望把数据与计算分离，就交 CITA 计算部分用容器云实部署，而磁盘却同时指向了远端的同一磁盘卷。最后磁盘空间不足了，也导致了所有节点的数据出了问题。
这其实比上面两种来得更隐蔽，是磁盘的单点导致了整个系统的单点。
Top 4: 将多个节点部署在云计算的同一个机房中
当机房同时出现故障，所以 CITA 节点也就有可能同时出现数据不可用。不过，这种情况还没有朋友反馈过，估计概率比较小。
当出现以上故障的时候，大多的错误日志如下面的 talk 所述：
即所有节点的 cita-bft.log 都在下一高度出现了 there is no proof 的日志，或者在所有节点的 cita-auth.log 中出现 cita-bft wal save error 日志。
在这种情况下，你可以参考下面的 talk 来手工尝试恢复链的运行：
但我并不能保证 100% 能成功。如果不成功，只能尝试重放或其它手段，得 case by case 分析了。
但是，如果在生产环境中部署 CITA，我强烈建议大家采用分布式的方式来部署，将链数据部署在不同的物理环境。如选择云供应商在不同地理位置的云主机，或者直接将节点部署到不同的云供应商的主机下。以免出现在特殊场景下造成链数据不可恢复的风险。
上一篇 : Quota 与 Quota Limit
下一篇 : [ CITA 的账户与数字签名 ]