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：
mkdir ulog
ttserver -port 1977 -ulog ulog -sid 1 -mhost 10.10.13.12 -mport 1978 -rts 1.rts casket-1.tch
TT2：
mkdir ulog
ttserver -port 1978 -ulog ulog -sid 2 -mhost 10.10.13.11 -mport 1977 -rts 2.rts casket-2.tch
启动后，日志显示如
2010-06-02T10:12:11+08:00 INFO connected: 10.10.13.12:60330
2010-06-02T10:12:11+08:00 INFO doing repl command
2010-06-02T10:12:11+08:00 INFO replicating to sid=2 after 1275379364260424
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上去，反之亦然。
一些参数说明，具体参考[url]http://1978th.net/tokyotyrant/spex.html[/url]：
-ulog path : specify the update log directory.
-sid num : specify the server ID.
-mhost name : specify the host name of the replication master server.
-mport num : specify the port number of the replication master server.
-rts path : specify the replication time stamp file.
".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的方式了，不需要额外的代码。
真正作为服务器运行的话，还需要加入一些额外的参数，如持久化文件的压缩，曾经有同事在作测试时发现文件大小一直增加的情况，加入压缩的参数情况得到好转。
原文链接：https://blog.csdn.net/hankesi2000/article/details/83637583
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/7334
