F29 Self Contained Change: MySQL 8

[Jan Kurik]

= Proposed Self Contained Change: MySQL 8 =
https://fedoraproject.org/wiki/Changes/MySQL_8


Owner(s):
  * Michal Schorm <mschorm at redhat dot com>


Update of MySQL ( community-mysql package) in Fedora from 5.7  to 8.0 version.



== Detailed description ==
Update of MySQL package in Fedora from 5.7 version to 8.0 version.


== Scope ==
* Proposal owners:
**Release MySQL 8.0.11 to Rawhide (done)
**Check software that requires community-mysql package (done, only
mysql-connector-odbc)
**Gather user input on the changes between mysql 5.7 and 8.0

* Other developers: N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7486

** List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Stephen Gallagher]

On Mon, May 7, 2018 at 7:04 AM Jan Kurik <jkurik(a)redhat.com&gt; wrote:

>  = Proposed Self Contained Change: MySQL 8 =
>  https://fedoraproject.org/wiki/Changes/MySQL_8
>
>
>  Owner(s):
>    * Michal Schorm <mschorm at redhat dot com
> >  
>
>  Update of MySQL ( community-mysql package) in Fedora from 5.7  to 8.0
>  version.
>
>
>
>  == Detailed description ==
>  Update of MySQL package in Fedora from 5.7 version to 8.0 version.
>
>
>  == Scope ==
>  * Proposal owners:
>  **Release MySQL 8.0.11 to Rawhide (done)
>  **Check software that requires community-mysql package (done, only
>  mysql-connector-odbc)
>  **Gather user input on the changes between mysql 5.7 and 8.0
>
>  * Other developers: N/A (not a System Wide Change)
>
>  * Release engineering:
>  https://pagure.io/releng/issue/7486
>
>  ** List of deliverables: N/A (not a System Wide Change)
>
>  * Policies and guidelines: N/A (not a System Wide Change)
>
>  * Trademark approval: N/A (not needed for this Change) 


I remember when MariaDB was first released, it and MySQL were compatible
replacements for one another and this assumption was baked into plenty of
other packages. Is this still true, and if not are there plans to
coordinate with other packages to update things like client connector
dependencies?

>

[Tomasz Kłoczko]

On 7 May 2018 at 12:03, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
[..]
>  Update of MySQL ( community-mysql package) in Fedora from 5.7  to 8.0
> version. 
1) After regular upgrade mysql server is completely not usable because
nothing is performing upgrade procedure by execute mysql_upgrade. No
warning, nothing is displayed to anyone who will be doing regular
upgrade .. just silent trashing.

2) If mysqll_upgrade command will be executed during 5.7 -> 8.0
package upgrade binary format will be changed and downgrade will be
not possible. Just in case if it is not obvious: I'm not proposing to
add this command to mysql post installation

3) 8.0.11 is just first 8.0 releases and jumping from very stable
5.7.x to deeply changed 8.0 is horrible idea

4) I already found that this upgrade breaks zabbix because in zabbix
db schema are used "group" and "function" which are in 8.0 part of
the
SQL keywords. Any other MySQL client code which will be using such
keywords in tables ot tables rows names will be instantly decapitated.
Shame that you did not mention that we already discussed this issue in
https://bugzilla.redhat.com/show_bug.cgi?id=1573642 zabbix only in 4.0
(probably) wil have MySQL 8.0 support and Alexey Vladyshew already
made decision that MySQL 8.0 support will be not backported to any 3.x
(https://support.zabbix.com/browse/ZBX-12451)

5) On top of group/function keywords clash definitely any other
software which will be querying performance_schema, global_status or
global_variables tables will be broken by this upgrade as well.
Probably 100% monitoring software which is using MySQL client API

6) In our IRC conversation on #zabbix you told me that working on
5.7->8.0 upgrade you've not done even single test build of any other
Fedora package trying to recompile it against MySQL 8.0 client API.
I've already told you that I found at least one package which fails
during such test build. It is zabbix and quick patch for this issue is
in ticket https://support.zabbix.com/browse/ZBX-14311. Looking on list
of changes in 8.0 I'm 100% sure that list of the client software will
be way longer.

7) Ad1) and Ad2): In the same few days ago public conversation on
#zabbix IRC channel you already told me that you never tested 5.7->8.0
upgrade (.. which is kind of odd that you are packaging software which
you are not testing/using)

8) After what you've done there is no anymore MySQL 5.7 packages in rawhide

IMO all those traps and holes is possible to avoid by leaving 5.7 on
community-mysql package and create completely new one
community-mysql80.
If you are not interested to maintain 5.7 line just split 5.7 and 8.0
and assign 5.7 line package to me (just assign 5.7 git repo line to
"kloczek")

kloczek
-- 
Tomasz Kłoczko  | LinkedIn: http://lnkd.in/FXPWxH

[Tomasz Kłoczko]

On 7 May 2018 at 12:48, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
[..]
>  I remember when MariaDB was first released, it and MySQL were
> compatible
>  replacements for one another and this assumption was baked into plenty of
>  other packages. Is this still true, and if not are there plans to coordinate
>  with other packages to update things like client connector dependencies? 
During 8.0 development cycle none of the client protocol changes has been made.
You can use for example ODBC connector compiled on top of 5.7 header
files land linked with 5.7 or MariaDB client libraries with MySQL 8.0
server and it will be no problem as long as for example you database
scheme stored in MySQL engine will be not using for example group or
function keywords in names of tables or rows.

In other words: from ABI point of view nothing needs to be coordinated here.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Michal Schorm]

>  I remember when MariaDB was first released, it and MySQL were compatible
>  replacements for one another and this assumption was baked into plenty of
>  other packages. Is this still true, and if not are there plans to
>  coordinate with other packages to update things like client connector
>  dependencies?
>  
As can be found here:
https://mariadb.com/kb/en/library/what-is-the-goal-of-mariadb/
MariaDB is not a drop-in replacement for MySQL anymore. They are "on the
user level, broadly compatible".

From devel POV it means, you has to choose, agains which you will compile
your software.
From user POV it means, you shouldn't easily cross a functionality which
differ, but they are there.
From upstream POV it means, they ususaly has to write their code in such a
way, it will compile fine with both. (That mostly meant stop using symbols
out of specification and stop using hardcoded paths)

MariaDB has now both connector C and ODBC in Fedora, which should be used
with it, rather than mysql-connector-odbc. On the other hand,
mysql-connector-odbc was changed to build back against MySQL (instead of
MariaDB)

Nowadays, all of the (applicable) software in F27+ is being compiled
against MariaDB.
I still try to support installing client X server packages one from MariaDB
and other from MySQL, as well as using connectors vice versa. (That's one
thing a Fedora CI will help me greatly in the future)

Did I answered your question?
If not, try it retry with "--verbose", please :)

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

[Josh Boyer]

On Mon, May 7, 2018 at 7:52 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
wrote:
>  IMO all those traps and holes is possible to avoid by leaving 5.7 on
>  community-mysql package and create completely new one
>  community-mysql80.
>  If you are not interested to maintain 5.7 line just split 5.7 and 8.0
>  and assign 5.7 line package to me (just assign 5.7 git repo line to
>  "kloczek") 
Or a mysql module stream for 8 could be introduced.  This kind of thing
fits nicely in the area modularity is trying to address.

josh