BerkeleyDB的同步
用BerkeleyDB较多了,但它的同步功能却从没用过,文档虽然有,但和BDB的其他文档一样,介绍得很单薄。用心看看示例代码 (源代码解包后,目录db-4.7.25/examples_c/ex_rep/),再结合文档,才算有些收获。
BDB将需要同步的n台机器作为一个Replication-Group,group内有一个master机器负责推数据,其它机器为replica(即 slave),接收数据。BDB同步方法类似mysql的同步,也是记日志并广播消息到slave机。BDB自带的示例程序测试结果显示,BDB可以平均 每秒同步1.2万条记录(单条记录25字节)。在master宕机后,Replication-Group内会进行一次选举,选出新的master,选举 算法应该是Bully算法(看rep_elect.c的代码,如看天书,但从选举时广播消息,猜测是常用的Bully算法)另外BDB要求“获胜者”收到 的票数必须是大于n/2(其中n为group中参选的机器总数,但也可由开发者选择n的值)
BDB为开发者提供两种调用同步机制的方法,一种是简 便的mgr方法,直接调用repmgr_*等API;另一种则由开发者来实现同步的框架。测试表明,直接调用repmgr_*同步速度很慢,建议自行实现 同步框架。同步框架要求开发者来实现Replication-Group内的机器列表、日志发送方式和开始选举的时间,并决定选举的“最少选民数”,即前 面提到的n。
BDB将需要同步的n台机器作为一个Replication-Group,group内有一个master机器负责推数据,其它机器为replica(即 slave),接收数据。BDB同步方法类似mysql的同步,也是记日志并广播消息到slave机。BDB自带的示例程序测试结果显示,BDB可以平均 每秒同步1.2万条记录(单条记录25字节)。在master宕机后,Replication-Group内会进行一次选举,选出新的master,选举 算法应该是Bully算法(看rep_elect.c的代码,如看天书,但从选举时广播消息,猜测是常用的Bully算法)另外BDB要求“获胜者”收到 的票数必须是大于n/2(其中n为group中参选的机器总数,但也可由开发者选择n的值)
BDB为开发者提供两种调用同步机制的方法,一种是简 便的mgr方法,直接调用repmgr_*等API;另一种则由开发者来实现同步的框架。测试表明,直接调用repmgr_*同步速度很慢,建议自行实现 同步框架。同步框架要求开发者来实现Replication-Group内的机器列表、日志发送方式和开始选举的时间,并决定选举的“最少选民数”,即前 面提到的n。
相关文章
- BerkeleyDB删除数据时的“内存泄漏”问题 - 04 08, 2009
- fedora 9 小集 - 01 05, 2009
- 多线程调试 - 12 17, 2008
留言: