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

[VNick]

The first is issue is only on Debian-based systems. Packages update may fail due to an incorrect attempt to start mariadb.service from package scripts with a configuration that is not up-to-date.

Since MariaDB developers didn't manage to properly fix this issue on their side, we've implemented a workaround on our side. It was just released with Plesk 18.0.63.4.

The second issue is only on systems with old kernel (presumably older than 3.10.0-408). It may also affect Docker installations. After upgrade the service cannot be started by SystemD with message "status=218/CAPABILITIES" as the new AmbientCapabilities specified in the unit file are not supported. To avoid this issue, make sure you're running the latest available kernel before the upgrade.

We've added an additional check for kernel version to avoid the issue since Plesk 18.0.61.4.

So, all in all, it should be safe to use the feature now, provided you use the latest available Plesk version.

 

[Alex Presland]

I successfully used the Plesk UI to upgrade from MariaDB v10.6.18 to v10.11.xx (currently 10.11.9, but that may have changed since the upgrade?). This is on a server running Ubuntu 22.04 and Plesk Obsidian 18.0.63 Update #4 Web Host Edition.

Ever since then every time that MariaDB is started / restarted, we get an email saying "WARNING: mariadb-check has found corrupt tables". However, these tables are NOT corrupt. There are two errors occurring here which are BOTH due to the table names not being escaped properly:

1. The use of a '-' symbol in the database table name which the script calling mariadb-check isn't escaping
2. The use of a space character in the database table name which the script calling mariadb-check isn't escaping

The two examples (also showing that they both work when the database and table names are escaped with a back-tick) are:

MariaDB [(none)]> select count(*) into @discard from mydatabase.mytable-dev;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-dev' at line 1
MariaDB [(none)]> select count(*) into @discard from `mydatabase`.`mytable-dev`;
Query OK, 1 row affected (0.000 sec)

MariaDB [(none)]>

and

MariaDB [(none)]> select count(*) into @discard from mydatabase.mytable name;
ERROR 1146 (42S02): Table 'beer_copy.id' doesn't exist
MariaDB [(none)]> select count(*) into @discard from `mydatabase`.`mytable name`;
Query OK, 1 row affected (0.001 sec)

MariaDB [(none)]>

I've found the line:
MYCHECK_SUBJECT="WARNING: mariadb-check has found corrupt tables"
in /etc/mysql/debian-start and this leads me to the command starting on line 36 of /usr/share/mysql/debian-start.inc.sh
However, in Blaming mariadb-columnstore-server/debian/additions/debian-start.inc.sh at master · mariadb-corporation/mariadb-columnstore-server the back-ticks are present but on my server the back ticks have been replaced with apostrophes.

@VNick are you able to review whether Plesk has modfied this source file from the original one that I've found in Github please, or point me to the distribution where you take your source from, so that I can fix it and submit a pull request? It is certainly different from line 23 onwards where "mysql" is replaced by "mariadb".

 

[VNick]

@VNick are you able to review whether Plesk has modfied this source file from the original one that I've found in Github please, or point me to the distribution where you take your source from, so that I can fix it and submit a pull request?

Sure. We actually use the upstream MariaDB packages for this feature. They are not modified in any way by Plesk (and Plesk doesn't interfere with mariadb-check on the service startup), so you should follow MariaDB Community Bug Reports and Feature Requests to report such bugs into the upstream.

 

[learning_curve]

@Alex Presland Relevant to your post:

I successfully used the Plesk UI to upgrade from MariaDB v10.6.18 to v10.11.xx (currently 10.11.9, but that may have changed since the upgrade?). This is on a server running Ubuntu 22.04 and Plesk Obsidian 18.0.63 Update #4 Web Host Edition.

On our Cloud Servers, we're also currently running Ubuntu 22.04 / Obsidian 18.0.63 #4 and Maria DB 10.11.9 with updates for Maria DB being achieved via /etc/apt/sources.list.d/mariadb.list together with MariaDB entries in /etc/apt/trusted.gpg.d and/or /etc/apt/keyrings So we do share some operational commonality. However, what we don't have (anywhere) is any of the errors that you've posted above and that you are now experiencing...

Can you post your current /usr/share/mysql/debian-start.inc.sh ? As that appears to be where you're identifying the source starts from. Just guessing / wondering if there's either a slightly different file content, possibly due to our slightly different upgrade path to Maria DB 10.11.9 (unlikely, but) and/or our different uses of ANSI_QUOTES SQL_MODE maybe?

FWIW Under Quote Character on THIS MariaDB page, back ticks, double quotes and ANSI_QUOTES SQL_MODE are covered although to be fair, that's referenced back to THIS MySQL page and again FWIW if/when you've reported this (as per post #63) what response have you received so far... Thx!

 

[Alex Presland]

FWIW if/when you've reported this (as per post #63) what response have you received so far... Thx!

See

[MDEV-34902] debian-start erroneously reports issues due to table names not being escaped properly - Jira

jira.mariadb.org

 

[learning_curve]

See

[MDEV-34902] debian-start erroneously reports issues due to table names not being escaped properly - Jira

jira.mariadb.org

Ahhhhh Yes. Relatively simple then in hindsight. Thx.
We're not effected as we don't have any MariaDB databases that have any of the 'offending' characters in their names, hence no escaping issues.

 

[Necroman]

Hi there! I have two servers running Plesk Obsidian 18.0.65 Update #2 on CentOS 7.9.2009.

I successfully updated one server from MariaDB 10.6 to 10.11.9, so i tried to update my second server but it's stuck on the step "Upgrading the structure of all tables", specifically in the psa.BlUpgrades table (the psa.BlUpgradeActions that is before is OK). From my previous update log from server one, i can see it's missing a lot of tables to be updated and the final step: Synchronizing system components

Sites and server seem to work fine, but i'm worried... I have a snapshot before the update.

What should i do?

Can i manually check or update the structure of the remaining tables?

Thanks!