I'm an old dog, and I do agree about trust-ability of shared storage solution (with disk layer replication). What I afraid with shared-nothing topology (each has it own disk) is the old wisdom of "shared nothing = replicate everything". Documentation mostly focus on fail-over event, but recovering primary side back is lacking, the re-sync, re-electing master node. I hope, I'd reach my retirement before I have to deal with it, thanks for the content, I do enjoy it.
I havent had the pleasure(?) To work with sql servers for couple of years, transitioned to other stuff, but I still enjoy listening your videos. Just because how you explain things, thanks Brent.
I 100% agree with the biggest issue with Always On is the availability of good, or actually any, management and troubleshooting tools. All it has out of the box is a simple dashboard that tells you little. Instead it requires you know a bunch of queries and have the ability to understand and respond to the queries and what to do with the information. Not easy.
Just a side node, moving from shared storage was not due to expensive replication of the storage. It was due to VMs and having a nightmare with things like iSCSI. Having attached storage directly to a VM means you cannot use snapshots "properly", full VM backup/restore or great features like vMontion. To use the best features of virtualization, you need to have only VMDK-s :D Please, feel free to correct me, if I am wrong.
We use AGs in db mirroring mode without WSFC i.e. cluster_type=none. We can mirror 300-500 dbs on a single instance this way but the failover is manual so it’s kind of like log shipping on steroids. Strange Brent didn’t discuss option for Win and Linux both.
It sounds like if you want your system to stay on during deployments, shared storage is out of the question. Are there any 3rd party solutions that offer what Always-On Availability Groups offers but with less management headaches?
I'm not sure what you mean about "stay on during deployments" - AGs don't have zero-downtime failover either. Feel free to contact me for consulting help for zero-downtime solutions, but that's way beyond what I can do in UA-cam comments.
@@BrentOzarUnlimited Oh, I thought with Always On = zero-downtime. My mistake. And yes, you are definitely in the Rolodex for when we decide we need consulting assistance. I am a lifetime training class subscriber and have gotten a to a value from your classes.
Loved this version. Just talking about 1 topic at a time ❤
Glad you liked it! If you like that, you'll love my training classes - that's where I do deep dives on a single topic.
I'm an old dog, and I do agree about trust-ability of shared storage solution (with disk layer replication).
What I afraid with shared-nothing topology (each has it own disk) is the old wisdom of "shared nothing = replicate everything".
Documentation mostly focus on fail-over event, but recovering primary side back is lacking, the re-sync, re-electing master node. I hope, I'd reach my retirement before I have to deal with it, thanks for the content, I do enjoy it.
Glad you liked it!
Informative, interesting and entertaining as always, thanks Brent 🙂
I havent had the pleasure(?) To work with sql servers for couple of years, transitioned to other stuff, but I still enjoy listening your videos. Just because how you explain things, thanks Brent.
Aww, thanks!
I 100% agree with the biggest issue with Always On is the availability of good, or actually any, management and troubleshooting tools. All it has out of the box is a simple dashboard that tells you little. Instead it requires you know a bunch of queries and have the ability to understand and respond to the queries and what to do with the information. Not easy.
Yep, agreed.
Great chat! Thanks Brent!
Glad you liked it!
Wonderful coverage.
You didn't touch on Distributed AG and VM snapshots. Do you have comments on these as like or dislike?
Just a side node, moving from shared storage was not due to expensive replication of the storage. It was due to VMs and having a nightmare with things like iSCSI. Having attached storage directly to a VM means you cannot use snapshots "properly", full VM backup/restore or great features like vMontion. To use the best features of virtualization, you need to have only VMDK-s :D Please, feel free to correct me, if I am wrong.
No, that is not correct. It was correct in the early days of virtualization, but hasn't been true for over a decade.
We use AGs in db mirroring mode without WSFC i.e. cluster_type=none. We can mirror 300-500 dbs on a single instance this way but the failover is manual so it’s kind of like log shipping on steroids. Strange Brent didn’t discuss option for Win and Linux both.
3:04 I thought the painting was Ron Perlman riffing on his role in Sons of Anarchy
26:35 Brent often talks about SAN, e.g. SAN backups and SAN replication. What's the AWS equivalent?
Check out my "Running SQL Server in the Cloud" training course - we cover it there.
It sounds like if you want your system to stay on during deployments, shared storage is out of the question. Are there any 3rd party solutions that offer what Always-On Availability Groups offers but with less management headaches?
I'm not sure what you mean about "stay on during deployments" - AGs don't have zero-downtime failover either. Feel free to contact me for consulting help for zero-downtime solutions, but that's way beyond what I can do in UA-cam comments.
@@BrentOzarUnlimited Oh, I thought with Always On = zero-downtime. My mistake. And yes, you are definitely in the Rolodex for when we decide we need consulting assistance. I am a lifetime training class subscriber and have gotten a to a value from your classes.
@@marcscirri7493 Great, glad I could help! Yeah, unfortunately Always On is just a marketing brand name. It doesn't actually mean "always on", heh.
See edwin sem training om availability groups
Yes, I do training on Always On Availability Groups. I owe @BrentOzarUnlimited for getting helping me get it off the ground.
Great chat! Thanks Brent!