对于夜莺的tsdb模块，在生产环境如何做高可用部署，很多朋友不太清楚，这里做个简单介绍。

大家应该清楚，tsdb是一致性哈希分片的，所以，每台tsdb都承担了集群中唯一的一份数据，如果这个tsdb实例所在的机器硬盘故障，这部分数据就彻底丢掉了。如果不想丢数据，怎么办？这里我们可以双写。即做两个tsdb集群，监控数据上报之后，同时写入集群1和集群2，这样一来，如果其中一台机器挂掉了，至少还有一个集群在，问题不大。

举例：

  1. 集群1：c1-i1.bj:5821和c1-i2.bj:5821，共2台机器
  2. 集群2：c2-i1.bj:5821和c2-i2.bj:5821，共2台机器

在transfer的配置文件里，要把这4台机器都配置上，格式如下：

  1. tsdb01: c1-i1.bj:5821,c2-i1.bj:5821
  2. tsdb02: c1-i2.bj:5821,c2-i2.bj:5821

这里tsdb01和tsdb02这两个标识，就相当于两个槽位，监控数据来了，均分给这俩槽位，每个槽位又对应多个实例，槽位里边的多个实例，数据完全一致。

这样就配置好了，后面集群维护时，如果tsdb进程本身如果挂了，那问题不大，重新起来就可以了，如果某个tsdb实例所在机器的硬盘故障，直接丢数据了，怎么办？

某实例故障

比如c1-i1.bj:5821这个实例所在的硬盘故障了，上层transfer推送数据过来的时候，发现tsdb01这个槽位里只有一个实例，那就只能推送数据到这一个实例：c2-i1.bj:5821；查询数据的时候，如果某个数据落在tsdb01这个槽位，那就有可能从c1-i1.bj:5821这里查询，但是这个实例挂掉了，所以查不到数据，transfer会自动尝试c2-i1.bj:5821，所以对上层是没影响的。

此时我们换好了硬盘，或者直接找了个新机器要顶上去，怎么做？需要通过运维的手段，把c2-i1.bj:5821的数据sync到新机器上去，sync完了之后，再启动。

还有另一个办法，不通过运维的手段sync数据，直接怼上去，但是要在这个新机器上配置migrate机制：

migrate:
  enabled: true
  oldCluster:
    tsdb01: c2-i1.bj:5821
  newCluster:
    tsdb01: c1-i1.bj:5821

这样一来，如果有数据写入或查询过来的时候，c1-i1.bj:5821发现本机没有rrd文件，就会自动去c2-i1.bj:5821拉取对应的rrd文件。migrate机制这里就不展开了。

另外，请使用xfs文件系统。