August 3, 2025 at 6:56 pm
Good afternoon,
I had a 7.8 TB database that needed some work. I removed the database from the AG, did my work, ran a backup (took 4 hours) and then added it back to the AG.
That worked. We have two secondaries with the primary in this AG. The first secondary server (secondary replica #1) was in restoring for about 4 hours. It is now synchronized.
The second secondary server in the AG (secondary replica #2) is still showing restoring.
Is there to way to bring the second secondary replica to synchronized without remove the database from the AG again?
Any thoughts on this would be appreciated? I would had to remove the database from the AG on the primary and then have to add it back and let it restore on both secondaries.
Things will work out. Get back up, change some parameters and recode.
August 4, 2025 at 7:45 am
Does this provide usable info for you ?
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS ag_name,
CASE HDRS.is_primary_replica WHEN 1 THEN 'Primary' ELSE 'Secondary' END AS Replica,
HDRS.synchronization_state_desc,
HDRS.log_send_queue_size,
HDRS.redo_queue_size,
HDRS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS HDRS
INNER JOIN sys.availability_databases_cluster AS adc
ON HDRS.group_id = adc.group_id AND HDRS.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = HDRS.group_id
INNER JOIN sys.availability_replicas AS ar
ON HDRS.group_id = ar.group_id AND HDRS.replica_id = ar.replica_id;
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
August 6, 2025 at 6:44 pm
Thanks Johan. No, I already had that. I just didn't want to have to move the database out of the AG again. It is about 8 TB. Then, when I add it back to the AG, the seeding of the secondary replicas should kick off.
Things will work out. Get back up, change some parameters and recode.
August 6, 2025 at 7:42 pm
As a thought - any way you can reduce the database size? Is there some data you could archive to get it to a more manageable size or is all 8 TB of that data in use?
If you can archive some of the data into an archive database, and it is not needed, you could back it up and delete it and restore only if/when it is needed. If it is needed but not actively, you could offload it to slower storage and not replicate the archived data.
Doesn't help the current problem, but helps in the event you need to do disaster recovery as an 8 TB database restore is not a quick task. And if your AG gets badly out of sync again and you need to redo this, it'll be faster with smaller databases.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply