Earlier quoted context omitted.
In terms of more fundamental features: can it do CHECK constraints yet?
If I remember correctly, 8.0 has them finally. 8.0 seems to have fixed a lot of the weird legacy eccentricities of MySQL
8.0.16 to be precise
Migrating Facebook to MySQL 8.0
291–300 of 336 posts
Re: Migrating Facebook to MySQL 8.0
#292Earlier quoted context omitted.
there's also this team page, although it has been somewhat lower on volume lately - https://www.facebook.com/MySQLatFacebook/
I've not got a FB account due to reservations about FB and their business model but that doesn't mean I am above learning from what they do, thanks for the link, I'll have to find info elsewhere though.
I don't think you need a FB account to read the posts there, you can just treat it like a blog with a crappy interface (but very good content). Probably some mandate to "eat your own dog food".
Re: Migrating Facebook to MySQL 8.0
#293Earlier quoted context omitted.
I like Postgres but still turn to MySQL for production use most of the time for a few reasons: * Permission management on Postgres is much more painful. * The need for an external connection pooler makes postgres more annoying to set up. * Better quality docs on performance tuning MySQL.
> * Permission management on Postgres is much more painful. but way more flexible and powerful I only work in the Java world where all application servers have the connection pooling built in, so I never had the need for an external connection pooler.
I joined a company where most stuff is done in Java and tried to explain to colleagues that sn external connection pool would ne good. They didn't know such things existed at all, and then refused because in their mind the application-specific intetnal pools were all they needed. Which was and is totally wrong - the application server internal pools, like HikariCP only share connections between threads inside the server. What if now we have 4 instances of the same server running (because of a deployment, where 2 new ones are spawned, started and the 2 old ones aren't taken down until the loadbalancer determines that the new o es are running ok. Now you need 2x the number of connections available than you would ususlly need. Once we had run out of connections when for some reason aws went crazy and started deploying too many instances of the application.
Re: Migrating Facebook to MySQL 8.0
#294Earlier quoted context omitted.
SemVer is a relatively recent proposal that the vast majority of software does not follow. Calling the three parts of a three-part version “major”, “minor” and “patch” is a SemVer thing, not a universal standard.
SemVer did not introduce major / minor / patch, that was standard usage in free and open source software for decades beforehand. Example from 20 years ago: > The most popular version numbering scheme stems from the . . scheme — https://ask.slashdot.org/story/01/01/05/0054230/version-numb... Example from 1997: > Python versions are numbered A.B.C or A.B. A is the major version number -- it is only incremented for majo…
Fair enough, you’re right that it’s more widespread than just SemVer (though IMO still not an ironclad standard)
Re: Migrating Facebook to MySQL 8.0
#295Earlier quoted context omitted.
Oracle, compared to their image is quite technically adept — they did a splendid job with OpenJDK and they have plenty of long-term R&D projects like GraalVM.
Yeah so, all of that seemed to happen after that Cantrill talk. How did Oracle suddenly turn from a pure license contract squeezing company into a tech leader again? I mean, they had to hire great engineering talent to do all this. And convince them to work for Oracle . What's the narrative I'm missing?
>Yeah so, all of that seemed to happen after that Cantrill talk.
The talk was in 2011, Oracle purchased Sun in 2010. So basically their continuous work on OpenJDK has nothing to do with the talk at all.
Re: Migrating Facebook to MySQL 8.0
#296Earlier quoted context omitted.
MySQL does not follow semantic version and there have been features introduced in minor released including some incompatible changes as you can see for example https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24....
That's still a patch release not a minor release.
If it does not follow semantic versions, it is just a third-level version number. It's like Linux's 2.6.x series.
Re: Migrating Facebook to MySQL 8.0
#297Earlier quoted context omitted.
No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.
I’m not saying semver is a universal standard but this is _wildly_ different to everything else. Nobody expects defaults to change between patch/minor versions. This is another example of how MySQL does not give a flying F about the footguns it leaves lying around. Putting the onus on the user is not reasonable; especially in a world where we’re trying to reduce toil or get rid of ops completely.
> _wildly_ different to everything else
Linux?
Re: Migrating Facebook to MySQL 8.0
#298Earlier quoted context omitted.
It is pretty scary because most of these new features or enhancements are buggy. By not adopting SemVer, users of MySQL who prefer stability (oxymoron?) have no obvious upgrade path. They could be happily using version 8.0.123, and then upgrade to version 8.0.126 to get some security fix, and suddenly encounter a bunch of functionality and/or performance regressions. Some examples... WL#10310 Redo log optimization: F…
This is a misconception that new features introduce more bugs than eg. patches/minor version upgrades. I can only bring up the OpenJDK project as example but this sort of change happened there as well - what used to be JDK 8.xxx and everyone jumped to that without second thought is the exact same thing as JDK 9->10. It’s just management’s backwards thinking that somehow the former is safe to apply while the latter is…
There is certainly no hard and fast rule. In the JDK case, in terms of language design, my observation is that with Brian Goetz in charge, it doesn't matter too much whether it was the slow release cycle back in the pre-9 days, or the shorter one from JDK 9 onward -- whenever a new feature is introduced, all kinds of compatibilities are being maintained at all costs.
(Except Project Jigsaw of course, but I'd like to think that he got overruled by his boss)
As for bugs, I will just quote Gil Tene from https://www.theserverside.com/opinion/Dont-ever-put-a-non-Ja...
> Play with them on your laptop, but don't use a single feature, and wait for the LTS.
Personally I think the LTS model is great. Features get rolled out as soon as they are ready, and then get stabilized after being used by early adopters. Meanwhile, production can stay on LTS and continue to get just the necessary fixes.
Re: Migrating Facebook to MySQL 8.0
#299Earlier quoted context omitted.
SemVer is a relatively recent proposal that the vast majority of software does not follow. Calling the three parts of a three-part version “major”, “minor” and “patch” is a SemVer thing, not a universal standard.
SemVer did not introduce major / minor / patch, that was standard usage in free and open source software for decades beforehand. Example from 20 years ago: > The most popular version numbering scheme stems from the . . scheme — https://ask.slashdot.org/story/01/01/05/0054230/version-numb... Example from 1997: > Python versions are numbered A.B.C or A.B. A is the major version number -- it is only incremented for majo…
There's also Windows with it's A.B.C.D or major.minor.patch.build version scheme. Not sure how far back that goes, but it clearly predates semver as well.
Re: Migrating Facebook to MySQL 8.0
#300> First, we could not upgrade servers in place and needed to use logical dump and restore to build a new server. However, for very large mysqld instances, this can take many days on a live production server and this fragile process will likely be interrupted before it can complete.
This part is quite interesting. I'd think it will take maybe a day to dump/restore a database with a single 10TB table with no parallelism, at a speed of about 120MB/s. How big is these mysqld instances such that the process will take many days?