本文说到的TTServer就是 TokyoTyrant＋TokyoCabinet ，是一个来自日本的持久化高性能的Key－Value存储，文章对TTserver 的安装启动，监控运维等方案进行了详尽的说明。推荐给使用TTserver的同学一看。
示例数据库目录 /data/ttserver_data
配置TTserver服务器的启动脚本
安装ttserver后默认在/usr/local/sbin目录下有ttservctl启动脚本示例，建议copy到具体ttserver数据存放的目录（一个机器可能有多个ttserver服务器，分开便于配置和管理）
cp /usr/local/sbin/ttservctl /data/ttserver_data/ cd /data/ttserver_data
配置启动脚本ttservctl , vim ttservctl；如：
# configuration variables basedir=”/data/ttserver_data” #数据库目录 port=”1978″ #ttserver端口 ulimsiz=”256m” #对单个ulog文件限制，超过将新建一个文件 sid=1 #server id同mysql，不能有重复的 mhost=”remotehost1″ #master的地址 mport=”1978″ #master端口 extfile=”$basedir/ext.lua” #lua扩展脚本文件，默认ttservctl没有这项，如果要使用lua扩展请加上， #并在启动脚本下面的逻辑代码中增加相应判断。 rtsfile=”$basedir/rts” #replication的时间记录文件 dbname=”$basedir/database_name.tch#bnum=bucket数量#xmsiz=最大使用内存”
#数据库名称及优化参数（“#”后面参数，根据需求配置，bnum推荐为记录数0.5-4倍，xmsiz理论上越大性能越好，默认64M，也可以使用默认配置，去掉“#”后面参数即可启动）
启动ttserver服务器：
./ttservctl start
关闭ttserver服务器：
./ttservctl stop
Note：可以放入rc.local中, ttserver启动脚本如果错误会有提示，也可以检查端口是否启用来确定ttserver的启动是否成功
TTserver的监控
监控命令：
tcrmgr inform -st -port 服务器使用的端口 监控服务地址
监控程序提供数据项包括：内存使用，数据文件大小,读写次数，未命中key数量等，由cacti定时读取实现监控
示例地址：http://…/cacti/graph.php?action=view&rra_id=all&local_graph_id=1050
增加磁盘io监控，iotop （iotop要求linux内核2.6.20以上）
Note：具体阀值可以设定iotop占总量的80%
TTserver的备份
全量热备份
备份命令为：
tcrmgr copy -port 1978 localhost dpath.tch.xxxxx (其中xxxxx为备份时间)
根据业务需求及数据库运行状态决定备份的频度,全量热备时数据库库会写锁定，读不受影响。全量备份需记录备份时间点以提供replication恢复时所用，时间记录点精确的微妙，可记录到备份文件名中，如backup.tch.1259474040630024。
示例备份脚本：
[ -n "$1" ] || { echo “input port number”; exit; }
[ -n "$2" ] || { echo “input backup dir”; exit; }
backup_date=`date +%s%N`
backup_date=`expr $backup_date / 1000`
tcrmgr copy -port ${1} localhost ${2}/backup_${1}.tch.${backup_date}
echo “back up finish! ${2}/backup_${1}.tch.${backup_date}”
增量备份ulog
ttserver产生的ulog在”$basedir/ulog”目录，设置了ulimsiz后会按文件尺寸进行切割并按数据升序命名，可以根据备份的频度，按ulog文件最后修改时间，备份到ulog最大命名数字的前一个文件，同时也需记录备份时间，可将时间记录在打包备份的文件名中，如backup_ulog.1259474040630024.tar.gz, 和全量备份一样，精确到微妙。
Note：全量备份速度和服务器情况有关，基本接近直接copy速度
TTserver的恢复
使用replication恢复
根据备份方案中数据库全量备份方法得到的备份库，如backup.tch.xxxxxx ,
echo xxxxxx > “$basedir/rts”
写入备份时间点，即恢复时间点
cp backup.tch.xxxxx database_name.tch
启动:
./ttservctl start
恢复的库会根据时间点去master库同步数据，实现恢复
使用日志增量恢复
先使用前一个全量备份的数据库文件作为基数据库，下线要整理的ttserver。
清空原来的日志，然后解压，再cp 备份的ulog文件 $basedir/ulog/ ，
echo xxxxxx > “$basedir/rts”
写入备份时间点（压缩文件名中包含），即恢复时间点
单独启动ttserver ：
ttserver database_name.tch
从日志恢复：
tcrmgr restore -port port -rcc localhost ulog
ctrl+c停掉ttserver，然后使用 ./ttservctl start 启动，master结构重新建立
Note：日志增量恢复环节应避免受其他ttserver的服务器影响，如可以使用一个不使用的端口进行恢复，这样数据也不会影响到其他服务器，恢复后再用原来的启动脚本启动，形成原来的dual master结构。
TTserver优化
定期优化，整理数据文件碎片，优化命令：
tcrmgr optimize -port port host
Note：整理时会锁库，读写都锁定
备注
基于dual master的结构具有较高的可靠性，dual master其实就是实时的热备方案，所以在备份频度和广度上是否可以适当宽松一些？建议每天备份全量即可，增量的日志一直留在服务器上，但是日志的分割尺寸要根据业务和恢复的粒度来确定。
PS：文章原出处难以考证，如有知情读者欢迎提供原文地址。
