We are debating moving from stand alone SQL server instances to SQL Always on Availability Groups for the benefits they provide. Mainly we can do maintenance on vms without taking the databases offline.
off topic from veeam, but FYI,
I moved a ton of databases to SQL AG groups and there are a few things you are going to run into that are not going to work as you expect out of the box, primarily the fact that users are not replicated between the Nodes of the cluster which means when you failover, nothing is actually going to work. Sure the databases are online, but none of the applications/users can't access them.
Creating Containerized SQL users seems like the obvious solution, but most applications don't know how to use containerized accounts and still interact with the global server security users section of the server itself. Hard to explain but you will figure it out when you try and connect an app to a database where the user is containerized.
Windows based login's also do not replicate so you are going to need to run a script on a regular basis that copies the users/passwords between the nodes. (https://www.sqlshack.com/synchronize-lo ... ity-group/)
Another thing that doesn't work is automatic seeding...never worked in 2017-2022 versions of SQL...We've always had to do the backup and restore to get them to seed....for empty databases, that's fine, for large databases, it really sucks.
Busy databases take FOREVER to get back in sync before you can fail back...we have a Solarwinds Orion database that literally takes an hour to get back in sync so we can failback after a failover. High transactional databases really are not suited to AG clusters it seem even with redundant 10G networks between nodes all running on Flash.
Full backup mode...if you have any databases in basic mode (like a data warehouse where large transactional actions happen generating massive TRN files so were left in basic mode, those cannot be part of the failover cluster....we had to move those to standalone database servers to make management simpler and avoid alerts of databases not sync'd (since they were not part of cluster)
No real native failover notification...we've had AG's just failover magically for no apparent reason and after 30-40 hours with Microsoft they didn't have answer either., except blame environment...there is not native alerting to let you know, it's usually scream test![:)]( "Smile")
Especially if someone has configured their app to talk to the SQL server name instead of the Cluster name...
Performance...one thing that might suprise you, if you have a DR environment with a node and it suffers performance problems (say the disk is overloaded), this WILL slow down your production system if running in synchronous mode (which you most likely will want to do) as the transactions are not committed on prod until they are committed on the DR side...
Those are the highlights of things I can think of right off the top of my head...
off topic from veeam, but FYI,
I moved a ton of databases to SQL AG groups and there are a few things you are going to run into that are not going to work as you expect out of the box, primarily the fact that users are not replicated between the Nodes of the cluster which means when you failover, nothing is actually going to work. Sure the databases are online, but none of the applications/users can't access them.
Creating Containerized SQL users seems like the obvious solution, but most applications don't know how to use containerized accounts and still interact with the global server security users section of the server itself. Hard to explain but you will figure it out when you try and connect an app to a database where the user is containerized.
Windows based login's also do not replicate so you are going to need to run a script on a regular basis that copies the users/passwords between the nodes. (https://www.sqlshack.com/synchronize-lo ... ity-group/)
Another thing that doesn't work is automatic seeding...never worked in 2017-2022 versions of SQL...We've always had to do the backup and restore to get them to seed....for empty databases, that's fine, for large databases, it really sucks.
Busy databases take FOREVER to get back in sync before you can fail back...we have a Solarwinds Orion database that literally takes an hour to get back in sync so we can failback after a failover. High transactional databases really are not suited to AG clusters it seem even with redundant 10G networks between nodes all running on Flash.
Full backup mode...if you have any databases in basic mode (like a data warehouse where large transactional actions happen generating massive TRN files so were left in basic mode, those cannot be part of the failover cluster....we had to move those to standalone database servers to make management simpler and avoid alerts of databases not sync'd (since they were not part of cluster)
No real native failover notification...we've had AG's just failover magically for no apparent reason and after 30-40 hours with Microsoft they didn't have answer either., except blame environment...there is not native alerting to let you know, it's usually scream test
Especially if someone has configured their app to talk to the SQL server name instead of the Cluster name...Performance...one thing that might suprise you, if you have a DR environment with a node and it suffers performance problems (say the disk is overloaded), this WILL slow down your production system if running in synchronous mode (which you most likely will want to do) as the transactions are not committed on prod until they are committed on the DR side...
Those are the highlights of things I can think of right off the top of my head...
Statistics: Posted by Rumple — Dec 31, 2024 5:14 pm
![Madonna – Who’s That Girl (1987/2020) [FLAC 24bit/192kHz]](http://imghd.xyz/images/2023/06/08/0093624951148_6004dceff9e1db710a9.jpg)
