Re: Mysqld refuses to start after upgrade to Fedora 29

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Danny and everybody else,

MariaDB & MySQL maintainer here!
I see I made it late, however I'll drop here some more answers & tips:


> I don't know where else to ask.
This is a right place.
Other good places could be Fedora IRC, create bugzilla ticket
... or write me personal mail as a last resort :) (can be found in the
package changelog)


> I've just upgraded from Fedora 28 to Fedora 29 and mysqld (version 8.0.13) won't start.
Between F28 & F29 is a big update
MySQL 5.7.24 --> 8.0.13
MariaDB 10.2.19 --> 10.3.10


> Keep in mind that you're really running mariadb ...
DNF will resolve "mysql" to "mariadb"; the "community-mysql" is the
original MySQL.

You can check anytime what you have installed by
$ dnf list installed | grep -e "mysql" -e "mariadb"

In Fedora it is even possible to have server of one and client from
another, but consider it an experimental feature instead of
recommended setup.


> I don't want to mess around switching to MariaDB, do you think that will cause more problems if I do?
Depends. Shouldn't.
It is simmilar to normal database upgrade. For small applications, it
may be drop-in replacement, for huge applications, you'd need to fix
all incompatibilities and can be tricky.

Anyway I wouldn't recommend switching to the other database as an
attemp to fix issues with the previous.
If you feel you need different software, try downgrade to the previous version.
Or try Fedora Modules. (providing MySQL 5.7 on F29)


> "systemctl start mysqld"
This is the corrct form.
For compatibility reasons, the MariaDB can be started with the same
command, instead of its native:
$ systemctl start mariadb
So nothing to change here.


> SELinux
I keep an eye on both MariaDB & MySQL. Both must run without SELinux issues.
If there would be a problem, bugzilla ticket is the solution.
Can be worth checking, though. Errors are a human nature.


> Found another log file I didn't know existed!!
Standard setup are logs in "/var/log/mysqld/" and some usefull
messages in the systemd journal.


> Some of those are fixable via mysql_upgrade
After *every* upgrade, "mysql_upgrade" utility should be ran.
Recomended steps for in-place upgrade for MariaDB (for MySQL it would
be very simmilar):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html-single/configuring_and_deploying_different_types_of_servers/#mariadb-in-place-upgrade

There's:
ExecStartPost=@libexecdir@/mysql-check-upgrade
check in the service that should have been triggered automaticly, though.


Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--
On Tue, Dec 11, 2018 at 11:40 AM Danny Horne via users
<users@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 11/12/2018 12:37 am, Rick Stevens wrote:
> >
> > Yup. Some of those are fixable via mysql_upgrade, others are fairly
> > important and appear to be caused by using a newer mysqld that's not
> > backwards compatible with your previous version. You didn't say which
> > version of MySQL you were running before and whether 8.0.13 was
> > compatible with it. Generally, the website has info on what's compatible
> > and how to convert from old to new.
> >
>
> mysql_upgrade seems to have done the trick -
>
> 2018-12-11T10:35:31.114349Z 0 [System] [MY-010910] [Server]
> /usr/libexec/mysqld: Shutdown complete (mysqld 8.0.13)  Source distribution.
> 2018-12-11T10:35:31.627020Z 0 [System] [MY-010116] [Server]
> /usr/libexec/mysqld (mysqld 8.0.13) starting as process 7131
> 2018-12-11T10:35:33.197087Z 0 [Warning] [MY-010068] [Server] CA
> certificate ca.pem is self signed.
> 2018-12-11T10:35:33.217669Z 0 [System] [MY-010931] [Server]
> /usr/libexec/mysqld: ready for connections. Version: '8.0.13'  socket:
> '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution.
> 2018-12-11T10:35:33.343046Z 0 [System] [MY-011323] [Server] X Plugin
> ready for connections. Socket: '/var/lib/mysql/mysqlx.sock'
> bind-address: '::' port: 33060
>
> Thanks so much for your help Rick
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux