在官网用户手册的系统工具（System Tools）一栏，有一个同步工具（Sync Tool），有很多人问这个东西怎么用，延迟是多少，今天就介绍一下这个工具的使用场景、基本原理和测试技巧。
正文 2439 字，预计阅读时间 7 分钟。
使用场景
某公司有多个电厂，每个电厂内部署了一个 IoTDB，负责监控电厂内多个设备的运行状态。各个电厂间数据不互通。这个时候公司想建一个云平台，汇总所有电厂的数据进行分析（这里有一个前提，云平台的数据分析主要针对长期历史数据，对数据的实时性要求不高）。这时候就可以用这个文件同步工具了。
文件同步工具的定位：将一个 IoTDB 的 Schema 和数据文件（TsFile）同步至另一个 IoTDB 中，同步过程会有一定延迟，具体延迟取决于负载和配置。
基本原理
通过名字应该能看出来，这个工具的同步粒度是数据文件，而不是每一个数据点。这也就导致同步的最长延迟是一个数据文件的生成耗时（从创建文件到封口）。因为发送端必须等一个文件生成好才会同步，否则传过去半个文件也没法解析。传文件类似 scp，相对同步每条数据的好处就是避免了数据的解析和重新导入。
我们把文件同步涉及到的两个 IoTDB 称为发送端、接收端。
写入流程
为了更好的理解数据文件的生成耗时，需要简单介绍一下写入流程。
IoTDB 采用了 LSM 结构，数据先写到内存缓冲区 memtable 中，memtable 达到一定大小会落盘，多个 memtable 会对应一个数据文件。
举个例子，某个存储组有 1 个时间序列，写入频率为 1 秒，每个数据点是 16 字节。一个 memtable 大小为 160 字节，TsFile 文件大小为 200 字节。存储组刚开始有一个空的 TsFile 可供写入。
（1）memtable 第一次存满 10 个数据点时，提交一个异步刷盘任务（追加到当前正在写入的 TsFile 中），同时检查 TsFile 大小，这个时候还是 0 字节，先不关文件。
（2）异步的刷盘任务开始执行，刷完之后 TsFile 变成了 200 字节。
（3）memtable 第二次存满 10 个数据点时，提交一个异步刷盘任务，同时检查 TsFile 大小，发现到了 200 字节，于是就标记关文件。
（4）异步刷盘任务开始执行，刷完之后把当前 TsFile 关掉。
在这个例子里，写满 2 个 memtable （20条数据） 关闭一次文件，写入频率为 1 秒，文件的生成耗时是 20 秒左右。
同步流程
发送端定时检查本地有没有新创建的 Schema 和新生成的完整的数据文件，如果存在，就发给接收端。同步的延迟基本就是 max(同步检查间隔，文件生成耗时)。
在 iotdb-sync-client.properties 配置文件中，有一个参数sync_period_in_second，这个控制发送端检查的频率。假如配置 60 秒，那同步的最长延迟就是 60秒，如果配置 10秒，那延迟就是 20秒（一个文件的生成耗时）。可以看到，同步延迟跟配置有关系，跟写入频率也有关系。
配置文件里的 sync_period_in_second 可以配的比较小，没啥大问题。主要问题是 TsFile 的生成间隔，这个由 memtable_size_threshold 和 tsfile_size_threshold 控制，这两个参数，尤其是 memtable 越大，历史数据查询越快。因此，同步能达到的最低延迟和查询性能之间需要平衡。
一个比较简单的查看自己系统里文件的生成速率，可以到数据目录 data/data/存储组{/分区} 看 .resource 文件的最后修改时间间隔。
测试同步
在一个机器测试同步，示例脚本为 linux 环境，版本 0.10.1。先下载二进制包，解压缩两遍重命名，一个 sender，一个 receiver。
启动接收端
cd receiver
## 配置
conf/iotdb-engine.properties 中的 is_sync_enable=true
## 启动接收端 IoTDB
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动接收端 CLI，默认用 root 用户连本地 6667 端口
./sbin/start-cli.sh
启动发送端，准备数据
cd sender
## 配置
conf/iotdb-engine.properties 中的 rpc_port=6668
conf/iotdb-sync-client.properties 中的 sync_period_in_second=10
## 启动 iotdb
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动发送进程
nohup ./tools/start-sync-client.sh >/dev/null 2>&1 &
## 启动发送端 CLI，注意，改到 6668 端口了
./sbin/start-cli.sh -h 127.0.0.1 -p 6668 -u root -pw root
## 输入
insert into root.turbine1.d1(timestamp,s1,s3) values(2,1,3);
flush （这个是精髓，强制把 memtable 刷盘，文件封口）
接收端验证数据
## 在接收端 CLI 中输入
select * from root
如果想自己配置，需要先把 enable_parameter_adapter 置为 false，不然系统会自动调 memtable 和 tsfile 大小。
具体可参考用户手册，也可点阅读原文跳过去。
http://iotdb.apache.org/zh/UserGuide/V0.10.x/System%20Tools/Sync%20Tool.html
总结
文件同步适合对实时性要求没那么高的数据汇总，备份。秒级或分钟级的同步就需要换方案了。在实验中遇到数据没同步过去的，要么是同步的定时检查间隔设置的过长了，要么是文件没关闭，现在还没有定时关文件的机制，需要手动调用 flush。对了，提示一个东西，start-cli.sh 脚本也可以连远端的 iotdb，加上 -h -p -u -pw 参数就行了。