Master / Slave
Master Slave Type
| Requirements |
Pros |
Cons |
|
|---|---|---|---|
| A shared file system such as a SAN |
Run as many slaves as required. Automatic recovery of old masters |
Requires shared file system |
|
| A Shared database |
Run as many slaves as required. Automatic recovery of old masters |
Requires a shared database. Also relatively slow as it cannot use the high performance journal |
|
| ZooKeeper Server |
Run as many slaves as required. Automatic recovery of old masters. Very fast. |
Requires a ZooKeeper server. |
如果您正在使用一个共享的网络文件系统 主从我们推荐一个共享文件系统。如果你快乐,省却高性能日志和使用纯JDBC作为持久化引擎,那么您应该使用JDBC主从。对于那些愿意尝试新技术,复制存储并且给速度类似于圣的解决方案而不必的麻烦设置一个高度可用的共享文件系统。
KahaDB Replication (Experimental)
KahaDB支持可插入的主选举算法,但只有当前的实现是建立在 ZooKeeper.
ZooKeeper.用来实现主选举算法。饲养员是一个非常快,复制,在内存中数据库的特性,使它容易实现集群控制算法。这是一个你可以自由下载Apache项目。您必须安装并运行至少有一个 ZooKeeper.服务器之前建立一个KahaDB主从配置。
JDBC Master Slave
如果您使用的是纯JDBC和不使用高性能日志然后你通常依赖于数据库作为单点故障和持久性引擎。如果你没有很高的性能需求,这种方法可以大量的意义有一个持久性引擎备份和管理等。KahaDB Replication (Experimental)
KahaDB支持可插入的主选举算法,但只有当前的实现是建立在 ZooKeeper.
ZooKeeper.用来实现主选举算法。饲养员是一个非常快,复制,在内存中数据库的特性,使它容易实现集群控制算法。这是一个你可以自由下载Apache项目。您必须安装并运行至少有一个 ZooKeeper.服务器之前建立一个KahaDB主从配置。
Pure Master Slave
纯粹的主从配置提供一个基本的无共享,完全复制拓扑不依赖于一个共享文件系统或数据库共享。
一个奴隶的主人从主代理消耗所有消息状态——消息,确认和事务的状态。而奴隶是主动连接到主——它不允许或开始任何网络或传输连接器,它的唯一目的是复制的状态的主人。
代理消息交换时只会回复客户已成功传递到奴隶。例如,提交在客户的事务才会完成主人和奴隶已经提交处理。
Shared File System Master Slave
如果你有一个圣或共享文件系统可用于提供高可用性,如果一个代理被杀,另一个代理可以立即接管。基本上你可以尽可能多的经纪人希望运行相同的共享文件系统目录。第一个代理抓取的排它锁定文件是主代理。如果代理死了,释放锁的另一个代理接管。奴隶经纪人坐在一个循环试图抓住锁从主代理。