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.....