0

I have seen frequently few databases are having synchronization issue with secondaries and monitored the same and found redo data queue size is around in 2MB in secondary replicas. I have tried in GUI for resume data and do syncup but it's failed giving error.

Do we have any code for apply Redo pending data on secondary replica databases manually.

3
  • What you are seeing is normal on busy AOAG. There is no code AFAIK let SQL Server do this task gracefully
    – Shanky
    Aug 16, 2016 at 9:05
  • If it's taking much time then how we would troubleshoot this issue. I mean the size is huge if we get a situation as need to failover the AG then we would be in trouble right. Because all DB's should be in sync for failover to other node AG right?
    – Narendra
    Aug 16, 2016 at 12:37
  • Add a screenshot showing the redo queue and log send queue. There are few ways in which you can make sure you do not overwhelm the network. How often you run index maintenance did you ran just before you are seeing this issue, does network is powerful enough to handle the amount of logs getting generated
    – Shanky
    Aug 16, 2016 at 12:40

1 Answer 1

1

I have seen frequently few databases are having synchronization issue with secondaries and monitored the same and found redo data queue size is around in 2MB in secondary replicas.

This is indicative of two possible items (or both).

  1. The system (storage, memory, cpu) isn't fast enough or have enough bandwidth to redo the log blocks.
  2. REDO may be blocked by a user thread if it's a readable secondary.

I have tried in GUI for resume data and do syncup but it's failed giving error.

Was it not synchronized? If not, that's a different problem. Pausing and resuming will potentially only make it worse, depending on the root cause.

Do we have any code for apply Redo pending data on secondary replica databases manually.

No, there isn't a button to press to tell the REDO to run. It runs. Constantly. All the time.

It doesn't run when it's blocked and it runs very slowly when it doesn't have the hardware to run properly (primary may be more powerful than secondary, etc.).

If you look at the secondary, there should be an AlwaysOn Health extended events session running. Opening the XEL file in management studio (SSMS) will give you what has been captured. Look for any REDO BLOCKED messages. If there aren't any, run a perfmon on the system to check on IO latency and throughput, memory, and cpu utilization.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.