BDB JE HA系列之Hot Upgrade(热升级)机制

HA的特性要求一个HA group能够提供7×24小时不间断的数据服务，如果因为给节点上运行的Berkeley DB Java Edition(简称JE)升级导致整个组或组内大部分节点关闭，显然是不能接受的。
往往一个版本的升级会有日志格式的变化或是HA协议的变化，在这种情况下，如果不支持热升级，就会出现数据服务中断的情况。在数据库行业内，解决这个问题有个通用的途径：先关掉副节点进行升级，最后再进行主节点的升级。
这样做的原因是因为HA主节点会将数据库所做的更改传到副节点，如果主节点的日志格式比副节点的日志格式版本高，那么副节点将不能识别这个更改，从而导致所有的副节点崩溃，数据服务也就中断了。
在理想的情况下，这种解决办法是可行的，但是如果在升级的过程中，主节点由于某些原因崩溃了，那么就有可能会将一个运行高版本日志格式的副节点选举为主节点，数据服务就会停止。
所以，解决问题的根本办法是：在任何情况下，都需要将运行最低版本日志格式的节点选举为主节点。在编码时，要将日志格式也作为选举的一个因素进行考量。在得到各个节点的proposal的时候，将其中的日志格式取出，判断当前组是否有多个日志格式，如果有则选出拥有最低日志格式的节点为主节点，并在组内广播该结果，这样就能保证任何时候都是有最低日志格式的节点成为主节点。
但是，在进行编码时，由于JE HA的第一个版本的选举协议不支持日志格式，而新版本的选举协议支持日志格式，导致协议的版本不一致。这带来了另外一个问题：新版本的选举协议不能被老版本的协议所识别，实际上这又是一个升级！
解决这个问题的办法是：高版本的选举协议必须能够识别低版本的选举协议，并在发现目标节点是运行低版本协议的时候，重新构造一个低版本的协议包，发送给对方，这样就能保证双方的通讯畅通无阻。也就是说将JE的选举协议升级成了能够容错的协议。
这个过程说起来简单，实现起来是相当复杂的，我花了大概4周左右的时间进行设计，编码和测试工作，而这个又是JE4.1版本必须要求的，因为4.2版本会有一个日志格式的变化，如果4.1不支持升级的话，那么从4.0和4.1就无法升级到4.2。
写这个blog的初衷是我在做这个工作的时候，发现在网上没有任何有关数据库版本热升级的资料，相当痛苦，我就想把这个写下来为后来的同学们提供一个参考，希望能够对大家的工作有所帮助。