欧美专区在线观看,91成人小电影,美女性日日爱,中日韩黄色视频,欧美性爱男人的天堂,久久成人三级片影院,91在线无码精品秘入口九色1,俺不色成人社区

TiCDC 是一款通過(guò)拉取 TiKV 變更日志實(shí)現(xiàn)的 TiDB 增量數(shù)據(jù)同步工具，具有將數(shù)據(jù)還原到與上游任意 TSO 一致?tīng)顟B(tài)的能力，同時(shí)提供開(kāi)放數(shù)據(jù)協(xié)議 (TiCDC Open Protocol)，支持其他系統(tǒng)訂閱數(shù)據(jù)變更。

TiCDC業(yè)務(wù)使用場(chǎng)景描述

（1）增量數(shù)據(jù)抽取需求

數(shù)倉(cāng)ETL每天凌晨基于table(create_date or update_date)增量或者全量的數(shù)據(jù)抽?。?/p>

目前離線報(bào)表業(yè)務(wù)為了凌晨產(chǎn)出報(bào)表，數(shù)倉(cāng)團(tuán)隊(duì)凌晨需要從我們核心的物料TiDB集群(70+節(jié)點(diǎn))中抽取維度基本信息數(shù)據(jù)，這些多張維度的基本信息表都是大表(200億/表，5T+/表)，每天凌晨的數(shù)倉(cāng)抽取任務(wù)會(huì)對(duì)全實(shí)例(20T)做全量抽取。導(dǎo)致凌晨CPU跑滿/內(nèi)存oom/網(wǎng)卡跑滿等各種負(fù)載問(wèn)題，并且平均1～2個(gè)月出現(xiàn)數(shù)倉(cāng)抽取失敗，從而影響離線報(bào)表的定時(shí)產(chǎn)出，導(dǎo)致廣告主不能及時(shí)看到昨天廣告的消費(fèi)情況，最嚴(yán)重的后果就是由此產(chǎn)生的廣告停止投放，影響廣告收入；另外凌晨除了數(shù)倉(cāng)還有其他的計(jì)算任務(wù)存在，這種全量的抽取也會(huì)對(duì)其他正常凌晨任務(wù)的執(zhí)行造成影響；凌晨的各種報(bào)警，我們DBA來(lái)說(shuō)也苦不堪言。所以使用TiCDC寫入kafka這種增量數(shù)倉(cāng)需求是我們緊要的需求。

（2）同城雙集群熱備

目前我們的核心tidb都放在同一個(gè)機(jī)房。如果機(jī)房孤島或者其他災(zāi)害問(wèn)題。業(yè)務(wù)無(wú)法及時(shí)恢復(fù)。TiDB集群的同城雙中心需求是重要的需求。

我們想利用TiCDC做同城雙集群數(shù)據(jù)同步，一是可以將部分不需要太實(shí)時(shí)的讀取流量切到備用集群，來(lái)緩解主TIDB集群的讀取壓力。二是一旦核心機(jī)房有問(wèn)題，備用集群就可以立即接管服務(wù)。

（3）流處理需求

之前業(yè)務(wù)就是用maxwell/canal等工具將MySQL的變更binlog解析處理后寫入kafka, 供實(shí)時(shí)JOB消費(fèi)或者映射成flink table 作為flink sql的維表join?，F(xiàn)在隨著MySQL遷移到TiDB，我們也需要TiCDC高效/穩(wěn)定的支持該需求，否則業(yè)務(wù)無(wú)法完全的遷移到TiDB（只能長(zhǎng)期保持MySQL->DM->TiDB）這種架構(gòu)，無(wú)法實(shí)現(xiàn)真正的TiDB替代MySQL，另外就是DM還需要處理上游分庫(kù)分表DDL的兼容和同步中斷的處理，所以TiCDC在流處理中扮演重要的角色。

ticdc架構(gòu)

從上圖的架構(gòu)來(lái)看可以細(xì)分4個(gè)大模塊分別為：TiKV cluster、PD、Ticdc Cluseter、Sink下游組件。

下面來(lái)詳細(xì)介紹下各個(gè)組件：

1、最核心的TiCDC cluster

可以看出集群里有多個(gè)ticdc進(jìn)程，專業(yè)名詞可以叫做capture，capture有幾大作用：

puller 負(fù)責(zé)拉取TiKV的change log，對(duì)拉取的change log排序（基于單表維度）。
基于processor這個(gè)內(nèi)部邏輯線程，每個(gè)processot負(fù)責(zé)同步一張或者多張表的數(shù)據(jù)變更，一個(gè)capture節(jié)點(diǎn)可以運(yùn)行多個(gè)processor線程，向下游輸出。
高可用：多個(gè)capture組成一個(gè)ticdc集群，并且capture有不同的角色，分為owner/非owner角色，owner節(jié)點(diǎn)負(fù)責(zé)集群的調(diào)度，并且所有的capture都會(huì)注冊(cè)到PD，一旦ticdc onwer異常，會(huì)觸發(fā)選舉新owner，并且owner會(huì)在其他processor節(jié)點(diǎn)異常時(shí)，將processor管理的同步任務(wù)調(diào)度到其他capture節(jié)點(diǎn)。
可以使用tiup來(lái)查看各個(gè)capture進(jìn)程的狀態(tài)tiup ctl cdc capture list --pd=http://xxxxx:2379
同步任務(wù)changefeed。一個(gè)同步任務(wù)可以同步一個(gè)tidb實(shí)例，也可以設(shè)定過(guò)濾規(guī)則，只同步某些DB or Table。創(chuàng)建同步任務(wù)：tiup ctl:v4.0.14 cdc changefeed create --pd=http://pd-ip:2379 --sink-uri="mysql://User:password@vip:4000/" --changefeed-id="sync-name" --start-ts=0 --config=./ticdc.yaml查看同步任務(wù)： tiup ctl:v4.0.14 cdc changefeed list --pd=http://pd-ip:2379

詳情可以下圖的抽取邏輯

2、TiKV Cluster

用戶寫入的鍵值對(duì)會(huì)先寫入磁盤上的 WAL (Write Ahead Log)，又可以理解為 KV 變更日志（KV Change Logs）。一旦同步任務(wù)創(chuàng)建，TiCDC集群就會(huì)拉取這些 row changed events。

3、PD cluster

TIDB集群的大腦，除了分配全局TSO、管理集群元數(shù)據(jù)和調(diào)度外，在TiCDC層面：負(fù)責(zé)存儲(chǔ)changefeed的配置和狀態(tài)、capture 節(jié)點(diǎn)元信息、owner 選舉信息以及 processor 的同步狀態(tài)等。

4、Sink組件

TiCDC的下游

MySQL 協(xié)議兼容的數(shù)據(jù)庫(kù)（MySQL、TiDB）
Kafka/Pulsar，然后Flink等第三方流處理組件訂閱數(shù)據(jù)變更來(lái)使用。
增量備份，比如存放在S3這種分布式文件存儲(chǔ)系統(tǒng)上。

早期版本的問(wèn)題

之前存在的問(wèn)題（大部分已經(jīng)修復(fù)）：

TiCDC正常同步進(jìn)行中，上游TiDB突增大寫入量的情況下經(jīng)常OOM，穩(wěn)定性不足
當(dāng)TiCDC因?yàn)槟承┰蛲街袛鄷r(shí)，并且中斷期間上游TiDB寫入了大量數(shù)據(jù)，重新啟動(dòng)同步導(dǎo)致TiCDC出現(xiàn) OOM 問(wèn)題
ticdc的下游是tidb的情況下，上游tidb集群出現(xiàn)大量對(duì)同一行記錄進(jìn)行更新時(shí)，下游tidb出現(xiàn)寫寫沖突導(dǎo)致ticdc同步停止（官方已經(jīng)對(duì)這個(gè)問(wèn)題有解決方案）
sort-dir路徑問(wèn)題：之前版本的sort目錄是默認(rèn)跟deploy放同一目錄，如果按照默認(rèn)deploy是/home/tidb/deploy的話，sort目錄就是默認(rèn)使用系統(tǒng)盤(一般空間較小)，當(dāng)遇到突增寫入或者又較大多的change log需要同步時(shí)，可能會(huì)把系統(tǒng)盤寫滿，另外ticdc同步也會(huì)因?yàn)閟ort目錄寫滿而中斷。目前sort目錄已經(jīng)修改成TiCDC的data目錄
早期版本的TiCDC在拉取change log時(shí)并發(fā)度沒(méi)有上限，導(dǎo)致TiKV節(jié)點(diǎn)的網(wǎng)卡、硬盤IO、CPU等飆升，影響了集群正常業(yè)務(wù)的運(yùn)行。
在執(zhí)行大的DDL操作時(shí)(比如對(duì)億級(jí)別的表添加索引)，TiCDC同步會(huì)等待DDL執(zhí)行完畢后才繼續(xù)同步change log。(4.0.14+版本解決)

最佳實(shí)踐：

強(qiáng)烈建議使用4.0.14/5.1.1最新版本的ticdc，高版本修復(fù)了不少bug。
及時(shí)觀察ticdc相關(guān)的監(jiān)控。ticdc有專門的監(jiān)控dashboard，從里面可以看出抽取changelog的速度，寫下游Sink的情況，對(duì)tikv集群的影響等等，官網(wǎng)有對(duì)各個(gè)監(jiān)控項(xiàng)的詳細(xì)說(shuō)明，如下。https://docs.pingcap.com/zh/tidb/stable/monitor-ticdc
如果數(shù)據(jù)寫入kafka，除了提供默認(rèn)的開(kāi)放數(shù)據(jù)協(xié)議 (TiCDC Open Protocol)外，還有多種 kafka 消息協(xié)議可選擇比如canal、canal-json、avro、maxwell等方式，兼容之前MySQL的cdc，可以無(wú)縫遷移。
在上游TiDB寫入量比較大時(shí)，拆分多個(gè)changefeed進(jìn)行同步，可以從STATEMENTSSUMMARYHISTORY系統(tǒng)表來(lái)看table寫入分布，按照寫入表拆分成多個(gè)changefeed，SQL如下：select digest,DIGEST_TEXT,TABLE_NAMES,sum(EXEC_COUNT),min(SUMMARY_BEGIN_TIME),max(SUMMARY_END_TIME) from STATEMENTS_SUMMARY_HISTORY where stmt_type='insert' and schema_name='ad_monitor' group by digest order by sum(exec_count) desc limit 20;
PS：dashboard->SQL語(yǔ)句分析，過(guò)濾insert找出table寫入情況。
kafka的partition-num參數(shù)要設(shè)定為1，因?yàn)榛诒淼耐诫m然是sort后執(zhí)行，如果輸出到多個(gè)kafka partition，kafka保證每個(gè)partition是有序的，但是消費(fèi)者從多個(gè)kafka partition拿數(shù)據(jù)向下游應(yīng)用時(shí)可能事務(wù)順序會(huì)被打亂，導(dǎo)致數(shù)據(jù)不一致的情況產(chǎn)生。
為了防止因?yàn)?sort 信息過(guò)多導(dǎo)致 ticdc 節(jié)點(diǎn)的 gorouting 異常，需要 ticdc 配置 per-table-memory-quota 到 6M 來(lái)緩解穩(wěn)定，注意這個(gè)參數(shù)的values是數(shù)值類型，按照下面的方式修改：
```
tiup edit-config tidb-cluster-name  #在全局配置的cdc配置加入下面
  cdc:
    per-table-memory-quota: 6291456
```
TiKV網(wǎng)絡(luò)限速，避免TiCDC的拉取對(duì)tikv集群造成影響，比如你的tikv都是千兆網(wǎng)卡，正常的集群就已經(jīng)使用到30～50M，可以將ticdc的拉取限速我20M（因?yàn)閾?dān)心ticdc的拉取把千兆網(wǎng)卡跑滿影響集群正常業(yè)務(wù)），修改方式如下：
```
tiup edit-config tidb-cluster-name  #在全局配置的tikv配置加入下面
tikv:
    cdc.incremental-scan-speed-limit: 20MB
```
TiCDC 的 gc-ttl：Ticdc默認(rèn)可以hold 24小時(shí)的changlog，超過(guò)24自動(dòng)釋放gc。所以中斷24小時(shí)以上的同步任務(wù)重啟會(huì)報(bào)錯(cuò)，啟動(dòng) TiCDC server 時(shí)可以通過(guò) gc-ttl 指定 GC safepoint 的 TTL。
雖然gc-ttl可以為中斷的同步hold 24小時(shí)的KV數(shù)據(jù)變更，但是從另外一個(gè)方面來(lái)看，累積多過(guò)的MVCC版本，肯定會(huì)對(duì)查詢?cè)斐捎绊?，需要根?jù)業(yè)務(wù)評(píng)估影響，如果需要?jiǎng)h除同步任務(wù)可以用下面的命令：
```
tiup ctl:v4.0.14 cdc changefeed remove --pd=http://pd-ip:2379 --changefeed-id=TICDC-XXX
```
使用ticdc增量拉取時(shí)，提前調(diào)整gc lifetime。比如要用cdc做跨機(jī)房數(shù)據(jù)同步，比如：用br恢復(fù)今天凌晨備份，記得提前調(diào)整gc lifetime時(shí)間，避免BR恢復(fù)完數(shù)據(jù)創(chuàng)建changefeed的時(shí)候發(fā)現(xiàn)change log已經(jīng)被gc了。
TiCDC 對(duì)大事務(wù)（大小超過(guò) 5 GB）提供部分支持，所以對(duì)于上游TIDB集群最大支持10G的事務(wù)來(lái)說(shuō)，大事務(wù)可能觸發(fā)TiCDC的oom。
出現(xiàn)同步中斷時(shí)，可以先使用以下命令查看同步報(bào)錯(cuò)的原因，另外就是從TiCDC的日志里面查看報(bào)錯(cuò)的具體詳情。
```
tiup ctl:v4.0.14 cdc changefeed query -s --pd=http://pd-ip:2379 --changefeed-id=TICDC-XXX
```

總結(jié)：

其實(shí)我想說(shuō)的是：目前ticdc在大部分場(chǎng)景下是可用的。

這里要提到一件事情，就是關(guān)于ticdc穩(wěn)定性和可用性立項(xiàng)：TiCDC在早期版本確定是出現(xiàn)過(guò)各種OOM以及對(duì)Tikv集群負(fù)載影響等問(wèn)題，從今年年初360就提出了本文開(kāi)頭的3個(gè)應(yīng)用場(chǎng)景，并且跟PingCAP的TiCDC研發(fā)團(tuán)隊(duì)一起合作立項(xiàng)，中間在線和線下溝通了10多次，基于360的高寫入環(huán)境來(lái)驗(yàn)證TiCDC的穩(wěn)定和可用性，直到現(xiàn)在TiCDC終于可以在各個(gè)場(chǎng)景下穩(wěn)定運(yùn)行，希望有類似需求的可以嘗試使用起來(lái)，有問(wèn)題可以及時(shí)跟官方溝通反饋，目的就是讓TiCDC這個(gè)同步工具更加高效和穩(wěn)定運(yùn)行。

TiCDC 解析 | TiCDC 應(yīng)用場(chǎng)景解析