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

各服務元件分別部署如下：

Z ookeeper	192.168.88.135192.168.88.136192.168.88.137	/opt/zookeeper-3.4.9
K afka	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

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<server dataFormatType="PUREDATA" dataRecoveryMode="file"

id="zbbserver210" isHighAvailable="false" mqType="kafka" queueName="8tto8tMQ"

syncMode="increment">

<manager heartbeatPort="9000" heartbeatTimeOut="500" httpPort="8087"

ip="192.168.88.135" isTableHotPatch="true" isValidateMetadata="false"

port="9432" useErrorDataRecovery="false" />

<source dataFormatParallel="10" dbObjToUpperCase="true"

ip="192.168.88.135" isConvertSingleQuote="true" monitorInterval="100"

openMonitor="true" password="******"

path="/opt/RTSync/"

queuePollTimeOut="20" queueSize="100" readParseAdapter="adapter"

rpcPort="9191" user="root" />

<target errorishandle="false" ip="192.168.88.135"

monitorInterval="100" password="******"

path="/opt/RTSync" rpcPort="9192"

sendDataBySocket="false" useHighVersionConsumer="true" user="root"

writeDataAdapter="adapter" />

<source-target groupName="8sgroup" id="idno0">

<db>

<sourcedb allowPrimaryKeyNull="true" catalog="dbmaster"

charset="UTF8"

columnTypeFormat="time=hh:mm:ss.SSSSSSS;date=yyyy-MM-dd;datetime=yyyy-MM-dd HH:mm:ss;smalldatetime=yyyy-MM-dd HH:mm:ss.SSSSSS;datetime2=yyyy-MM-dd HH:mm:ss.SSSSSS"

delayTimeThreshold="0" driver="com.gbasedbt.jdbc.Driver" dyntal="true"

fetchSize="100" isGetDBspace="true" isMineWholeTransaction="fasle"

isOverDelayTimeThresholdExit="false" isParallelForMysql="true"

isUseMinerCache="true" longTxCheckIntervalTime="10"

longTxMaxWaitTime="60" maxRecordsPerRead="200" maxSizeOfPerRecord="1024"

mysqlSlaveId="00" operationType="dml" packetMaxRecord="2"

parallel="4" password="******" startLSN="0" timeOut="2"

timestampWithFraction="true" transMaxCount="10000" type="MYSQL"

url="jdbc:gbasedbt-sqli://192.168.88.135:16351/syscdcv1:gbasedbtserver=ol_gbasedbt1210;IFX_SOC_TIMEOUT=180000;IFX_LOCK_MODE_WAIT=100;"

useAddFile="false" user="gbasedbt" />

<targetdb catalog="dbslave" charset="UTF8" commitSize="50"

driver="com.gbasedbt.jdbc.Driver" isInitMetadata="true"

parallel="8" password="******" queueSize="2000" timeOut="10"

type="GBASE8S"

url="jdbc:gbasedbt-sqli://192.168.88.136:16351/sysmaster:gbasedbtserver=ol_gbasedbt1210;IFX_SOC_TIMEOUT=180000;IFX_LOCK_MODE_WAIT=100;"

user="gbasedbt" />

</db>

</source-target>

<source-target groupName="8sgroup" id="idno1">

<db>

<sourcedb allowPrimaryKeyNull="true" catalog="dbmaster"

charset="UTF8"

columnTypeFormat="time=hh:mm:ss.SSSSSSS;date=yyyy-MM-dd;datetime=yyyy-MM-dd HH:mm:ss;smalldatetime=yyyy-MM-dd HH:mm:ss.SSSSSS;datetime2=yyyy-MM-dd HH:mm:ss.SSSSSS"

delayTimeThreshold="0" driver="com.gbasedbt.jdbc.Driver" dyntal="true"

fetchSize="100" isGetDBspace="true" isMineWholeTransaction="fasle"

isOverDelayTimeThresholdExit="false" isParallelForMysql="true"

isUseMinerCache="true" longTxCheckIntervalTime="10"

longTxMaxWaitTime="60" maxRecordsPerRead="200" maxSizeOfPerRecord="1024"

mysqlSlaveId="00" operationType="dml" packetMaxRecord="2"

parallel="4" password="******" startLSN="0" timeOut="2"

timestampWithFraction="true" transMaxCount="10000" type="MYSQL"

url="jdbc:gbasedbt-sqli://192.168.88.135:16351/syscdcv1:gbasedbtserver=ol_gbasedbt1210;IFX_SOC_TIMEOUT=180000;IFX_LOCK_MODE_WAIT=100;"

useAddFile="false" user="gbasedbt" />

<targetdb catalog="dbhistory" charset="UTF8" commitSize="50"

driver="com.gbasedbt.jdbc.Driver" isInitMetadata="true"

parallel="8" password="******" queueSize="2000" timeOut="10"

type="GBASE8S"

url="jdbc:gbasedbt-sqli://192.168.88.137:16351/sysmaster:gbasedbtserver=ol_gbasedbt1210;IFX_SOC_TIMEOUT=180000;IFX_LOCK_MODE_WAIT=100;"

user="gbasedbt" />

</db>

</source-target>

</mappings>

</server>

</servers>

4. 服務啟動

執行sh /opt/RTSync/RTSyncManagerServer.sh start命令

5. 總結

從配置檔案看到按組分源與普通的增量同步設定的唯一區別就是通過在source-target 節點增加屬性 groupName, 將同屬於同一例項資料庫的需要分發到不同目標資料庫的同步任務設定成相同的 groupName 即可。使用者使用該功能非常方便，但這確是 GBase RTSync 在整體架構設計上的考量，在設計之初在架構上便支援了這種處理，該功能重點在於後設資料合併處理後進行資料探勘及後續資料的複製分發。

按組分源進行同步的特性很好解決了增量資料在源端重複挖掘的問題，特別是需要將同一例項的相同庫或者不同庫間的資料發到不同目標端的時候，極大降低了資料庫io 的壓力，同時將之前需要獨立運維的同步任務通過組的設定合併到一個組內處理，所有任務公用一套斷點續傳管理介面，提高了運維的可操作性。

GBase RTSync實時同步之設定按組同步

相關文章