fastdb 容错支持

 

Fault tolerant support

从2.49版本开始fastdb提供了可选的容错支持。可以启动一个主要的（活动的）和几个备用的结点，所有在主要结点发生的变化同时被复制到备用结点上。如果主结点崩溃，其中一个备用结点将变为活动的并成为主结点。一旦一个崩溃的结点重新启动，它要进行恢复，与主结点的状态同步，然后作为备用结点投入使用。结点通过套接字连接并规定放置在不同的计算机上。通信被假定为时可靠的。

要使用容错支持，应该使用REPLICATION_SUPPORT可选项来重新编译fastdb.在makefile开始把FAULT_TOLERANT变量设置为1来把它打开。应该使用dbReplicatedDatabase来代替dbDatabase。在open方法的参数中，除了数据库名和文件名之外，应当指定这个结点的标志符(从0到N-1的整数)，包含所有结点地址(主机：端口)的数组以及结点数(N).然后就可以在N个结点的每一个启动程序。一旦所有的实例都启动，ID=0的结点成为活动的（主结点）。在这个实例中open方法返回true.其他结点在open方法堵塞。如果主结点崩溃，其中一个备用结点被激活（open方法返回true）,然后这个实例继续执行。如果崩溃的实例重新启动，它将尝试连接所有服务器，恢复其状态然后作为备用结点，等待其代替崩溃的主结点的机会。如果主结点正常终止，所有备用结点的close方法返回false.

在容错模式下fastdb保留两个文件：一个包含数据库本身，另一个则是页更新计数器。带有页更新计数器的文件用于增量恢复。当崩溃结点重启动时，它将向主结点发送页计数器，并只接受这段时间在主结点发生变化的页（其时间戳大于被恢复的结点所发送的页）。

在复制模式中（在主结点）应用程序在事务提交期间并不阻塞知道所有的变化被刷新到硬盘。以改变的页由独立的线程异步的刷新到磁盘上。这样带来了显著的性能提升。但如果所有的结点都崩溃了，数据库就可能处于不一致状态。也可以指定向硬盘刷新数据的时间延迟：延迟越大，磁盘IO开销越小。但在崩溃的情况下，需要从主结点发送更多的数据以进行恢复。

可以在无盘模式中使用容错模式（DISKLESS_CONFIGURATION构建选项）。在这种情况下，没有数据保存在磁盘上（没有数据库文件，也没有页更新计数器）.假定至少有一个结点总是活动的。只要有一个在线结点数据就不会丢失。当崩溃结点恢复时，主结点向其发送完整的数据库快照(增量恢复是无法实现的因为崩溃结点的状态已经丢失)。由于这种模式没有磁盘操作，操作性能是非常高的并且只受限于网络吞吐量。

当复制结点启动后就开始在指定的时限内尝试连接所有其他的结点。如果在这个时间内无法建立连接，则该结点被假定为自主启动的并作为普通（非复制）数据库开始工作。如果结点与其它结点建立了连接，则具有最小ID的节点被选为复制主结点。所有的其他结点被切换到旁置模式并等待来自主结点的复制请求。如果主结点和从结点的数据库的内容不一致（使用页计数器数组来决定），则主结点进行旁置结点的恢复，向其发送最近的页面。如果主结点崩溃，则旁置结点选择一个新的主结点（最小ID的节点）。所有的旁置结点都在open方法堵塞直到下面的情况之一发生：

1． 主结点崩溃并且该节点被选为新的主结点。在这种情况下open方法返回true。

2． 主结点正常关闭数据库。在这种情况下所有复制结点的open方法返回false。

可以从其他应用程序中对复制数据库进行只读的访问。在这种情况，复制的结点必须通过dbReplicatedDatabase(dbDatabase::dbConcurrentUpdate)构造掉用来创建。其他应用程序可以用dbDatabase(dbDatabase::dbConcurrentReadMode)实例来访问同一数据库。

并非所有应用都需要容错。许多应用使用复制只是为了提高可测量性，在许多结点间分担负载。对于这些应用，fastdb提供了简化复制模型。在这种情况下，有两种结点：读者和写者。任何一个写者结点都可以作为复制主结点。而读者结点只能从主结点接收复制的数据而不能自己更新数据库。与上面所述的复制模型的最主要区别是读者永远不能变成主结点并且这个结点的open方法一旦与主结点建立了连接就马上归还控制权。来自主结点的更新通过单独的县城接收。读者结点要用dbReplicatedDatabase(dbDatabase::dbConcurrentRead)构造器来创建。必须使用预主结点同样的数据库模式（类）。当主结点关闭连接时来自读者结点的数据库连接并不自动关闭，其仍然保持打开并且应用仍然可以以只读模式访问数据库。一旦主结点重启，就会与所有的旁置结点建立连接并继续向它们发送更新。如果没有读者结点，则复制模型就等同于前面所述的容错模型，如果只有一个写者结点和一个或多个读者结点，这就是经典的主从复制。

可以使用Guess例子来测试容错模式。这个例子用-DREPLICATION_SUPPORT编译展示了3个结点的簇(所有地址指向localhost,但你当然也可以用你的网络中真实的主机来代替他们)。必须用参数0..2来启动guess应用的3个实例。当所有的实例启动后，用参数0启动的应用开始正常的用户对话(这是游戏：“guess an animal”).如果你用Crtl-c来模拟该应用程序的崩溃，则其中的一个备用结点继续执行。

testconc示例演示了更复杂的复制模型。有3个复制结点，通过使用testconc update N 命令来启动，其中N是这些结点的标志符：0，1，2。启动了这3个结点后，它们就会互相连接，结点0成为主结点并开始更新数据库，把改变复制到结点1和2。可以启动一个或多个检查者，即用只读模式（使用dbConcurrentRead访问类型）来连接到复制的数据库的应用程序。检查者可以用testconc inspect N T来启动，其中N是检查者要连接的复制结点的标志符，T是检查线程的编号。

同一个testconc示例可以用来演示简化的复制模型。启动一个主结点：testconc update 0,然后启动两个只读复制结点：testconc coinspect 1 和 testconc coinspect 2。请注意与前面所述的场景的区别：在容错模式下，普通的复制结点使用testconc update N命令启动，而连接到同一数据库的只读结点（不包括复制进程）通过testconc inspect N命令启动。在简化的主-从复制模型中，有只读的复制结点，其不能变成主结点（因此如果最初的主结点崩溃，没有人能够扮演这个角色），但运行在这个结点上的应用可以同通常的只读应用一样访问复制结点。