←back to thread

Upgrading Uber's MySQL Fleet

(www.uber.com)
234 points benocodes | 2 comments | 14 Oct 24 12:08 UTC | HN request time: 0.018s | source
Show context
xyst ◴[14 Oct 24 14:42 UTC] No.41838001[source]▶
I wonder if an upgrade like this would be less painful if the db layer was containerized?

The migration process they described would be less painful with k8s. Especially with 2100+ nodes/VMs

replies(5): >>41838083 #>>41838418 #>>41838563 #>>41839037 #>>41839595 #
1. meesles ◴[14 Oct 24 16:25 UTC] No.41839037[source]▶
A pipe dream. Having recently interacted with a modern k8s operator for Postgres, it lacked support for many features that had been around for a long time. I'd be surprised if MySQL's operators are that much better. Also consider the data layer, which is going to need to be solved regardless. Of course at Uber's scale they could write their own, I guess.

At that point, if you're reaching in and scripting your pods to do what you want, you lose a lot of the benefits of convention and reusability that k8s promotes.

replies(1): >>41841224 #
2. jcgl ◴[14 Oct 24 19:54 UTC] No.41841224[source]▶
> it lacked support for many features that had been around for a long time

Care to elaborate at all? Were they more like missing edge cases or absent core functionality? Not to imply that missing edge cases aren’t important when it comes to DB ops.