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!

 

[Hangover2]

@Alex Presland In our case, the issue also occurs when the database name contains a '-' symbol and the table is of type MyISAM. As a workaround - if possible, switching to InnoDB already resolves the startup hiccup, since MariaDB has not patched the issue yet.

 

[wakabayashi]

Is this option no more available or am I not getting the point?

My Goal: updating from MariaDB 10.11.11 to MariaDB 11.4.5.

I have set the canBeUpgraded value to true. But I don't have any upgrade button:



Plesk ObsidianVersion 18.0.69

 

[Sebahat.hadzhi]

@wakabayashi , upgrades to MariaDB 11.4 are not yet supported through the auto-upgrade tool. The option hasn't been implemented yet as MariaDB 10.11 is a long-term support version, which will be maintained until 2028. Our team will introduce the option in the future, but I cannot provide any ETA yet.

 

[wakabayashi]

@Sebahat.hadzhi ah, I see. No problem then. I will wait

 

[valwello]

Hello there!

I'm on Plesk Obsidan 10.8.70 upd2 - CentOs 7.9.2009
My MariaDB version is 10.11.9, and would update to the latest long term supported version (10.11.11).

The problem:
- no "UPGRADE NOW" button in Tools & Settings / Database Servers panel (features.canBeUpgraded = true)
- get repository error (as this didn't exist anymore) on terminal > yum check-update
https://dlm.mariadb.com/repo/mariadb-server/10.11/yum/rhel/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.

The question:
what should I do to update my database to version 10.11.11?

Thank you in advance!
V

 

[Sebahat.hadzhi]

@valwello , the Plesk upgrade tool would typically update MariaDB to the latest supported version. I believe, 10.11.11 is not present in the official MariaDB yum repository for CentOS 7.9. I would suggest considering an upgrade to another OS.

 

[trialotto]

@valwello , the Plesk upgrade tool would typically update MariaDB to the latest supported version. I believe, 10.11.11 is not present in the official MariaDB yum repository for CentOS 7.9. I would suggest considering an upgrade to another OS.

@Sebahat.hadzhi

Are there known issues for upgrades of installations with custom config?

How are they dealt with in the process? Are backups of (custom) config files made?

I am curious .........

Kind regards....

 

[Sebahat.hadzhi]

@trialotto , I am not quite sure I was able to understand the question. Sorry. Are you asking in reference to the automatic MariaDB Upgrade tool? If yes, can you please confirm which custom config files are you referring to?

 

[trialotto]

@trialotto , I am not quite sure I was able to understand the question. Sorry. Are you asking in reference to the automatic MariaDB Upgrade tool? If yes, can you please confirm which custom config files are you referring to?

@Sebahat.hadzhi

I am asking in reference to the MariaDB Upgrade tool.

There is no specific set of custom config files that I am referring to, since it is a general question.

However, I can state the following.

In many test scenario's, I use two types of customizations :

1 - inline adjustments / additions of default config files : this method is chosen, if and only if custom config files do not override the custom settings properly

2 - custom config files with some "individual" lines : this method often works, but not always.


The question can hence be asked differently and as follows :

a) does the upgrade tool overwrite the default config files (for instance, if the upgrade changes some defaults in the default config files)?

b) does the upgrade tool overwrite inline adjustments / additions in default config files?

c) does the upgrade tool preserve custom config files?


As a final remark, it has to be duly noted that I am asking, since specific upgrades of database servers will make specific config variables (whether used as a custom or a default config variable) change or even change.

In the latter case, the upgrade tool is just as good as it will deal with the config variables that need to be changed with the upgrade.

For instance, if a specific variable becomes obsolote / is renamed / is changed, then the upgrade tool might fail if that specific variable is not "translated" into a variable that is required for the new version of the database server.

Stated differently, introducing the upgrade tool in Plesk without a method of checking for and replacement of "changed variables" will be not a good idea.

The question about custom config (in default or custom config files) is a first question that can help determining when the upgrade tool is ready for release.


All things considered, the upgrade tool is a VERY good idea !

Nevertheless, there are some reasons to give some good thought to introductng an upgrade tool, since those databases are the backbone of Plesk.


Kind regards.....

 

[VNick]

a) does the upgrade tool overwrite the default config files (for instance, if the upgrade changes some defaults in the default config files)?

We may modify default config files (such as /etc/my.cnf or /etc/mysql/my.cnf), but we don't overwrite them entirely.

b) does the upgrade tool overwrite inline adjustments / additions in default config files?

Yes, in case these changes would prevent the new version of DB server from startup and normal operation.

c) does the upgrade tool preserve custom config files?

In case we remove some directives, we backup the corresponding configuration files with .bak* extension.

General logic is as follows:

1. adapt bind_address directive if needed (this is unconditional);
2. remove directives that are not present anymore or have invalid values for the target DB server version (we warn the admin about it and backup corresponding configs).

That's basically it. So if anything of value is "lost" during the upgrade (which is unlikely), admin should be able to easily restore it manually.

 

[trialotto]

We may modify default config files (such as /etc/my.cnf or /etc/mysql/my.cnf), but we don't overwrite them entirely.

Yes, in case these changes would prevent the new version of DB server from startup and normal operation.

In case we remove some directives, we backup the corresponding configuration files with .bak* extension.

General logic is as follows:

1. adapt bind_address directive if needed (this is unconditional);
2. remove directives that are not present anymore or have invalid values for the target DB server version (we warn the admin about it and backup corresponding configs).

That's basically it. So if anything of value is "lost" during the upgrade (which is unlikely), admin should be able to easily restore it manually.

@VNick,

That sounds excellent.

This also implies that Plesk has a "conversion template" containing "old-to-new-variable conversions" and "remove-deprecated-variable conversions".

Are those "templates" included in the packages?

The latter question might not seem really relevant, but it is!

The "templates" themselves are interesting : they - probably - give some options for

a - custom config after the db update (read: by adjusting the templates a bit before the db update)

b - config optimization (read: changing existing db instances to a more optimized form or updating existing db instances to a new optimal db instance)


The latter option (read: option b) is currently missing in Plesk's arsenal of tools .... but with the upgrade tool, this "optimization tool" should be feasible.

Or am I a bit mistaken?


Kind regards....

 

[VNick]

Are those "templates" included in the packages?

The logic is part of the MariaDB upgrade feature. We use the upstream MariaDB packages as is (we do not rebuild them).
So this is not something that is intended to be customizable by end users. They can just perform the necessary adjustments manually in any way they see fit, since the feature first warns about incompatibilities and offers a chance to stop and change configuration.

While your idea is interesting, it's not really something that constitutes the MariaDB upgrade feature or its part.

DB server configuration optimization is done to some extent in the Performance Booster extension, AFAIK. I believe it is installed by default with Plesk.

 

[trialotto]

The logic is part of the MariaDB upgrade feature. We use the upstream MariaDB packages as is (we do not rebuild them).
So this is not something that is intended to be customizable by end users. They can just perform the necessary adjustments manually in any way they see fit, since the feature first warns about incompatibilities and offers a chance to stop and change configuration.

While your idea is interesting, it's not really something that constitutes the MariaDB upgrade feature or its part.

DB server configuration optimization is done to some extent in the Performance Booster extension, AFAIK. I believe it is installed by default with Plesk.

@VNick,

The Performance Booster extension is a bit poor in the area of db optimization (and optimization in general).

The idea is indeed interesting and might need some (serious) tweaking in order to be able to function as an efficient db optimization tool.

However, it might be possible ........ and I might have some time to have a look into the matter ........ do you perhaps have and/or can you share the conversion templates that are used with the db upgrade tool?

Kind regards...