Bug 1573642
Summary: | Zabbix does not support MySQL 8 (yet) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tomasz Kłoczko <kloczko.tomasz> |
Component: | community-mysql | Assignee: | Michal Schorm <mschorm> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 29 | CC: | hhorak, jstanek, kloczko.tomasz, mschorm, volker27 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-09-05 14:40:47 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tomasz Kłoczko
2018-05-01 20:31:17 UTC
OK, this bugzilla will lie here for some time, so I'll add the zabbix maintainer to CC and try to summarize what I found out so far: https://support.zabbix.com/browse/ZBX-12451 zabbix 4.0 There is a open upstream issue tracker for the mysql 8 support, however romours are, the support will appear only in zaabix 4.0 (and later) versions. -- So far, Fedora 29 has Beta freeze set to "2018-08-28". by this time, I want to have the solution decided for sure. On the other hand, it is a good amount of time to be fixed by upstream and released to Fedora. It is already known that such support will be only for zabbix 4.0.x. Even if 4.0.0 will be released soon all olders still supported zabbix versions must be used with MySQL 5.7.x or older. It other words there is no now in Fedora MySQL server which could be used with any zabbix version. Looking on 8.0.x list of changes I'm 100% that it will be more MySQL code which could mod be used with MySQL 8.0.x. All those applications even if linked with MarianDB client libraries may be not working with only MySQL 8.0.x server. If you not interested to maintain MySQL 5.7 just let me know and I'll request create package like community-mysql57 and will continue provide necessary stable MySQL server platform for Fedora. IMO still 8.0.x is not ready yet to put it as regular upgrade from 5.7.22 straight to 8.0.11. I'll hold this repository with MySQL 5.7 built for Fedora Rawhide for now: https://copr.fedorainfracloud.org/coprs/mschorm/mysql-5.7/ So did you made any decision? Still there is no MySQL 5.7 for rawhide. Yes. I talked about it with my coleagues. I still does not see it as any kind of blocker for F29. I do not expect users to run the Rawhide machine unaware it may be broken. It does not affect *any* users of stable Fedora reeleases. Until the F29 beta freeze, the COPR repo should be sufficient. -- I did a self-contained change proposal for F29, so both rel-eng and users will be aware of it as much as they can be. https://fedoraproject.org/wiki/Changes/MySQL_8 At the time of F29 beta freeze, a MySQL 5.7 module will be available. -- A year back, I started a huge shift of packages to build against MariaDB rather than MySQL. Only a single package requiring MySQL remained now - its own ODBC connector. The compatibility, both ABI and API, between MariaDB and MySQL is still very high, but they aren't just drop-in replacements anymore, so no guarantee it can run both. -- If somebody want to get a software with simmilar issue running, he can either IMHO: * use the COPR repo I created * use the package from older Fedora * use the module, once it will be ready * rebuilt the package himself form older fedora (either mysql or the second software) * get the built packages from the upstream (either MySQL or the second software) * switch to MariaDB, because the software is built against it * rebuilt the package himself against community-mysql * ... so there are a lot of ways. I see that you don't see any problems with 5.7->8.0 upgrade. Problem only os that this ticket is not about what you don't see or you. Please try to focus on MySQL. MySQL server can work on remote host and nothing what is possible to do on host where is working client software can stop or prevent upgrade which you've proposed. Whoever will be doing community-mysql server package upgrade will be not aware that some of his/her applications working on other hosts may suddenly stop working. Tomasz, do I understand correctly, that what you're saying is that the rest of the world is not ready for MySQL 8.0 yet? If it is not only about Zabbix, do you know of any other program that is not fine with MySQL 8.0 yet? Really this is not about readiness. This is about cutting off use stable 5.7 version. I have no idea what is the current state because I've made very limited tests but seems I made much more than you, and you instead basing on raw facts or results of exact tests are going to make upgrade decision basing on what you are thinking. I showed you that at least one package is not ready and more WILL come. Doesn't matter what I'm saying or what you are thinking. I'm and the same you are not the part of this puzzle. Any decisions about provide MySQL 5.7.x for rawhide? The MySQL 5.7 module is ready to use in the Rawhide repository. This solution should't restrict the users to stick to 5.7 version while moving Fedora forward. As you done upgrade from 5.7 to 8.0 in community-mysql still all issues with not upgraded database format. Two months after seems you still even not been trying one time to test upgrade from 5.7 to 8.0. Tomasz, I tried upgrading from 5.7 to 8.0 on F28, and after upgrade I ran mysql_upgrade (which is a usual after each major upgrade for MySQL). It went smooth and I didn't see any issues. Can you, please, share what issues you see? This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'. No more required information supplied by the reporter. In general, it works fine. On Zabbix upstream side it's marked as resolved form "2018 Jun 18 11:59". The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |