tokyotyrant 使用经验

1、关于rcc参数

如果运行ttserver的时候，带上了rcc参数。那么在数据同步过程中，如果有一条数据执行错误，那么同步就会停下来，直到有人工干预。反之，如果没有rcc参数，同步会继续进行，但是在日志中，会报一个ERROR级别的错误。

建议，不带rcc参数运行ttserver，同时监控ttserver的日志，对ERROR级别的日志监控报警。

 

2、重连RCONN参数

接口函数tcrdbtune，可以传递 RDBTRECON开关，使ttserver有断开重连的机制。但这并不可靠，ttserver的通讯机制设计是有缺陷的，即没有message-id的考虑。在网络环境差的情况下，可能，你的第n次请求，得到的应答却是第n-1次请求的应答。所以安全起见，如果你的程序一旦检查到ttserver有网络异常情况（也同时要求程序必须检查），立刻关闭并释放掉ttserver句柄，要使用全新实例化的句柄进行接下来的操作。

 

3、ttserver的日志文集不能超过2G

其实这不只是ttserver的问题，不作特殊处理，在32bit系统，文件大小不能超过2G，但是这个问题容易被忽略。开始上线使用ttserver的时候，输出了debug级别的日志，导致日志文件膨胀迅速，很快就到了2G，导致了一次事故。采用的策略是：1、在一般情况下，可以不输出debug级别的日志；2、定时备份日志（cp命令），清空日志内容（echo "" > ttserver.log）；一般日志切分使用移动(mv)，和重启服务，在ttserver日志切分上尽量不采用这样的策略。

 

4、ttserver互为备份的两台数据不一致的时候

由于某些特殊原因，比如上面的3中情况，在处理不当的时候，会导致互为备份的两台服务器数据不一致，这个时候应该怎么处理，同时还不打断系统的正常运行。采用的方法是，修改系统配置，使得系统读写数据库时，只读写其中的那台正常的服务器，把异常的服务器从系统中剥离开来，然后采用ttserver的备份/恢复策略，使得两台服务器的数据一致。

我开始不是这样操作的，总是异常的服务器在重启后（基于从正常服务器的数据备份以及备份时的时间戳/版本号），就开始提供服务。这样实际上异常的服务器在提供正常服务（有读写操作）的同时，还要从正常服务器同步从备份数据到重启异常服务器这段时间产生的新数据。操作几次总不能成功，两边的数据总是有差异，没有深入思考为什么会这样，就搁置了，一直到现在，应该抽时间想一想为什么了