Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

Post reply on HN
Print view View original

201–210 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#201

Post by dijit »

evanelias wrote: post #199
dijit wrote: post #198

Earlier quoted context omitted.

That’s pretty scary, isn’t it?

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.

Re: Migrating Facebook to MySQL 8.0

#202

Post by evanelias »

dijit wrote: post #197
tapoxi wrote: post #116

Earlier quoted context omitted.

We also did a MySQL 5.7 to PG 9.6 migration (thanks to https://pgloader.io/ ) and we got some pretty immediate speed improvements (2-5x). We shot ourselves in the foot a few weeks later with some poorly written RLS policies, but it was overall a smooth experience.

pgloader is great. Sadly for me when I tried to make a PoC of Postgres for our eCommerce platform I found that we had violated our constraints and lost data. That was the day I went from MySQL agnostic to MySQL hating. It largely doesn’t matter that the defaults could be configured to be more strict. We live in a world where people are trying to avoid hiring sysadmin and that database was set up by a developer. It sh…

> It largely doesn’t matter that the defaults could be configured to be more strict. We live in a world where people are trying to avoid hiring sysadmin and that database was set up by a developer. It should not have been a default.

Everyone agrees with this. That's why they changed the default nearly 6 years ago.

Yes, the old default was terrible. But there's no way to change the past, so why complain about it for years and years?

All versions with this bad default have hit end-of-life, what more can be done?

Re: Migrating Facebook to MySQL 8.0

#204

Post by evanelias »

dijit wrote: post #201
evanelias wrote: post #199

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

In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast?

Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults?

You don't like MySQL, I get it. Regardless of reasons, I don't think your view will change, so why enter every HN thread about MySQL just to repetitively bash MySQL? What's the purpose of this?

Re: Migrating Facebook to MySQL 8.0

#205

Post by ipaddr »

paulddraper wrote: post #190
twic wrote: post #124

Earlier quoted context omitted.

> I absolutely adore Postgres's tweaks to the SQL language Do you mean additions to the SQL standard, or bits of the standard that MySQL doesn't implement, or something else? The reason i ask is that i also enjoy writing SQL for PostgreSQL, but as far as i know, i am sticking to standard SQL. Perhaps there are things i'm missing, or things i like which i haven't realised are nonstandard!

> as far as i know, i am sticking to standard SQL PostgreSQL documentation is very good about comparing each feature to the standard. For example, the SQL standard specifies that triggers fire in the historical order they are added to the table. PostgreSQL chose to fire them alphabetically. Technically nonconformant, but in practical terms, far better.

Why would alphabetically be better? Wouldn't you want first in first out?

Re: Migrating Facebook to MySQL 8.0

#206

Post by unethical_ban »

taywrobel wrote: post #129
fipar wrote: post #122

Earlier quoted context omitted.

There have been several minor releases in the past 3 years: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/

In semantic versioning parlance those would all be considered "patch" releases, not a "minor" release. The minor version segment in a semantic version is the 2nd number, so most people would consider the next "minor release" for MySQL to be 8.1.0. If following the guidance set out at https://semver.org , a patch release wouldn't add any new functionality, it would just address bugs in a backwards compatible way. A mi…

Sure, but you're assuming they follow that standard simply because they have x.y.z.

Re: Migrating Facebook to MySQL 8.0

#208

Post by dijit »

evanelias wrote: post #204
dijit wrote: post #201

Earlier quoted context omitted.

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.

In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast? Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults? You don't like MySQL, I get it. Regardless of reasons, I don't think y…

The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why.

The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that:

a) it wasn’t built with that in mind and thus was experimental.

b) was not enabled to ease adoption (this is kinda evil, in my personal opinion because it teaches bad habits)

c) was considered a power-user feature, which is ridiculous.

What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns, and people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”- which is absolutely not a good warning.

If you listen to my rambling about the pain I’ve seen, and you still want to use it: at least it’s an informed decision. But pretending that all is well is not ideal, it doesn’t lead anyone to make better software or practices (MySQL) or better developers (because they don’t see footguns before they’ve sprung some self-inflicted wounds on themselves)

Re: Migrating Facebook to MySQL 8.0

#209

Post by jolux »

ipaddr wrote: post #205
paulddraper wrote: post #190

Earlier quoted context omitted.

> as far as i know, i am sticking to standard SQL PostgreSQL documentation is very good about comparing each feature to the standard. For example, the SQL standard specifies that triggers fire in the historical order they are added to the table. PostgreSQL chose to fire them alphabetically. Technically nonconformant, but in practical terms, far better.

Why would alphabetically be better? Wouldn't you want first in first out?

It means that the order they fire is imperative and determined by how you run your migrations.
Post reply on HN