Tokyo Cabinet & Tyrant 多服务器节点master-master部署思考

Tokyo Cabinet & Tyrant支持master-slaver和master-master两种分布式方式的部署,但是由于master-slaver在master宕机后需要重新手动设置master,这种冷启动的方式不是特别好;而且master-slaver的方式基本上是用来处理多读少写的操作,对于读写比例不大的我们的项目,感觉更适合使用master-master的方式。

假设有两台机器作为分布式中的两个master服务器,取名为TT1和TT2,假设IP为10.10.13.11和10.10.13.12。

安装完TC和TT后,直接运行TTserver,脚本为:

TT1:
Shell代码
  1. mkdir ulog   
  2. ttserver -port 1977 -ulog ulog -sid 1 -mhost 10.10.13.12 -mport 1978 -rts 1.rts casket-1.tch  


TT2:
Shell代码
  1. mkdir ulog   
  2. ttserver -port 1978 -ulog ulog -sid 2 -mhost 10.10.13.11 -mport 1977 -rts 2.rts casket-2.tch  

启动后,日志显示如
Log代码
  1. 2010-06-02T10:12:11+08:00       INFO    connected: 10.10.13.12:60330  
  2. 2010-06-02T10:12:11+08:00       INFO    doing repl command   
  3. 2010-06-02T10:12:11+08:00       INFO    replicating to sid=2 after 1275379364260424  
  4. 2010-06-02T10:12:12+08:00       INFO    replicating from sid=2 (10.10.13.11:1977) after 1275443629795059  

启动完成后,master-master方式的TTserver就可以运行了。根据TT的自动复制策略,写入到TT1上的数据会被复制到TT2上去,反之亦然。

一些参数说明,具体参考 http://1978th.net/tokyotyrant/spex.html
Tt代码
  1. -ulog path : specify the update log directory.   
  2. -sid num : specify the server ID.   
  3. -mhost name : specify the host name of the replication master server.   
  4. -mport num : specify the port number of the replication master server.   
  5. -rts path : specify the replication time stamp file.   
  6. ".tch", the database will be a hash database.  


需要注意的是,如果TT1宕机并且持久化文件casket-1.tch丢失,重启后可能有数据无法从TT2上同步的问题,原因是rts的时间戳设置的太大了,修改1.rts中的值为0,则会从TT2上获取所有的数据。新加入的节点,首次创建时其rts中的值默认为0,所以会同步到所有的数据。

TTmaster-master的介绍并不多,只找到了双机做master的情况,而且他们之间的复制是互为master-slaver的复制方式。并且单个节点只能与一个节点作master-slaver,这样的话,暂时只能为环状方式的复制;而且只要其中一个节点坏掉,都会有数据过期的可能。robbin大哥说的没错,TT&TC确实不是用来作为分布式数据库存在的。

综合TT和master-slaver和master-master方式,完全可以做到mysql的双机做master,然后每个master后面挂slaver的方式了,不需要额外的代码。

真正作为服务器运行的话,还需要加入一些额外的参数,如持久化文件的压缩,曾经有同事在作测试时发现文件大小一直增加的情况,加入压缩的参数情况得到好转。

你可能感兴趣的:(Tokyo Cabinet)