How to Use PowerShell to Track a Network Latency Issue in an Always On Availability Group

Question

Post reply

How to Use PowerShell to Track a Network Latency Issue in an Always On Availability Group

Vincent92

Old Hand

Points: 303
More actions
October 21, 2022 at 12:00 am

#4074059

Comments posted to this topic are about the item How to Use PowerShell to Track a Network Latency Issue in an Always On Availability Group

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

Richard M. SSCertifiable Points: 7401 More actions · Answer 1

Interesting insight into the research process to find out what the root cause might be.

I am a little confused though about your comment:

Since the full backup job of both replicas happened at the same time

What are your AG Backup preferences set to? Database backups in an AG are done either on the Primary or the Secondary, depending on that setting, not both, so it doesn't make sense to me that your solution would fix your root cause of timeouts.

_______________________________________________________________________
For better assistance in answering your questions, click here[/url]

saatanlami Newbie Points: 2 More actions · Answer 2

saatanlami

Newbie

Points: 2

October 21, 2022 at 10:17 pm

#4102732

thanks

Vincent92 Old Hand Points: 303 More actions · Answer 3

Hi, The log backup of AOAG only happened on the primary or secondary replica regarding the AOAG backup ploicy, but we created the same scheduled job for the daily full DB backup under both replicas, so full DB backup happened on both replicas, thanks

Richard M. SSCertifiable Points: 7401 More actions · Answer 4

If you created the same scheduled job on both replicas, and are not doing the right backup config, you might be creating a mess with your backup chain.

The fact that the backups are not failing, means probably the FULL backups are happening with the COPY_ONLY parameter, otherwise the backup would fail on the Secondary (Read Only) replica.

AlwaysON allows to control where your Automated backups happen, as per the Backup Preferences set on the AG. The Automated backup jobs should check if they are running on the preferred backup replica. If they aren't, they will not run there (by design).

You indicated that your backups effectively run on both replicas. If your Log backups are also running that way, I wish you good luck trying to piece the backup chain together when trying to do a Point in Time restore (by the way, have you tried restoring a database, with t-logs ?).

I'd suggest reading up on backups on AlwaysON. A good resource to start is Configure backups on secondary replicas of an Always On availability group, but you will find many other good resources on the 'net.

What peaked my attention on your article is that both of your replicas were doing the backup, which means your backup setup is not configured properly. backups should only be running from the Preferred Replica, not both servers.

_______________________________________________________________________
For better assistance in answering your questions, click here[/url]

Vincent92 Old Hand Points: 303 More actions · Answer 5

Hi, Richard, thank you, we did use "Copy only" for full backup, so it is possible to do the full backup on both nodes, but we finally think it's not meaningful to do that and just remain the full backup job on the secondary node.

Richard M. SSCertifiable Points: 7401 More actions · Answer 6

Right. Not only not meaningful, but messy, at best. Include the logic pointed out in the article I linked (or any other you found on this topic), so the backups happen where they should and will still run when a failover happens.

_______________________________________________________________________
For better assistance in answering your questions, click here[/url]