国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

DM同步主鍵沖突原因及排查恢復

IT那活兒 / 3498人閱讀
DM同步主鍵沖突原因及排查恢復

點擊上方“IT那活兒”,關注后了解更多內容,不管IT什么活兒,干就完了!!!



報錯現象

主鍵沖突:


報錯分析



情況1:上游數據存在沖突的情況,例如上游兩套Mysql庫,分別都有store_bj表,通過DM將上游兩張表的數據匯總到下游一張表中,在同步的過程中上游兩張表都有id=12的主鍵的數據,上游mysql中均插入成功,但在同步Tidb進行中出現主鍵沖突。
-- 解決方法:從上游數據入手,避免重復主鍵數據,出現主鍵沖突的報錯之后,同步Task任務將被終止,通過重啟Task任務可以恢復同步狀態。
在任務終止期間,如果上游Mysql繼續有相同主鍵數據更新的操作會在重啟Task任務后再次出現主鍵沖突報錯,需要再次進行Task任務的重啟。
建議對于報錯的主鍵沖突情況,需要業務開發人員對報錯的表操作以及數據進行排查,會存在主鍵沖突的數據未同步成功的情況。
-- 測試報錯及恢復案例:
1)store_bj表結構:
create table store_bj (id int primary key,name varchar(20));
mysql1:

mysql> insert into store_bj values (12,store_bj_11);
Query OK, 1 row affected (0.01 sec)

mysql2:

mysql> insert into store_bj values (12,store_bj_12)
;
Query OK, 1 row affected (0.01 sec)
2)在上游兩套Mysql中,均正常插入id=12的數據,但在Tidb中只有成功插入其中一條數據插入,查詢Task狀態報錯:
[tidb@tidb1 ~]$ tiup dmctl --master-addr ***.**.***.134:8261 query-status two_tidb_slave
………
"subTaskStatus": [
{
"name": "two_tidb_slave",
"stage": "Paused",
"unit": "Sync",
"result": {
"isCanceled": false,
"errors": [
{
"ErrCode": 100*6,
"ErrClass": "database",
"ErrScope": "not-set",
"ErrLevel": "high",
"Message": "startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.000002, 12368), gtid-set: ]: execute statement failed: commit",
                               "RawCause": "Error 1062: Duplicate entry 12 for key PRIMARY",
"Workaround": ""
}
],
"detail": null
…………
3)排查DM日志,可以找到對應的主鍵沖突的報錯以及對應表的操作:
[tidb@tidb1 ~]$ cat /home/tidb/dm/deploy/dm-worker-8262/log/dm-worker.log
………
[2021/12/03 16:54:39.773 +08:00] [INFO] [syncer.go:1902] ["meet heartbeat event and then flush jobs"] [task=two_tidb_slave] [unit="binlog replication"]
[2021/12/03 16:54:39.773 +08:00] [INFO] [syncer.go:3016] ["
flush all jobs"] [task=two_tidb_slave] [unit="binlog replication"] ["global checkpoint"="position: (mysql-bin.000002, 12123), gtid-set: (flushed position: (mysql-bin.000002, 12123), gtid-set: )"]
[2021/12/03 16:54:39.773 +08:00] [INFO] [syncer.go:1119] ["
flushed checkpoint"] [task=two_tidb_slave] [unit="binlog replication"] [checkpoint="position: (mysql-bin.000002, 12123), gtid-set: (flushed position: (mysql-bin.000002, 12123), gtid-set: )"]
[2021/12/03 16:54:39.773 +08:00] [INFO] [syncer.go:1127] ["
after last flushing checkpoint, DM has ignored row changes by expression filter"] [task=two_tidb_slave] [unit="binlog replication"] ["number of filtered insert"=0] ["number of filtered update"=0] ["number of filtered delete"=0]

[2021/12/03 16:54:41.794 +08:00] [ERROR] [db.go:201] ["
execute statements failed after retry"] [task=two_tidb_slave] [unit="binlog replication"] [queries="[INSERT INTO `store`.`store_bj` (`id`,`name`) VALUES (?,?)]"] [arguments="[[12 store_bj_12]]"] [error="[code=10006:class=database:scope=not-set:level=high], Message: execute statement failed: commit, RawCause: Error 1062: Duplicate entry 12 for key PRIMARY"]
[2021/12/03 16:54:41.794 +08:00] [INFO] [syncer.go:2854] ["
print status routine exits"] [task=two_tidb_slave] [unit="binlog replication"] [error="context canceled"]
[2021/12/03 16:54:41.794 +08:00] [INFO] [syncer.go:1696] ["
binlog replication main routine quit(context canceled)!"] [task=two_tidb_slave] [unit="binlog replication"] ["last location"="position: (mysql-bin.000002, 12399), gtid-set: "]
[2021/12/03 16:54:41.828 +08:00] [INFO] [syncer.go:1602] ["
flush checkpoints when exit task"] [task=two_tidb_slave] [unit="binlog replication"]
[2021/12/03 16:54:41.837 +08:00] [INFO] [checkpoint.go:694] ["
rollback checkpoint"] [task=two_tidb_slave] [unit="binlog replication"] [component="remote checkpoint"] [schema=store] [table=store_shenzhen] [from="position: (mysql-bin.000002, 10712), gtid-set: "] [to="position: (mysql-bin.000002, 10712), gtid-set: "]
[2021/12/03 16:54:41.837 +08:00] [WARN] [checkpoint.go:697] ["
failed to drop table from schema tracker"] [task=two_tidb_slave] [unit="binlog replication"] [component="remote checkpoint"] [schema=store] [table=store_shenzhen] [error="[schema:1146]Table store.store_shenzhen doesnt exist"]
[2021/12/03 16:54:41.844 +08:00] [WARN] [syncer.go:681] ["something wrong with rollback global checkpoint"] [task=two_tidb_slave] [unit="binlog replication"] ["previous position"="position: (mysql-bin.000002, 12399), gtid-set: "] ["current position"="position: (mysql-bin.000002, 12123), gtid-set: "]
[2021/12/03 16:54:41.844 +08:00] [INFO] [subtask.go:292] ["unit process returned"] [subtask=two_tidb_slave] [unit=Sync] [stage=Paused] [status="{"totalEvents":1,"syncerBinlog":"(mysql-bin.000002, 12123)","binlogType":"remote"}"]
[2021/12/03 16:54:41.844 +08:00] [ERROR] [subtask.go:311] ["unit process error"] [subtask=two_tidb_slave] [unit=Sync] ["error information"="{"ErrCode":10006,"ErrClass":"database","ErrScope":"not-set","ErrLevel":"high","Message":"startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.000002, 12368), gtid-set: ]: execute statement failed: commit","RawCause":"Error 1062: Duplicate entry
12 for key PRIMARY"}"]
[2021/12/03 16:54:45.961 +08:00] [WARN] [task_checker.go:390] ["task can
t auto resume"] [component="task checker"] [task=two_tidb_slave]
…………
對于報錯的同步,建議業務開發人員對DM失敗的操作進行排查,對同步的表上游源端和下游成功插入的數據是否有效,未同步成功的數據是否需要進行主鍵的調整,均需要進行排查。當調整完成后,再次重啟Task任務,并檢查同步狀態。
4)再次重啟task任務:
[tidb@tidb1 ~]$ tiup dmctl -master-addr ***.**.***.134:8261 stop-task task3637.yaml
[tidb@tidb1 ~]$ tiup dmctl -master-addr ***.**.***.134:8261 start-task task3637.yaml
5)檢查同步狀態:
[tidb@tidb1 ~]$ tiup dmctl --master-addr ***.**.***.134:8261 query-status two_tidb_slave
情況2:
全量導入數據之前,該主鍵數據已經存在于下游數據庫中。
判斷依據:主鍵寫入數據庫的時間即(MVCC時間)早于 load 的時間(min(create_time)),查詢時間點可以參考情況3。
解決方法:如僅出現一次主鍵沖突的情況,可以將下游主鍵數據刪掉,恢復同步任務即可;如多次出現主鍵沖突,建議刪除下游數據以及為位點信息后,重新進行全量數據的導入。
情況3:
由于位點信息被清理導致 sql 文件被重復導入(未重現,需要根據情況進行判斷,BUG情況需要提交AskTUG專家進行分析)。
判斷依據:根據以下信息可了解到在全量遷移階段開始后,因某種原因導致 sql 文件位點被刪除,sql 文件被重復導入,導致主鍵沖突。
同步任務全量遷移階段開始時間為:2020-03-17 11:57:36
該數據插入數據庫的時間為:2020-03-17 11:57:37
該文件 test.sbtest5.000000005.sql 記錄的創建時間以及更新時間都是 2020-03-17 12:20:29
從 dm-worker.log 中 grep test.sbtest5.000000005.sql 發現同步任務開始后,有兩次導入該文件。
解決方法:建議清空下游數據,重新導入。
根據沖突主鍵的 MVCC 版本以及 dm_meta 中的位點信息具體分析:
1)利用 tidb API 查看主鍵沖突的行的 mvcc 版本,以此來確認該行數據插入數據庫的時間
注意:該操作需要保留現場,該操作是從下游 TiDB 中查詢。
#主鍵為 int 類型,handle 即 int 類型主鍵。
curl http://{TiDBIP}:1**80/mvcc/key/{db}/{table}/{handle}
#主鍵為非整數類型。
select _tidb_rowid from xxx where trade_no=‘190606LI8OODRTZA5XX1’;
curl http://{TiDBIP}:1**80/mvcc/key/{db}/{table}/{_tidb_rowid}
根據上述命令得到如下結果:
下一步操作為根據 pd-ctl 將 commit_ts 轉化為對應的時間,即解析 tso。
注:也可以在 TiDB 中調用 select TIDB_PARSE_TSO(415345529804292097); 獲取對應時間。
2)在 dm_meta 查詢 min(create_time) 來獲得 load 第一個文件時的時間,可以認為是 全量遷移階段的開始時間。
3)在 dm_meta 中查看 xxx_loadder_checkpoint 表查看該文件 test.sbtest5.000000005.sql 的詳細信息!
4)從 dm-worker 中 grep 查看該主鍵所在的 .sql 文件出現的時間以及次數
沖突的主鍵(1292790)所在的文件為 test.sbtest5.000000005.sql
grep test.sbtest5.000000005.sql dm-worker.log



本文作者:陳聰

本文來源:IT那活兒(上海新炬王翦團隊)

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/129629.html

相關文章

  • TiDB Ecosystem Tools 原理解讀系列(三)TiDB-DM 架構設計與實現原理

    摘要:合庫合表數據同步在使用支撐大量數據時,經常會選擇使用分庫分表的方案。但當將數據同步到后,通常希望邏輯上進行合庫合表。為支持合庫合表的數據同步,主要實現了以下的一些功能。 作者:張學程 簡介 TiDB-DM(Data Migration)是用于將數據從 MySQL/MariaDB 遷移到 TiDB 的工具。該工具既支持以全量備份文件的方式將 MySQL/MariaDB 的數據導入到 Ti...

    legendaryedu 評論0 收藏0
  • DM 源碼閱讀系列文章(七)定制化數據同步功能的實現

    摘要:作者王相本文為源碼閱讀系列文章的第七篇,在上篇文章中我們介紹了的實現,主要包括目錄結構定義數據的處理流程主從切換支持的讀取等邏輯。本篇文章我們將會對的定制化數據同步功能進行詳細的講解。 作者:王相 本文為 DM 源碼閱讀系列文章的第七篇,在 上篇文章 中我們介紹了 relay log 的實現,主要包括 relay log 目錄結構定義、relay log 數據的處理流程、主從切換支持、...

    leo108 評論0 收藏0

發表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<