tiflow
tiflow copied to clipboard
DM: dmctl query-status to return checkpoint position
Is your feature request related to a problem?
In dm-worker log, there are 3 binlog positions:
[2024/07/18 15:33:13.682 +00:00] [INFO] [status.go:149] ["binlog replication status"] [task=mysql1] [unit="binlog replication"] [total_rows=17322636] [total_rps=6260] [rps=0] [master_position="(binlog.000119, 23186223)"] [master_gtid=] [checkpoint="location(position: (binlog.000119, 23186223), gtid-set: 00000000-0000-0000-0000-000000000000:0) (flushed location(position: (binlog.000119, 22526200), gtid-set: 00000000-0000-0000-0000-000000000000:0))"]
In dmctl query-status output there are only 2 binlog positions:
"sync": {
"totalEvents": "17322668",
"totalTps": "3798",
"recentTps": "0",
"masterBinlog": "(binlog.000119, 23186223)",
"masterBinlogGtid": "",
"syncerBinlog": "(binlog.000119, 23186223)",
"syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
In a cutover scenario, when checkpoint catches up master_position, the replication is completed. However from checkpoint catches up master_position to flushed location catches up master_position, there can be up to 30s delay, controlled by parameter checkpoint-flush-interval. In cutover when every second is valuable, this delay is unnecessary.
Describe the feature you'd like
This feature request suggest to add checkpoint binlog position to dmctl query-status output, so it can be used in catover scenario.
Describe alternatives you've considered
Right now in cutover scenario, we can monitor dm-worker log file instead, which is inconvenient.
Teachability, Documentation, Adoption, Migration Strategy
No response