About the generative mechanism of TrackingID

What’s the generative mechanism of TrackingID? Under what circumstances (eg. restart, change of IP address, scale in & out, etc. ) will it change?

1 Like

According to the codebase, the TrackingID will be (lazily) retrieved when the report is going to be happen: https://github.com/pingcap/tidb/blob/19e100c27a37601d674df625034ebddb5196a299/telemetry/telemetry.go#L108

Then, dig into the implementation, you can see that TrackingID is persisted in the etcd: https://github.com/pingcap/tidb/blob/19e100c27a37601d674df625034ebddb5196a299/telemetry/id.go#L30

In summary, the TrackingID will be generated at the first report time. It will be persisted in the etcd, which means it will not change after restarting or scaling.

However notice that user is able to manually reset a TrackingID to “forget” himself: https://github.com/pingcap/tidb/blob/19e100c27a37601d674df625034ebddb5196a299/executor/admin_telemetry.go#L56. In this way, this cluster will have a new TrackingID. This syntax is undocumented though.

3 Likes

Thank you for your information and patience. This is really helpful b( ̄▽ ̄)d