随着企业业务的发展，系统架构趋于复杂、数据规模不断增大，数据分布存储在不同的地域、数据中心或云平台上的现象越发普遍，如何保证数据的可靠性和在线服务的连续性成为人们关注的重点。在此基础上，跨集群复制（Cross-Cluster Replication，CCR）应运而生，并逐渐成为数据和服务高可用性的重要保障。
CCR 通常被用于容灾备份、读写分离、集团与公司间数据传输和隔离升级等场景。
为满足上述各场景的需求，市面上也有不少数据产品推出 CCR 功能，其中比较有代表性的是 Elasticsearch 和 ClickHouse。
由于 CCR 是企业在系统服务可用性方面的强需求，因此许多厂商将其纳入产品的付费增值功能中，需要购买企业版才能使用。 秉持开源开放的原则，在 Apache Doris 2.0 版本中我们正式推出 CCR 来服务广大开源用户。
相较于 Elasticsearch 和 Clickhouse，Apache Doris CCR 可以在库/表级别将源集群的数据变更同步到目标集群，可根据场景精细控制同步范围；用户也可以根据需求灵活选择全量或者增量同步，有效提升了数据同步的灵活性和效率；此外 Doris CCR 还支持 DDL 同步，源集群执行的 DDL 语句可以自动同步到目标集群，从而保证了数据的一致性。Doris CCR 配置和使用也非常简单，简单操作即可快速完成跨集群数据复制。基于 Doris CCR 优异的能力，可以更好实现读写负载分离以及多机房备份，并可以更好支持不同场景的跨集群复制需求。
Doris CCR 的设计
在 Apache Doris 2.0 版本中，我们引入了 Binlog 机制来追踪数据的修改记录，包括 Meta Binlog 和 top="1881.890625">新增 Binlog
在 Apache Doris 2.0 之前的版本中，我们无法追踪到 Apache Doris 数据修改记录，而数据变更记录正是实现 CCR 的前置依赖。为解决该问题，在 Apache Doris 2.0 版本中，我们引入了 Binlog 机制，通过 Binlog 机制自动记录数据修改记录和操作，以实现数据的可追溯性，同时我们还可以基于 Binlog 回放机制来实现数据的重放和恢复。由于我们支持库表级别同步，因此在使用时需要为 DB/Table 添加 Binlog 相关的属性，目前 Binlog 支持 enable 和 ttl_seconds 这两种属性。
注意 ：如果想要使用 CCR 功能，开启 Binlog 是的必要前提条件。
alter table binlog set ("binlog.enable" = "true"); //开启 binlogalter table binlog set ("binlog.ttl_seconds" = "864000"); // 配置 binlog 过期时间alter>alter>持久化机制
为了确保在系统崩溃或者各种突发事件后可以得到及时恢复，我们引入了持久化机制，将数据持久化至磁盘来确保数据的可靠性和一致性。数据的持久化主要涉及 FE 所存储的元数据信息以及 BE 所存储的实际数据本身，在开启 Binlog 属性后，FE 和 BE 会将 DDL/DML 操作的修改记录持久化成 Meta Binlog 和>
在 FE 发起 Publish Transaction 的时候，BE 会执行对应的 Publish 操作，BE 会将这次 Transaction 涉及 Rowset 的元数据信息写入以 rowet_meta 为前缀的 KV 中，并持久化到 Meta 存储中，提交后会把导入的 Segment Files 链接到 Binlog 文件夹下。通过该方式，FE 的元数据和 BE 的数据可以构建一个逻辑上的 Binlog 系列。而该机制可以通过物理文件回放或逻辑回放来实现数据的恢复，在性能和可靠性方面均能提供有效的解决方案。
数据回放
为了更好的连接源集群及目标集群，我们引入了中间同步与控制组件——Syncer。通过 Syncer 可以将源集群的数据抽取到目标集群上，并且可以将 Binlog 系列抽取到另一个集群上进行数据回放。
具体实现：
Binlog 数据清理
随着数据导入越来越多，Binlog 记录的数据操作也会越来越多，占用的存储资源也会逐步增大。因此，我们需要一种数据回收机制来清理多余的 Binlog。
当我们进行 Binlog 数据清理时，在配置 Binlog GC 时我们需要注意 DB 和 TableBinlog GC 的同步状态。比如当用户在 Enable DB Binlog 之前 Enable Table Binlog，之后又需要 Disable DBBinlog 时，我们需要保持之前的 Table Binlog Enable 状态的相关配置，原因是 DB 的清理条件优先于 Table 的清理条件，如果 DB Binlog 是 Enable 状态，那么就需要按照 DB 的 GC 时间进行 Binlog 清理，否则就会出现 DB 和 Table 的清理状况是不一致，进而导致 Binlog 不一致的情况。
面对这种情况，FE 端会根据 Binlog 的过期时间定期扫描已经过期的 Binlog，将对应的清理过期请求下发给 BE，而 BE 会根据最后一条的 Commit Seq 对对应的 Tablet 进行元数据和 Rowset Binlog 的清理。在这个过程之中需要关注 DB 和 Table Binlog 的重叠情况。
如何使用 CCR
使用须知
目前在使用 CCR 时暂时需要开启 Doris 的 Root 权限，其他须知如下：
安装部署
下载和编译源码
git cloneccr-syncer# -j 开启多线程编译# --output指定输出的路径名称，默认名称为outputbash build.sh <-j NUM_OF_THREAD> <--output SYNCER_OUTPUT_DIR>编译完成的源码在 Output 文件夹中，与 Doris 类似启停脚本在 Bin 中，可执行文件在 Lib 中
# SYNCER_OUTPUT_DIR是编译的输出路径# SYNCER_DEPLOY_DIR是实际部署的路径cp -r SYNCER_OUTPUT_DIR SYNCER_DEPLOY_DIRcd SYNCER_DEPLOY_DIR# 启动syncer，加上--daemon使syncer在后台运行bash bin/start_syncer.sh --daemon# 停止syncerbash bin/stop_syncer.sh配置任务
enable_feature_binlog=true-- enable>ALTER>-- enable table binlogALTER TABLE enable_binlog SET ("binlog.enable" = "true");curl -X POST -H "Content-Type: application/json" -d '{"name": "ccr_test","host": "localhost","port": "9030","thrift_port": "9020","user": "root","password": "","database": "demo","table": "example_tbl""host": "localhost","port": "9030","thrift_port": "9020","user": "root","password": "","database": "ccrt","table": "copy"}'复制代码补充参数说明：
查看和取消状态
curl -X POST -H "Content-Type: application/json" -d '{"name": "ccr_test"}'复制代码curl -X POST -H "Content-Type: application/json" -d '{"name": "ccr_test"}'复制代码数据同步性能实测
为了测试 CCR 的数据同步效率，我们也进行了基于全量数据的导入测试。在全量数据的导入过程中，2TB 数据仅需不到 4 小时即可同步完成，单节点写入速度超过 170MB 每秒，具体结果见下方表格。随着集群规模的扩展，数据写入的效率呈线性提升的趋势。
需要说明的是，性能测试在特定的环境和配置上进行测试，结果与不同的环境、版本及配置有关，在此仅作为参考。
全量同步
源集群和目标集群均为 1FE 1BE 的集群，系统信息与硬件信息如下：
源集群数据量：2097152MB
目标集群数据量：0
全量同步性能测试结果
后续规划
目前 Doris CCR 已支持表和库级别的数据同步。具体来说，在表级别支持各种数据导入方式，支持轻量级和重量级 Schema Change，包括增加单表物化视图等，以支持更灵活的数据同步需求；同时 CCR 还支持动态分区，手动分区等。在库级别支持整库同步，可以将源集群中的所有表数据同步到目标集群中。此外，CCR 还支持创建和删除表的同步操作，可以在源集群中创建或删除表时，自动同步到目标集群中，以实现数据的同步和一致性。
未来我们还将在持续发力，不断提升 Doris CCR 的同步能力与性能，主要包括：
在此也欢迎有相关需求的同学积极在评论区反馈需求或问题。
作者介绍：
许瑞亮，资深研发工程师
李仕杨，SelectDB 生态研发工程师
