Dockerizing MySQL at Uber Engineering

Re:Dockerizing MySQL at Uber Engineering by otterley on Monday November 28, 2016 @11:33AM (#13056458)

Additionally, the article appears to falsely assume that one can start a new container with a different and arbitrary MySQL version and reuse the data volumes from the previous container. From experience I know that this is not always the case: upgrades might work, but downgrades often will not. Even in the case of upgrades, various DB schema changes will be needed.

[ Parent | on HN ]

Re:Dockerizing MySQL at Uber Engineering by evanelias on Monday November 28, 2016 @11:52AM (#13056624)

In my experience it's generally safe to upgrade (and usually even downgrade) across post-GA point releases of the same major version, i.e. 5.6.22 -> 5.6.31 or vice versa.

You should always run mysql_upgrade to be safe, and I'd assume Uber's automation does this. But you probably won't encounter problems if you don't.

mysql_upgrade typically just makes some quick changes to the system schema ("mysql" database), not to other data. And it typically only needs to change things across major version upgrades (5.5->5.6) or pre-GA releases; it's rare to make a change in a point release of a major version much after the GA release.

That all said, I don't ever advocate using Docker for MySQL in production at this time; see my longer comment in another subthread below for reasoning.

[ Parent | on HN ]

Re:Dockerizing MySQL at Uber Engineering by falcolas on Monday November 28, 2016 @12:09PM (#13056758)

> In my experience it's generally safe to upgrade (and usually even downgrade) across post-GA point releases of the same major version

My experience with this mirrors the parents. The more data you have, and the more obscure engine features you use, the more likely it is to happen. It only takes one major failure to make you want to test the daylights out of any upgrades or downgrades.

[ Parent | on HN ]

Re:Dockerizing MySQL at Uber Engineering by evanelias on Monday November 28, 2016 @12:12PM (#13056776)

I agree; I wasn't advocating not testing. My point was more that the parent was overstating the risk, particularly around things like required schema changes, or data volumes no longer being usable. Those particular things aren't issues in my experience (for post-GA point releases), and I've worked at crazy scale.

The more common classes of problem are performance degradation, config options being added or renamed, new features being buggy in rare edge cases, etc. Not things particular to InnoDB's storage format or things that would prevent a volume from being usable with a different version.

[ Parent | on HN ]