tiflow icon indicating copy to clipboard operation
tiflow copied to clipboard

DM: dmctl query-status to return checkpoint position

Open mzhang77 opened this issue 1 year ago • 0 comments

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

mzhang77 avatar Jul 19 '24 13:07 mzhang77