SQL Server Always On Availability Groups 101

Рет қаралды 5,274

Brent Ozar Unlimited

Күн бұрын

Пікірлер: 24

@anuragkumar-dm1er 2 ай бұрын

Loved this version. Just talking about 1 topic at a time ❤

@BrentOzarUnlimited 2 ай бұрын

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.

@staffansolson9544 4 күн бұрын

Great chat! Thanks Brent!

@utenatenjou2139 2 ай бұрын

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.

@BrentOzarUnlimited 2 ай бұрын

Glad you liked it!

@wensday8784 2 ай бұрын

Informative, interesting and entertaining as always, thanks Brent 🙂

@PauliPorkka 2 ай бұрын

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.

@BrentOzarUnlimited 2 ай бұрын

Aww, thanks!

@Bill_N_ATX 2 ай бұрын

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.

@BrentOzarUnlimited 2 ай бұрын

Yep, agreed.

@wqweto 4 күн бұрын

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.

@nofreenamestoreg 2 ай бұрын

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.

@BrentOzarUnlimited 2 ай бұрын

No, that is not correct. It was correct in the early days of virtualization, but hasn't been true for over a decade.

@rebornfenix4412 2 ай бұрын

3:04 I thought the painting was Ron Perlman riffing on his role in Sons of Anarchy

@marcscirri7493 2 ай бұрын

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?

@BrentOzarUnlimited 2 ай бұрын

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 KZbin comments.

@marcscirri7493 2 ай бұрын

@@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.

@BrentOzarUnlimited 2 ай бұрын

@@marcscirri7493 Great, glad I could help! Yeah, unfortunately Always On is just a marketing brand name. It doesn't actually mean "always on", heh.