Hacker News Reader

"The reason a vendor like Percona or a linux distro chooses to favor MySQL or MariaDB is mostly about that vendor's relationship"

Close. Percona is a consulting firm specializing in MySQL (expanding to other things). Percona's race horse is MySQL the actual company and actual maintainers. They view MariaDB as a type of competition against their friends at MySQL. Good luck spotting the differences between Maria vs Mysql. I have gathered that from the many SFMysql meetups I have attended. The Mysql guys would show off their newest feature that beats MariaDB.

Percona is amazing and without the pt-online-schema-change tool, I would probably be a bar tender. If you ever get in a bad database bind they are worth every penny.

Looking from the outside as a user and package maintainer, there is no "MySQL" company. There's just Oracle now. You can't even download MySQL's official Python driver (mysql-connector-python) from Pypi because Oracle legal is not comfortable with it. If you are looking to do business with MySQL over MariaDB, it means you are looking to get in with Oracle. Is that not accurate?

This is btw. changing very soon. All lawyers agreed and mysql-trunk for-profit will be back on pypi as soon as we fix a few a tiny technical issues (I lead the team working on Python and other things in MySQL)

That would be amazing because we've been asking for this for literally years.

Not only you ... :-/

> Percona is amazing and without the pt-online-schema-change tool, I would probably be a bar tender

Without the pt-online-schema-change, you would likely use gh-ost :-)

Product Manager for the MySQL server here.

w.r.t. tx_isolation:

In MySQL 8.0, it is called transaction_isolation which is the name used by configuration files. MySQL 5.7 supports both names, but now warns when using the old name.

Supporting old+new names is required to support distributed apps which may upgrade a shard at a time (i.e. you want your code to work on both MySQL 5.7 and 8.0). But there is a deprecation warning to let you know which version is preferred.

Calling it an incompatible change is perhaps a little strong. The idea behind the deprecation warning is to give you as much notice as possible.

> Calling it an incompatible change is perhaps a little strong.

Definitions of backwards incompatibility are either tautological or disingenuous (provided we talk about documented behavior).

The right way to do that change would have been to allow both names without warnings in a point/minor release (with the docs stating where the project is headed), add the depreciation warning with the next semver major one, and remove the old name on the next next semver major release.

That though is a really long lifecycle for a product that may have a six month qualification and burn-in periods for a production enterprise implementation . You’re basically saying a change of config file parameter should take a year-plus?

MySQL releases are 2-3 years. So it would be 4-6 years wait in this case :-)

Just so you know, that warning broke Openstack builds in CI which fail for warnings like these. Other users have reported it elsewhere and I have users begging me to release SQLAlchemy 1.1.15 so that it can fix "the bug" ASAP for them.

Unfortunately, "database suddenly emits a prominent, unconditional warning upon upgrade to 5.7.20" is a breaking change in many situations.

We are looking to add something to filter warnings in the future. Thx for the feedback.

Sorry for my unnecessarily harsh comment yesterday. A great course of action would be to put those deprecation warnings behind an opt-in flag. That would let curious people discover what they must change in order to migrate to future versions without breaking anything out of the box.

Mike, given all your experience, do you have a preferred relational db? I'm assuming the answer is "it depends" but I feel like, say, MySQL and Postgres are fairly indentical in terms of usecase.

I'm assuming you know pretty much every dark corner of the dbs you have engines for in sqla. It must be a little hard forever supporting strange breakages like your example above when it's a db you don't care for as much.

If I was doing brand new development somewhere I'm sure I'd use Postgresql, since from a developer point of view it's the most consistent and flexible. While for the last few years I've worked way more with MySQL / MariaDB and at the moment the MySQL side of things is a bit more familiar to me, I still appreciate PG's vastly superior query planner and index features. Certainly in the SQLAlchemy world when i want to see how a database does something "correctly", Postgresql is where you go to see the "correct" way to do something (such as, the correct answer for "SELECT NULL IN (SELECT 1 WHERE 1=0)" - the answer is false, not NULL, or when I had to convince MariaDB developers, who just added real CHECK constraints in 10.2, that I should be able to drop a column that has a single-column CHECK constraint on it without first dropping the constraint, PG serves as the canonical example for "yes this is supposed to work").

I'm personally a little annoyed at PG's efforts to turn SQL into half an OO programming language (see http://ledgersmbdev.blogspot.com/2012/08/postgresql-or-model... for examples), but for selfish reasons; features like these are meant as replacements for what you get from a tool like SQLAlchemy Core and the unusual syntaxes they have are also really hard to implement yet I continually get asked to implement more of them. These aren't reasons I wouldn't use Postgresql it's just this little cloud of "ugh" that hangs over me when I really have to dig into PG :).

It also makes me cringe a bit the way Postgresql spawns a child process on the server for every database connection still. MySQL has very cheap connections and that's still a pretty compelling reason to keep it in mind for some kinds of applications (applications called Openstack which eat up thousands of connections...).

In the closed source world, MS SQL Server has really been getting a lot easier to use and I'm very impressed at their linux version, I have it running in docker and it is 100% exactly the same as the windows version as far as SQL / client interaction. None of this "MySQL default casing conventions are OS-dependent" stuff (see https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sens... , and prepare to be amazed what hacky cruft still lives on within the MySQL ecosystem).

> I'm personally a little annoyed at PG's efforts to turn SQL into half an OO programming language (see http://ledgersmbdev.blogspot.com/2012/08/postgresql-or-model.... for examples)

I read that link and didn't get it - has anyone a fuller explanation or other links to recommend?

I guess this is one of the more interesting examples to look at:

    select * from inventory_item i where (i.cogs_account).control_code = '5500';

You're only referencing 1 table in the query (inventory_item), but then i.cogs_account runs a query on a related table.

It doesn't seem like a great idea to me. You can't really tell what's happening and there's a huge performance impact in doing it. The query planner is going to be a bit limited in what it can do.

The example following where you have a save procedure against a column is a bit baffling.

    SELECT (i.save).*
    FROM (SELECT (row(null, 3, 1, 2, 'TEST124', 
                'Inventory testing item 2', 1, 2, 
                true)::inventory_item).save) i;

Wow, I'd never seen that style of defining the relationships as computed columns inside a table before — it's somewhat....terrifying.

Think I'll stick to SQLA on that front thanks!

Forgive me for being blunt but I am sorry, can you please tell me who zzzeek is? Why does everyone know him but first name?

Click on his username to read his profile which includes a link to his website http://techspot.zzzeek.org

> I switch between multiple versions of MySQL and MariaDB all day long.

Mike, maybe I misundertood this, but I think they meant actually moving /var/lib/mysql between maria/mysql.

Oh you might be right about that. I'd be pretty nervous going in either direction on top of constant datafiles. Just mysqldump and be done with it.

My understanding is that MariaDB is using an updated replication format which is not readable by Oracle MySQL or the Percona fork of MySQL. So you could not maintain a MySQL slave of a MariaDB instance, and would have to take downtime to switch from MariaDB to MySQL.

(This is only be true if you're using GTIDs in MariaDB, the old file:position format is still compatible. MariaDB does understand MySQL GTIDs, so replication from MySQL to MariaDB does work when using GTIDs in MySQL.)

I stopped moving live files around in MySQL as a migration strategy decades ago. Why would you want to deal with anything but data?

There is definitely a difficulty in using dumpfiles if your database is 50G in size.

I pipe dumpfiles into pbzip2, which shrinks 1TB+ dumpfiles down to a very manageable 30-40GB. scp to the new host, import, start replication, and it's good.

The problem with this approach is often that the dump restore takes a week to complete.

Actually, from experience, you are wrong. If your database if 50G, chances are most of that is index space. So no, mysqldump has absolutely no problem dealing with database that size.

Use mydumper/myloader. I've had issues using mysqldump over 50g databases with three or four figure tables and has to write a script that dumps every table. To get a consistent snapshot you have to close all the client connections.

I think --single-transaction flag solves this.

We have 500GB to 900GB, redumping that is fun :-)

Are you sure that you actually installed mysql? A apt-get install mysql would install mariadb.

It could be pretty difficult to get and install mysql. I recall times where you needed to go to the Oracle website and check some EULA manually before you could get a temporary download link. Quite a stand against automation.

Your question is whether the person who maintains SQLAlchemy knows how to install mysql?

The forking war between mariadb and mysql does not mind who you are. It affects everyone.

Your parent's point is that zzzeek' is highly likely to understand the difference. He is the maintainer of https://www.sqlalchemy.org/

I think you are looking for apt-get install mysql-server

docker run mysql -d