The newest Cumulative Update for SQL Server 2019 has this gem in the release notes:
This is a massive problem if:
- You have databases encrypted with TDE
- You take backups WITH COMPRESSION (which has a history of bugs already), or you have the server’s default compression option turned on
- You’re doing log shipping to other 2019 servers
- You patch the primary to CU16 before you patch the secondaries
You might say, “Well, you should always patch the secondaries first” – but in some shops, here’s how they approach patching:
- Patch the secondary (Server2)
- Fail over to the patched secondary (Server2) but do not patch the former primary (Server1) just yet, because you’re worried about something going wrong in the patching
- Wait a few hours or days before patching Server1
At that point, the unpatched Server1 is the secondary – but it can no longer restore backups because of this “feature” of CU16. (That’s exactly how I discovered this issue – a client’s log shipping was broken when they had problems with CU16 and tried to fail back to Server1 – but they couldn’t. CU16 is a one-way trip if you’re using log shipping.)
The “feature” is detailed in this KB article, which says:
In my client’s case, to get back to the CU15 servers quickly, we had to take uncompressed full & log backups from the CU16 primary over to the CU15 server, and were then able to go live on CU15 again. (I wasn’t involved in troubleshooting the issues they had with CU16 that drove them to fall back to CU15.)
12 Comments. Leave new
But why would anyone ever want to downgrade to previous CU?
LOL
Wow, you were so lucky that you have encountered any issues on CU upgrades.
I meant to say
Wow, you were so lucky that you have not encountered any issues on CU upgrades.
(Clippy is a joke account someone is using. If you’ve been through my classes, you may recognize the character. If not, hey, now’s a good time to join! Click Fundamentals Week at the top of the screen.)
“We’ve designed a new car. Please not the brakes are on the passenger side, so you can’t stop the car. But other than that, everything is great!”
Gott love the Marketing geniuses at MS…..
Any known implications for CLE?
No, as far as I’m aware, there’s nothing built into SQL Server that’s specific to any given airport. Performance and behavior at Cleveland Hopkins International Airport should be the same as anywhere else.
This wasn’t a big issue for us. Granted we forgot about log shipping impact but it only impacted 2 servers so we just had to apply CU16 to those servers a few days earlier than scheduled.
We upgraded to CU16 very recently. Auto seeding is also an issue between CU15 and CU16. However, it works when both replicas are on CU16.
Thanks for the notice. Was TDE or compression enabled? Just wondering if it has any effect.
“This is a massive problem if” Are those points “AND” or “OR”? Could you simply turn off compression to get out of trouble?
I have to admit that I have found the above blog mildly confusing.
On initial read, I took it as dot points as an Or Statement. Reading the KB entries, I gather its an And statement 🙂
So, if I have a non TDE encrypted database, but use compression on Backups, I’m OK?