新 Pika 主从数据全量同步方案

[AlexStocks]

背景：pika 主从全量同步机制目前依赖 rsync，由此导致了很多问题，目前需要去除 rsync 重新实现一套新的 主从数据全量同步方案。

[luky116]

方案示例：

分析

现状问题：

1、当前 Pika 已经支持了增量复制功能，这块功能可以保留，无需改动；

2、全量同步时，Rsync 是一个单独的进程，这个进程的声明周期和状态不受 Pika 影响，无法很好的进行管理。

设计新方案的时候，需要考虑如下这些问题：

1. 全量同步

2. 同步耗时问题

3. 1. 并发传输
   2. 压缩算法

4. 同步过程中服务的可用性

5. 断点续传

6. 文件校验

7. 速率限制

8. 传输时间预估ETA(estimated time remaining)

思路

思路有两个，第一种是寻找一个类似 rsync 的文件传输工具，来替代本地启动一个 rsync 进程。这个方案的优点是开发量相对较少，能在短期内快速上线；缺点是受限于第三方的实现，不好做太多的定制化功能；

另一种思路是使用网络库，自己从头实现一套数据复制方案。这个方案的优点是很灵活，缺点是开发量较大，测试工作较多，周期比较长。

方案

MetaSync 和 TrySync 的流程，在原来的基础上做了一点的改进，加了一个 master run_id 的判断。这样能保证如果 slave 切换了新的 master，能进行全量同步。

BinlogSync 的流程（增量同步）不做改动，DBSync 的流程（全量同步）改为使用 socket.sendfile 来做文件的传输：