Workflow Show: use timeUpdated to calculate vreplication lag

[rohit-nayak-ps]

Signed-off-by: Rohit Nayak [email protected]

Description

1. There was a problem in the initial implementation of determining MaxVReplicationLag, which was the seconds since transaction_timestamp. MaxVReplicationLag is used, in a Reshard workflow, by the operator to determine when resharding is completed. See VReplication stream heartbeats record incorrect event timestamps #6946, which logs the problem and fixes it. However this fix was problematic for two reasons:

   • transaction_timestamp is 0 as long as the stream is in the copy phase. If there are no new writes on the source once the copy phase is completed then the value does not get updated
   • there are cases when there are no writes on the source relevant to a target. In this case the transaction_timestamp column for that stream does not get updated as there are no new events seen by the target.
     
     

   In both cases the operator decides that the stream is lagging and doesn't perform the cutover. This PR changes the logic to use the time_updated column instead of transaction_timestamp. time_updated is updated both when there is a binlog event from the source and also when the source sends a heartbeat (every idle second).

2. Don't display unused column max_replication_lag from _vt.vreplication

   This column was used several versions earlier for throttling SplitClone streams. Vreplication workflows do not use it and it should not be displayed since it always displays MaxInt and is confusing to users.

Related Issue(s)

#6946

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build
• VTAdmin

[deepthi]

LGTM

[PrismaPhonic]

LGTM