6 ms·

who says MariaDB doesn't work with ProxySQL? Also, this statement is total BS: "The risk of moving to MariaDB Server if you aren’t using newer MySQL features

by zzzeek 9y ago

who says MariaDB doesn't work with ProxySQL? Also, this statement is total BS: "The risk of moving to MariaDB Server if you aren’t using newer MySQL features may be minimal, but the risk of moving out of MariaDB Server to MySQL is very prevalent." Here is the correct statement: "The risk of moving to MariaDB Server if you aren’t using newer MySQL features may be minimal, and the risk of moving to MySQL server if you aren't using newer MariaDB features is also minimal." I switch between multiple versions of MySQL and MariaDB all day long. If you aren't using specific things like MySQL's JSON type or NDB storage engine or expecting CHECK constraints to enforce on MySQL (oddly omitted from this feature comparison!), there is nothing different at all from a developer point of view, beyond the default values of flags which honestly change more between MySQL releases than anything else. As the maintainer of SQLAlchemy I think MySQL more often makes backwards-incompatible changes more often than MariaDB, such as just from 5.7.19 to 5.7.20 they decided to change the name of "@tx_isolation" to "@transaction_isolation" (and no, "@transaction_isolation" is not in 5.7.19, they just changed the name on a point release) and start emitting a prominent, scary warning when you use @tx_isolation that is breaking people's CI builds - on a point release. The reason a vendor like Percona or a linux distro chooses to favor MySQL or MariaDB is mostly about that vendor's relationship with Oracle (or lack thereof) more than anything else. I'm stuck using both all the time but the MariaDB community certainly feels more accessible than trying to get through to people working at Oracle.

user5994461 9y ago
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.
- deleted 9y ago
  [deleted]
- matthewowen 9y ago
  Your question is whether the person who maintains SQLAlchemy knows how to install mysql?
  - user5994461 9y ago
    The forking war between mariadb and mysql does not mind who you are. It affects everyone.
    - praneshp 9y ago
      Your parent's point is that zzzeek' is highly likely to understand the difference. He is the maintainer of https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
- wolco 9y ago
  I think you are looking for apt-get install mysql-server
- orf 9y ago
  docker run mysql -d
aidos 9y ago
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.
- zzzeek 9y ago
  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-modelling-part-2-intro-to.html 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-sensitivity.html 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).
ergo14 9y ago
> 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.
- zzzeek 9y ago
  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.
  - VintageCool 9y ago
    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.)
- jack9 9y ago
  I stopped moving live files around in MySQL as a migration strategy decades ago. Why would you want to deal with anything but data?
  - zzzeek 9y ago
    There is definitely a difficulty in using dumpfiles if your database is 50G in size.
    - beiller 9y ago
      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.
    - 9y ago
ransom1538 9y ago
"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.
- zzzeek 9y ago
  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?
  - johannes1234321 9y ago
    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)
    - zzzeek 9y ago
      That would be amazing because we've been asking for this for literally years.
      - johannes1234321 9y ago
        Not only you ... :-/
- pizza234 9y ago
morgo 9y ago
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.
- pygy_ 9y ago
  > 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.
  - mattzito 9y ago
    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?
    - morgo 9y ago
      MySQL releases are 2-3 years. So it would be 4-6 years wait in this case :-)
- zzzeek 9y ago
  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.

by zzzeek 9y ago

user5994461 9y ago

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.

deleted 9y ago
[deleted]
matthewowen 9y ago
Your question is whether the person who maintains SQLAlchemy knows how to install mysql?
- user5994461 9y ago
  The forking war between mariadb and mysql does not mind who you are. It affects everyone.
  - praneshp 9y ago
    Your parent's point is that zzzeek' is highly likely to understand the difference. He is the maintainer of https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
wolco 9y ago
I think you are looking for apt-get install mysql-server
orf 9y ago
docker run mysql -d

aidos 9y ago

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.

zzzeek 9y ago
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-modelling-part-2-intro-to.html 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-sensitivity.html 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).

ergo14 9y ago

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

zzzeek 9y ago
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.
- VintageCool 9y ago
  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.)
jack9 9y ago
I stopped moving live files around in MySQL as a migration strategy decades ago. Why would you want to deal with anything but data?
- zzzeek 9y ago
  There is definitely a difficulty in using dumpfiles if your database is 50G in size.
  - beiller 9y ago
    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.
  - 9y ago

ransom1538 9y ago

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

zzzeek 9y ago
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?
- johannes1234321 9y ago
  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)
  - zzzeek 9y ago
    That would be amazing because we've been asking for this for literally years.
    - johannes1234321 9y ago
      Not only you ... :-/
pizza234 9y ago

morgo 9y ago

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.

pygy_ 9y ago
> 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.
- mattzito 9y ago
  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?
  - morgo 9y ago
    MySQL releases are 2-3 years. So it would be 4-6 years wait in this case :-)
zzzeek 9y ago
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.