Proposing as a blocker for 4.12.0 as the current behavior leads to application downtime and very high RTO which isn't acceptable.
Given that it is a relocate operation and not failover, according to engineering this does not qualify as a blocker. Also, in order to identify the actual bottleneck we need more enhancements which are not possible for 4.12 Shyam, Do we need to add it as a known issue in 4.12?
(In reply to Mudit Agarwal from comment #12) > Given that it is a relocate operation and not failover, according to > engineering this does not qualify as a blocker. > Also, in order to identify the actual bottleneck we need more enhancements > which are not possible for 4.12 > > Shyam, > > Do we need to add it as a known issue in 4.12? I do not think so, as it would depend on the amount of data etc. to transfer. IOW, barring the unavailability of a metric on how much data is left to transfer there is no known issue here. Requested to add a note to the DR document in the relocate pre-req to check last sync time is closer to current time before relocation, to speed up the process: https://docs.google.com/document/d/1N6IbYv6SGkmAsj6UHGrZWNnUD3qHq3nsPFH4obCBf6M/edit?disco=AAAAkUOiR84