TIDB 4.0.11 支持从mysql 5.7 MGR同步数据吗??

这个测试通过,执行没问题,感谢:+1::+1::+1::+1:, 数据源切换后,采用gtid模式数据正常同步。这种情况是我一开始就启用了GTID模式同步数据的。

现在还剩下下面这个问题
1 一开始采用的是默认方式binlog file+ pos模式同步
2 后来才启用gtid模式同步

发现问题:
后来启用GTID模式同步后,数据同步异常,发现同步了重复的数据,没有从断点继续同步, 这个有没有好的解决办法。
需要我这边提供什么信息???

这个拿下你这边 dm-worker 的日志,以及 dm-master leader 的日志,麻烦标记下执行时间,多谢。

这个我还需要重新模拟下,要等一会。

顺便问下,这个从binlogfile+pos 转换到gtid模式同步,理论上是支持的吗??

1 查看现在的同步位置

2 停止同步任务
3 停止数据源
4 修改worker配置,启用gtid
5 启动同步任务,报错

dm-master.log (3.3 MB) dm-worker.log (2.6 MB)

                    "syncerBinlog": "(3306-binlog.000004, 1750)",
                    "syncerBinlogGtid": "b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-6",

这个应该是从开始的binlog同步了

好的。感谢反馈,我们查一下。

@Hacker_gYl9RI8v 你好,是否可以再提供下 enable-gtid=false 时,dm_meta 中 xxx_syncer_checkpoint 的信息。我这边尝试复现你的问题时,针对第一点,enable-gtid=false 时,query-status 可以正常查到 syncerBinlogGtid 信息

mysql> select * from mgr_syncer_checkpoint\G;
*************************** 1. row ***************************
id: mysql-replica-03
cp_schema:
cp_table:
binlog_name: 3306-binlog.000004
binlog_pos: 1750
binlog_gtid: b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-6
exit_safe_binlog_name:
exit_safe_binlog_pos: 0
exit_safe_binlog_gtid:
table_info: null
is_global: 1
create_time: 2021-04-07 10:37:45
update_time: 2021-04-07 10:43:25
*************************** 2. row ***************************
id: mysql-replica-03
cp_schema: testdb
cp_table: t1
binlog_name: 3306-binlog.000004
binlog_pos: 1750
binlog_gtid: b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-6
exit_safe_binlog_name:
exit_safe_binlog_pos: 0
exit_safe_binlog_gtid:
table_info: {“Lock”: null, “ShardRowIDBits”: 0, “auto_id_cache”: 0, “auto_inc_id”: 0, “auto_rand_id”: 0, “auto_random_bits”: 0, “charset”: “utf8mb4”, “collate”: “utf8mb4_bin”, “cols”: [{“change_state_info”: null, “comment”: “”, “default”: null, “default_bit”: null, “default_is_expr”: false, “dependences”: null, “generated_expr_string”: “”, “generated_stored”: false, “hidden”: false, “id”: 1, “name”: {“L”: “id1”, “O”: “id1”}, “offset”: 0, “origin_default”: null, “origin_default_bit”: null, “state”: 5, “type”: {“Charset”: “binary”, “Collate”: “binary”, “Decimal”: 0, “Elems”: null, “Flag”: 4099, “Flen”: 11, “Tp”: 3}, “version”: 2}, {“change_state_info”: null, “comment”: “”, “default”: null, “default_bit”: null, “default_is_expr”: false, “dependences”: null, “generated_expr_string”: “”, “generated_stored”: false, “hidden”: false, “id”: 2, “name”: {“L”: “id2”, “O”: “id2”}, “offset”: 1, “origin_default”: null, “origin_default_bit”: null, “state”: 5, “type”: {“Charset”: “utf8mb4”, “Collate”: “utf8mb4_bin”, “Decimal”: 0, “Elems”: null, “Flag”: 0, “Flen”: 6, “Tp”: 15}, “version”: 2}], “comment”: “”, “compression”: “”, “constraint_info”: null, “fk_info”: null, “id”: 52, “index_info”: [{“comment”: “”, “id”: 1, “idx_cols”: [{“length”: -1, “name”: {“L”: “id1”, “O”: “id1”}, “offset”: 0}], “idx_name”: {“L”: “primary”, “O”: “PRIMARY”}, “index_type”: 1, “is_global”: false, “is_invisible”: false, “is_primary”: true, “is_unique”: true, “state”: 5, “tbl_name”: {“L”: “”, “O”: “”}}], “is_columnar”: false, “is_common_handle”: false, “max_col_id”: 2, “max_cst_id”: 0, “max_idx_id”: 1, “max_shard_row_id_bits”: 0, “name”: {“L”: “t1”, “O”: “t1”}, “partition”: null, “pk_is_handle”: false, “pre_split_regions”: 0, “sequence”: null, “state”: 5, “tiflash_replica”: null, “update_timestamp”: 424086970104807426, “version”: 3, “view”: null}
is_global: 0
create_time: 2021-04-07 10:40:28
update_time: 2021-04-07 10:43:25
*************************** 3. row ***************************
id: mysql-replica-03
cp_schema: testdb
cp_table:
binlog_name: 3306-binlog.000004
binlog_pos: 1563
binlog_gtid: b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-5
exit_safe_binlog_name:
exit_safe_binlog_pos: 0
exit_safe_binlog_gtid:
table_info: null
is_global: 0
create_time: 2021-04-07 10:43:25
update_time: 2021-04-07 10:43:25
3 rows in set (0.00 sec)

ERROR:
No query specified

enable-gtid=false 时,query-status 可以正常查到 syncerBinlogGtid 信息

这个是查不到的,除非从gtid 切换到 非GTID时候,去查询会有,过一会儿就查不到了。

你这个方便在 2.0.1 的环境上操作下吗 ? 我测了下 2.0.1 没有复现你的问题。

在 2.0.1 上,enable-gtid=false 时,query-status 可以正常查到 syncerBinlogGtid 信息

后面我升级到2.0.1了,GTID只是从true变成false 启动后瞬间能查到syncbinloggtid信息,等一会就没有了。

升级到 2.0.1 还是可以稳定复现是么 ? 那辛苦再提供下 2.0.1 环境中的相关日志吧,以及 DM display 的拓扑也拿下。上游 mysql 的版本

get-config task、dm-worker.log、dm-master.log(leader)

我之前发的日志就是2.0.1的了。
[tidb@localhost ~]$ tiup -version
v1.2.3 tiup
Go Version: go1.13
Git Branch: release-1.2
GitHash: df7e28a
[tidb@localhost ~]$ tiup dm -version
Found dm newer version:

The latest version:         v1.4.1
Local installed version:    v1.2.3
Update current component:   tiup update dm
Update all components:      tiup update --all

Starting component dm: /home/tidb/.tiup/components/dm/v1.2.3/tiup-dm -version

Error: unknown shorthand flag: ‘e’ in -ersion

Verbose debug logs has been written to /home/tidb/logs/tiup-cluster-debug-2021-04-08-13-53-08.log.
Error: run /home/tidb/.tiup/components/dm/v1.2.3/tiup-dm (wd:/home/tidb/.tiup/data/STy0fGF) failed: exit status 1
[tidb@localhost ~]$ tiup dmctl
Starting component dmctl: /home/tidb/.tiup/components/dmctl/v2.0.1/dmctl/dmctl
Usage: dmctl [global options] command [command options] [arguments…]

image

操作时间在13:55左右
stop 同步任务
stop 数据源
修改gitd 为false
create 数据源
start 同步任务
查看任务
[tidb@localhost ~]$ tiup dmctl --master-addr 10.200.25.254:8261 query-status mgr
Starting component dmctl: /home/tidb/.tiup/components/dmctl/v2.0.1/dmctl/dmctl --master-addr 10.200.25.254:8261 query-status mgr
{
“result”: true,
“msg”: “”,
“sources”: [
{
“result”: true,
“msg”: “”,
“sourceStatus”: {
“source”: “mysql-replica-03”,
“worker”: “dm-10.200.25.254-8262”,
“result”: null,
“relayStatus”: null
},
“subTaskStatus”: [
{
“name”: “mgr”,
“stage”: “Paused”,
“unit”: “Sync”,
“result”: {
“isCanceled”: false,
“errors”: [
{
“ErrCode”: 10006,
“ErrClass”: “database”,
“ErrScope”: “not-set”,
“ErrLevel”: “high”,
“Message”: “startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (3306-binlog.000004, 1955), gtid-set: b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-6]: execute statement failed: REPLACE INTO testdb.t1 (id1,id2) VALUES (?,?)”,
“RawCause”: “Error 1366: Incorrect datetime value: ‘hu’ for column ‘id2’ at row 1”,
“Workaround”: “”
}
],
“detail”: null
},
“unresolvedDDLLockID”: “”,
“sync”: {
“totalEvents”: “1”,
“totalTps”: “0”,
“recentTps”: “0”,
“masterBinlog”: “(3306-binlog.000034, 59699914)”,
“masterBinlogGtid”: “b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-7929943”,
“syncerBinlog”: “(3306-binlog.000004, 1750)”,
“syncerBinlogGtid”: “b639a283-5453-47f2-af5e-fb2bc85bdaa6:1-6”,
“blockingDDLs”: [
],
“unresolvedGroups”: [
],
“synced”: false,
“binlogType”: “remote”
}
}
]
}
]
}dm-worker.log (5.7 MB) dm-master.log (3.3 MB)

好的, 多谢。另外方便填写下 你这边的相关信息么 ?
image

还有就是看了下日志,4-8 号的时候,是把 enable-gtid=true 改成 enable-gtid=false

之前测试的时候是 pos → gtid 数据重新同步,报错,
4-8 号测试 gtid → pos 也是会报错的,是这样吗 ?

还有 DM 上游数据库的是用的什么? 版本信息提供下吧。

是的,都会报错。 mysql 5.7.33-- TIDB 4.0.11

:ok_hand::ok_hand:

hi 关于这个问题,具体问题为:
用户从 gtid 为 false 改为 true 后,因为 BinLogGTID 未填写为空,checkpoint 中该值也为空,因此 dm 从头开始同步了。改回 false 也无法继续同步是因为 checkpoint 已经停在了错误的点,所以改回来从错误 pos 点开始也会报错。

现在有两个解决方案:

  1. 重新同步:清理下游,开启 gtid 重新 start-task --remove-meta
  2. 调整下游 checkpoint 为之前已同步到的 gtid 和 pos

后续 dm 会想办法自动匹配 pos 和 gtid 位点解决这一问题。

感谢耐心提供信息~

感谢您的支持。

这样看来,如果要实现切换worker的数据源,目前就必须要一开始就要使用gtid模式同步或者更改GTID为true,然后重新初始化数据同步了。

是的哈~