• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Try our new tool to upgrade your old MariaDB server from Plesk UI

Unfortunately, I receive the following error message in the 3rd step of the wizard:

"Pre-upgrade checks
Analyzing databases with mysqlcheck"

Restarting MySQL server...
Running mysqlcheck...
/usr/bin/mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... MEDIUM'
The command exit code: 2
 
In this url (https://support.plesk.com/hc/en-us/...MariaDB-5-5-to-10-x-on-Linux-?page=2#comments) I see this:

I ran into the "A manual upgrade is required." issue too, going from MariaDB 10.6 to 10.11.


This helped me:


MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysqldump -u admin --verbose --all-databases --routines --triggers > /tmp/all-databases.sql
systemctl stop mariadb
cp -v -a /var/lib/mysql/ /var/lib/mysql_backup
rpm -q --whatprovides mysql-server
rpm -e --nodeps `rpm -q --whatprovides mysql-server`


This removes the old MariaDB without removing dependencies and then the upgrade succeeds.


@Plesk support: this should be added to the manual. Currently it isn't correct.


P.S. I'm on Almalinux 8.

It is safe to run these commands (rpm -q --whatprovides mysql-server and rpm -e --nodeps `rpm -q --whatprovides mysql-server`), is this the solution to my problem?
 
I managed to solve the update problem today, the problem was in yum that was with the client and server blocked, I completed the update to 10.5 finally.

I think my previous manager locked the yum repository via command to prevent problems when he upgraded to 10.6 and had to go back to 10.4 to fix.

This command solve the problem: yum versionlock clear

Now I have the option to upgrade to 10.11, but I think I'll wait a few days or longer, for now I'm on 10.5.

Thanks for all your help!
 
/usr/bin/mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... MEDIUM'
I saw such error messages on older OSes when there are issues with certain DB table files (basically corrupted).
Check the MariaDB logs (e.g. /var/log/mariadb/mariadb.log). You'll probably see something like:
Code:
Version: '5.5.68-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
InnoDB: Error: the size of single-table tablespace file ./testdb/test1.ibd
InnoDB: is only 0 0, should be at least 65536!
240205  9:52:23  InnoDB: Assertion failure in thread 140165186688768 in file fil0fil.c line 766
InnoDB: Failing assertion: 0
In this case testdb.test1 table is corrupted. Try restoring these tables from a backup. If you don't have one or this doesn't help, data would probably be lost and something else should be done (depending on the specific error message).
 
I have a rather stupid, but simple question.

On alma 8, the upgrade says:

"Upgrade your local MariaDB database server to the current long-term support (LTS) version."

And then i get the option to go to 10.5 or 10.11

But, according to MariaDB Server Releases the LTS versions are 10.6 and 10.11

10.5 is not long term and is only about a year (and a bit) in the future.

Alma 8 has 10.3 build in, is there a technical reason why not go from 10.3 to 10.6 ?

If i upgrade manual to 10.6 directly from 10.3, will this work? or should i go to 10.5 first? We have several servers that have databases of more then 30 GB so we need to plan then table upgrade at a quiet moment

regards
Jan
 
I saw such error messages on older OSes when there are issues with certain DB table files (basically corrupted).
Check the MariaDB logs (e.g. /var/log/mariadb/mariadb.log). You'll probably see something like:
Code:
Version: '5.5.68-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
InnoDB: Error: the size of single-table tablespace file ./testdb/test1.ibd
InnoDB: is only 0 0, should be at least 65536!
240205  9:52:23  InnoDB: Assertion failure in thread 140165186688768 in file fil0fil.c line 766
InnoDB: Failing assertion: 0
In this case testdb.test1 table is corrupted. Try restoring these tables from a backup. If you don't have one or this doesn't help, data would probably be lost and something else should be done (depending on the specific error message).
Thank you very much for your answer. I took up your suggestion and first removed all unnecessary databases. There was actually an older one with a corrupt index. After that the upgrade worked without any problems.
 
When updating 10.3 to 10.11 on alma 8 the update tool doesn't remove

mariadb-gssapi-server

I started to test the script on 10.11.6 and this week the update to 10.11.7 failed due to a dependency for mariadb-gssapi-server. After removing mariadb-gssapi-server manually the update from 10.11.6 to 10.11.7 worked fine.

In the plesk support article for alma 8 and alma 9, the removal of mariadb-gssapi-server is a step.

3. Remove additional package conflicting with 10.4 version:
yum remove mariadb-gssapi-server


regards
Jan
 
Trying this as a test on a non production server outside our normal installation environment and this was displayed on the first update screen. This particular server was a clean Plesk in stall several years ago and has been updated via automatic updates since its inception. If I recall correctly a manual upgrade to mariadb was done several years ago to get to 10.6.

The message:

Only MariaDB forks shipped by OS vendors or the MariaDB vendor can be upgraded.

The environment:

Ubuntu 22.04.3 LTS, Plesk 18.0.58 Update 2, Mariadb 10.6.17
 
When updating 10.3 to 10.11 on alma 8 the update tool doesn't remove

mariadb-gssapi-server

I started to test the script on 10.11.6 and this week the update to 10.11.7 failed due to a dependency for mariadb-gssapi-server. After removing mariadb-gssapi-server manually the update from 10.11.6 to 10.11.7 worked fine.

In the plesk support article for alma 8 and alma 9, the removal of mariadb-gssapi-server is a step.

3. Remove additional package conflicting with 10.4 version:
yum remove mariadb-gssapi-server


regards
Jan
Hi, here is a question, do you use this. package 'mariadb-gssapi-server' and was it safe for you to remove it? Any application that depends on this package?
Or it was just installed earlier as a part of some bundle install?
 
Hi, here is a question, do you use this. package 'mariadb-gssapi-server' and was it safe for you to remove it? Any application that depends on this package?
Or it was just installed earlier as a part of some bundle install?


I don't understand the question. It was installed at the installation of almalinux 8 as part of the rhel (alma) mariadb packages. No idea if it is used, i don't think so.

It gave a dependency error when updating from 10.11.6 to 10.11.7 AND at your own page (see link above) it says that this package must be removed when updating mariadb from the rhel (alma) one to the one from the mariadb repositry.

mariadbgssapiserver.jpg

regards
Jan
 
I don't understand the question. It was installed at the installation of almalinux 8 as part of the rhel (alma) mariadb packages. No idea if it is used, i don't think so.

It gave a dependency error when updating from 10.11.6 to 10.11.7 AND at your own page (see link above) it says that this package must be removed when updating mariadb from the rhel (alma) one to the one from the mariadb repositry.

View attachment 25540

regards
Jan
Got it, thanks for the clarification, that in your case this package was just part of installation and not currently in use.
 
Hi to all

I started to work in this update and I have an error in first step:

The message:

Only MariaDB forks shipped by OS vendors or the MariaDB vendor can be upgraded.

The environment:

Ubuntu 20.04.6 LTS, Plesk 18.0.58 Update 2, Mariadb 10.4.33

Any idea?
 
Hi to all

I started to work in this update and I have an error in first step:

The message:

Only MariaDB forks shipped by OS vendors or the MariaDB vendor can be upgraded.

The environment:

Ubuntu 20.04.6 LTS, Plesk 18.0.58 Update 2, Mariadb 10.4.33

Any idea?
Ubuntu 20.04 LTS shipped with MariaDB 10.3. This is what I have, and I'm planning to use this tool to jump to MariaDB 10.5 soon.
 
Only MariaDB forks shipped by OS vendors or the MariaDB vendor can be upgraded.
MariaDB developers may have changed their maintainer identification. Could you execute the following commands and paste the output here? This will help identify the root cause.

Bash:
for f in /usr/bin/mysql /usr/sbin/mysqld; do dpkg-query -W -f '${Maintainer}' "`dpkg -S "$f" | cut -d: -f1`"; echo; done
apt-cache policy mariadb-server mysql-server
 
Hi all,

I'm very happy to report I used the new tool to upgrade MariaDB 10.3.x to 10.5.24 (Ubuntu 20.04.6 LTS). I have no plans or need to upgrade anytime soon, but after popping back into the Upgrade tool, I see the message enclosed.

Only MariaDB forks shipped by OS vendors or the MariaDB vendor can be upgraded.
 

Attachments

  • MariaDB Upgrade.png
    MariaDB Upgrade.png
    157.5 KB · Views: 14
MariaDB developers may have changed their maintainer identification. Could you execute the following commands and paste the output here? This will help identify the root cause.

Bash:
for f in /usr/bin/mysql /usr/sbin/mysqld; do dpkg-query -W -f '${Maintainer}' "`dpkg -S "$f" | cut -d: -f1`"; echo; done
apt-cache policy mariadb-server mysql-server
#:/home/adminsystem# for f in /usr/bin/mysql /usr/sbin/mysqld; do dpkg-query -W -f '${Maintainer}' "`dpkg -S "$f" | cut -d: -f1`"; echo; done
MariaDB Developers <[email protected]>
MariaDB Developers <[email protected]>
#:/home/adminsystem# apt-cache policy mariadb-server mysql-server
mariadb-server:
Installed: 1:10.4.33+maria~ubu2004
Candidate: 1:10.4.33+maria~ubu2004
Version table:

*** 1:10.4.33+maria~ubu2004 500
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main arm64 Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main ppc64el Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
1:10.4.32+maria~ubu2004 500
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main arm64 Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main ppc64el Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main amd64 Packages
1:10.4.31+maria~ubu2004 500
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main arm64 Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main ppc64el Packages
500 Index of /pub/mariadb/repo/10.4/ubuntu focal/main amd64 Packages
1:10.3.39-0ubuntu0.20.04.2 500
500 Index of /ubuntu focal-updates/universe amd64 Packages
500 Index of /ubuntu focal-updates/universe i386 Packages
500 Index of /ubuntu focal-security/universe amd64 Packages
500 Index of /ubuntu focal-security/universe i386 Packages
1:10.3.22-1ubuntu1 500
500 Index of /ubuntu focal/universe amd64 Packages
500 Index of /ubuntu focal/universe i386 Packages
mysql-server:
Installed: (none)
Candidate: 8.0.36-0ubuntu0.20.04.1
Version table:
8.0.36-0ubuntu0.20.04.1 500
500 Index of /ubuntu focal-updates/main amd64 Packages
500 Index of /ubuntu focal-updates/main i386 Packages
500 Index of /ubuntu focal-security/main amd64 Packages
500 Index of /ubuntu focal-security/main i386 Packages
8.0.19-0ubuntu5 500
500 Index of /ubuntu focal/main amd64 Packages
500 Index of /ubuntu focal/main i386 Packages
 
The GUI tool failed two installs on AlmaLinux 9.3 with the local gpgkey path not found errors; ended up using the manual upgrade approach which pulls it from MariaDB and worked like a charm:

Code:
[mariadb]
name = MariaDB
baseurl = https://dlm.mariadb.com/repo/mariadb-server/10.11/yum/rhel/9/x86_64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
priority=1
module_hotfixes=1
 
Back
Top