GBase RTSync实时同步之设置按组同步

GBase RTSync实时同步之设置按组同步

Gbase RTSync是南大通用自主研发的数据库增量数据实时同步产品，用于支持异构数据源的数据同步，包含指定库，指定表，指定列的增量同步及全量数据同步，其具备实时性、一致性、精准性、易扩展性特性。Gbase RTSync支持多种数据源之间的数据同步，如下图所示：

Gbase RTSync同步的基本原理，概念以及简单使用之前文章已经讲解过，我们这里不再过多讲解，只是简单帮大家回顾下：支持市面上主流的事务型数据库之间的增量数据同步，能够将某一种数据源的增量数据近乎实时的同步到指定的数据库中，在数据库部署主备架构及异地灾备架构以及不同数据库间的数据迁移场景中发挥着巨大的作用

Gbase RTSync的主要优势如下表
准实时性 通过流模式实现源数据库到目标数据库的秒级同步
灵活部署 组件间可以独立部署到不同机器上，充分利用机器资源；同时支持部署部分组件用于将增量数据写入kafka，提供给第三方使用
断点续传 出现网络异常，宕机等情况导致服务退出后，重启服务能够接着之前同步的点继续同步数据，保证数据不丢失。
双向同步 双活集群中两边都会有写入数据的 *** 作，RTSync能够很好的支持这种需要双向同步的场景，且不会导致数据的环形同步
高可用 支持部署多套搭建高可用服务
灵活同步 支持自定义的库级，表级，列级别的同步；支持按组配置同步任务

Gbase RTSync 【灵活同步-按组设置同步任务】是比较高级且实用的同步方式，我们以实例的方式帮大家讲解下
1.应用场景
设想我们有这样一种简化场景，数据库包含主备节点，主节点对外提供写服务，备节点对外提供读服务，主备间需要做数据同步。同时主节点的数据变化还要同步到历史库中，供其他应用数据分析使用。
我们能想到的一种部署方式是部署两套RTSync分别负责主备间同步，主到历史库间同步。这种方式优点是部署简单，但缺点也显而易见，主要有： 1）因为增量数据需要解析逻辑日志，多个服务同时读取会造成数据库io压力，影响数据库性能
2）需要单独维护两套RTSync服务，如果两套服务因网络等原因导致同步延迟不一致会造成运维繁琐
针对这种场景我们有更好的部署方式来解决这些问题，即按组分源配置它是RTSync同步中的一个高级特性，数据流转如下：

所谓按组分源，就是允许我们在任务中配置多个同步任务（配置中体现为多个source-target对），其中每个source间配置为同一个数据库实例的不同或者相同表，target端为目标端数据库的配置。我们将这多个同步任务标记为同一个group下，这样RTSync服务启动后会将组内同步任务的元数据合并处理，然后交由miner组件挖掘数据，参考上图黄橘黄色背景Miner组件。同时RTSync内部会有分发组件负责将挖掘的数据按配置的同步任务分发到不同的任务节点中，确保一份数据会被多个任务节点处理，最终同步到目标端，参考上图橘黄色背景数据分发组件。

2.部署环境
提供三台服务器：192.168.88.135,192.168.88.136,192.168.88.137
各服务组件分别部署如下：
Zookeeper 192.168.88.135192.168.88.136192.168.88.137 /opt/zookeeper-3.4.9
Kafka 192.168.88.135192.168.88.136192.168.88.137 /opt/kafka_2.11-0.10.2.1
Gbase8s主节点数据库 192.168.88.135 /opt/gbase8s
Gbase8s备节点数据库 192.168.88.136 /opt/gbase8s
Gbase8s历史数据库 192.168.88.137 /opt/gbase8s
RTSync 192.168.88.135 /opt/RTSync

3.服务配置
1）修改/opt/RTSync/config_kafka_8tto8t.properties
内容如下：
kafka.producer.paramers=request.timeout.ms=600000;metadata.fetch.timeout.ms=60000;linger.ms=10;
kafka.send.issuccess=true
kafka.consumer.paramers=session.timeout.ms=10000;request.timeout.ms=60000;enable.auto.commit=false;
zookeeper.session.timeout.ms=8000
kafka.resend.max.retries=3
topic.replication.num=1
send.data.max.size=30485760
kafka.batch.commit.time=300
fetch.message.max.bytes=104857600
group.id=test08061
zookeeper.sync.time.ms=4000
bootstrap.servers=192.168.88.135:9092,192.168.88.136:9092,192.168.88.137:9092
auto.commit.offset.enable=false
kafka.acks=all
kafka.batch.commit.count=1000
topic.enable.auto.create=true
topic.name=bht1120,sstest71,sstest81
auto.commit.interval.ms=5000
zookeeper.connect=192.168.88.135:2181,192.168.88.136:2181

2）修改/opt/RTSync/config_task.xml

4.服务启动
执行sh /opt/RTSync/RTSyncManagerServer.sh start命令
5.总结
从配置文件看到按组分源与普通的增量同步设置的唯一区别就是通过在source-target节点增加属性groupName,将同属于同一实例数据库的需要分发到不同目标数据库的同步任务设置成相同的groupName即可。用户使用该功能非常方便，但这确是Gbase RTSync在整体架构设计上的考量，在设计之初在架构上便支持了这种处理，该功能重点在于元数据合并处理后进行数据挖掘及后续数据的复制分发。
按组分源进行同步的特性很好解决了增量数据在源端重复挖掘的问题，特别是需要将同一实例的相同库或者不同库间的数据发到不同目标端的时候，极大降低了数据库io的压力，同时将之前需要独立运维的同步任务通过组的设置合并到一个组内处理，所有任务公用一套断点续传管理接口，提高了运维的可 *** 作性。