Errors on fresh DA install with mariadb

As long as nothing else leaks...

But if stopping mysql wasn't the problem maybe CB should stop allowing to upgrade MySQL to MariaDB?
 
Nah, that's not a good idea imho. People like to change and it should be possible to migrate to MariaDB.
 
Sure but if it results in corrupted tables it might be better to only offer fresh MariaDB installs where you import your backed-up databases afterwards.
 
For us that is true, but there are still people who want to stay with Mysql. And maybe change there mind later....
Or maybe create a more foolproof solution so there will not be corrupted tables anymore. Like you said earlier, dump all, install Mariadb, import all.
However I think it's already working this way so i don't know where the errors come from then.
 
There are a couple different sections about the conversion to MariaDB in that General MariaDB and MySQL docs page:

1. How to upgrade MySQL / MariaDB with CustomBuild 2.0
This one is documents the drop-in replacement and upgrade path which doesn't do a dump all, remove everything and build a clean MariaDB but just tries a drop-in replacement with the same files MySQL was using just running mysql_upgrade afterwards. It specifically lists this upgrade path: MySQL 5.5 > MariaDB 5.5 > MariaDB 10.0 > MariaDB 10.1 > MariaDB 10.2 > MariaDB 10.3. Nowadays though MySQL 5.7 is installed by default so I did the MySQL 5.7 > MariaDB 10.2 as suggested in the table.

2. Converting from MySQL 5.5 to MariaDB 5.5
This seems to do something similar but is written for CentOS specifically, adding a step of removing the system supplied MySQL?

3. How to reinstall mysql
This only mentions how to do a clean install, nothing about restoring the databases in there.

So all in all nothing that actually works for current fresh Debian installs at the moment, haven't tested this on anything else. That's why I think that documentation page should be updated to at least tell everybody a MySQL > MariaDB conversion is not going to work anymore unless you do a clean install of MariaDB.
 
This one is documents the drop-in replacement and upgrade path which doesn't do a dump all,
Yes it does:
./build set mysql_backup yes
is stated in the description and..
If you have mysql_backup=yes set set in options.conf file then a full raw sql backup will be run prior to the upgrade.
However, it looks confusing, I would only use this to upgrade mysqsl -or- mariadb, not convert from mysql to mariadb.
I would certainly not use this procedure do to a conversion. If it indeed should not be used, then it would be wise if it would be mentioned specifically.

The title converting is at option 2.
adding a step of removing the system supplied MySQL?
No a lot more. Like also creating a better backup and taking care that mysql is stopped the correct way that DA won't start it automatically again. Also a backup of /var/lib/mysql is mentioned. I don't see that this would be only for Centos as also Debian/FreeBSD is mentioned.
This would be the correct conversion procedure.

3.) Yes the title says it all. Reinstall not convert.

to at least tell everybody a MySQL > MariaDB conversion is not going to work anymore unless you do a clean install of MariaDB.
Oke, but how does anybody running MySQL gets a part MariaDB? This can only appear if a conversion went wrong, and then you have a problem anyway. So I don't understand this one completely.
 
Personally i find wrong conversions or updates.
There should be a more safe proces then only own backups

So kind of extra copy / backup and reverse possibility before doing this, then after testing and all is ok, the possible delete from those.

Such also build in install procedure where things go wrong.

You can test upfront but you can't test all from all as SERVER ADMIN, other software devs...
Backups and restore yes you can, and backups should be there.
But still more easy (semi- automatic ) procedures could help here, and is way more friendly.

OYEA updates if info's about some important precautions should be also easier to find here in support Forum, help. ( and howto's about solving such if doing wrong)
And in Custombuild under the I (info ?) where some are but not enough or am i wrong here?

To have a better Customer experience for DA ofcourse. ;)

Yes one is Server Admin, but there are Server Admin who need / want a CP to get things done for them as easy as possible, else wherefore is a CP?
Command line and such ok ofcourse, but why if you can solve in CP and build such in the CP, example for updates going wrong or conversions i think some more could be done or? ( extra safe backup parts and scripts to solve most common also the help / info with the basic changes and precautions for software update / conversion under that one CP is very handy and friendly)

Lets say for future build in some and more AI, and make whith that AI kind of as "MANAGED" DA ? :love:
 
Last edited:
No a lot more. Like also creating a better backup and taking care that mysql is stopped the correct way that DA won't start it automatically again. Also a backup of /var/lib/mysql is mentioned. I don't see that this would be only for Centos as also Debian/FreeBSD is mentioned.
This would be the correct conversion procedure.
That section also mentions RPM so that's a bit difficult in Debian. Anyway if this is the only correct conversion procedure it should be made clear in the docs that the How to upgrade MySQL / MariaDB with CustomBuild 2.0 section isn't the correct conversion procedure as this isn't obvious at all now because they have that "Drop-in replacement and upgrade path is following:" stuff in that section as well.
 
Still getting these errors, was updating MariaDB 10.4.20 to 10.4.21:

Code:
mysqldump: Got error: 1356: "View 'sys.host_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them" when using LOCK TABLES
mysqldump: Couldn't execute 'SHOW FIELDS FROM `host_summary`': View 'sys.host_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `memory_by_host_by_current_bytes`': View 'sys.memory_by_host_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `memory_by_thread_by_current_bytes`': View 'sys.memory_by_thread_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `memory_by_user_by_current_bytes`': View 'sys.memory_by_user_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `memory_global_by_current_bytes`': View 'sys.memory_global_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `memory_global_total`': View 'sys.memory_global_total' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `metrics`': View 'sys.metrics' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `processlist`': View 'sys.processlist' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `ps_check_lost_instrumentation`': View 'sys.ps_check_lost_instrumentation' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `schema_table_lock_waits`': View 'sys.schema_table_lock_waits' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `session`': View 'sys.session' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `session_ssl_status`': View 'sys.session_ssl_status' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `user_summary`': View 'sys.user_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$host_summary`': View 'sys.x$host_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$memory_by_host_by_current_bytes`': View 'sys.x$memory_by_host_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$memory_by_thread_by_current_bytes`': View 'sys.x$memory_by_thread_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$memory_by_user_by_current_bytes`': View 'sys.x$memory_by_user_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$memory_global_by_current_bytes`': View 'sys.x$memory_global_by_current_bytes' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$memory_global_total`': View 'sys.x$memory_global_total' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$processlist`': View 'sys.x$processlist' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$schema_table_lock_waits`': View 'sys.x$schema_table_lock_waits' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$session`': View 'sys.x$session' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW FIELDS FROM `x$user_summary`': View 'sys.x$user_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)
mysqldump: Couldn't execute 'SHOW CREATE PROCEDURE `diagnostics`': Failed to load routine sys.diagnostics (internal code -6). For more details, run SHOW WARNINGS (1457)
mysqldump: Got error: 1356: "View 'sys.host_summary' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them" when using LOCK TABLES

From the, way better documentation-wise, Cpanel doc site: MySQL or MariaDB Upgrade:

  • Do not upgrade from MySQL 5.7 to MariaDB 10.2 or 10.3. Those versions of MariaDB do not contain the sys schema, which will cause check tablecalls to fail. If you do accidentally upgrade from MySQL 5.7 to MariaDB 10.2 or 10.3, you must manually remove that schema from your databases.

Compare that to the DirectAdmin documentation that actually seems to advise to upgrade MySQL 5.7 to MariaDB 10.2:

Drop-in replacement and upgrade path is following:

MySQL versionMariaDB version
5.55.5
5.610.0
5.710.2
8.0None

Maybe the DirectAdmin crew could show some love/spend some money on their documentation site? Will add it as an omission in the Knowledge Base - Errors or omissions thread hoping they'll start following that thread and fix documentation problems like these.

Fix seems to manually remove the sys table if you did upgrade MySQL 5.7 to MariaDB 10.2 like the DirectAdmin documentation advises you to do.
 
Last edited:
Fix seems to manually remove the sys table if you did upgrade MySQL 5.7 to MariaDB 10.2 like the DirectAdmin documentation advises you to do.
We had no issues upgrading from Mysql 5.7 to MariaDB 10.2 on the other servers. Maybe DA used already a fix in the update script? I don't know why it might have issues now.

Also it's not only DA stating that it can be done, but also MariaDB itself suggest to upgrade 5.7 to 10.2.

Within the same base version (for example MySQL 5.5 -> MariaDB 5.5, MySQL 5.6 -> MariaDB 10.0 and MySQL 5.7 -> MariaDB 10.2) you can in most cases just uninstall MySQL and install MariaDB and you are good to go. There is no need to dump and restore databases. As with any upgrade, we recommend making a backup of your data beforehand.
and I read you were having issues upgrading mariadb 10.4.20 so I don't know what this 10.2 stuff has to do with your upgrade issue?
 
We had no issues upgrading from Mysql 5.7 to MariaDB 10.2 on the other servers. Maybe DA used already a fix in the update script? I don't know why it might have issues now.
Couldn't find anything in the CB2 changelog about that but let's hope so!

and I read you were having issues upgrading mariadb 10.4.20 so I don't know what this 10.2 stuff has to do with your upgrade issue?
Upgrade path on this machine over time was MySQL 5.7 -> MariaDB 10.2 -> MariaDB 10.3 MariaDB 10.4

Please explain how to remove a schema that is not present? Because like they say it here, if you accidentally upgrade, then you already are running mariadb 10.2 or 10.3 which do not have that scheme.
Manually; open to suggestions here though, still hoping DirectAdmin will add a fix in a future version of CB.

DA is fully uninstalling mysql and then installing mariadb, so no sys scheme would be present. And also Mariadb itself is advising to convert from mysql 5.7 to mariadb 10.2.
The sys scheme is present by default on MySQL 5.7 and it's only doing a drop in replacement so the sys scheme would be present since it's not touching the actual database source files at all. This was the case on all our (Debian) machines anyway.
 
by default on MySQL 5.7 and it's only doing a drop in replacement
I don't know exactly what is ment by a drop in replacement, but the upgrade is doing a dump of all tables, then uninstall mysql and install mariadb and then restore all tables again. You mean the sys scheme table would get back in with the restore? Because as far as I know that is not backed up in the dump.
If what you say is true, then the sys scheme table should still be present in our mysql versions. We are at 10.4.21 at this moment too.
Also this upgrade went without issues. We went from 10.2 to 10.4, I'm not sure anymore but I thought I went via 10.3 just to be sure.
I'll have a look later if I see that table.

Edit: just checked, I only have the information_schema table on the databases.

So maybe it's a Debian thing. I don't know.
 
Last edited:
I don't know exactly what is ment by a drop in replacement, but the upgrade is doing a dump of all tables, then uninstall mysql and install mariadb and then restore all tables again.
As far as I know a drop in replacement is just replacing the MySQL binaries with MariaDB keeping the raw database source files as is. CB does give you the option to backup/dump all tables but MariaDB will just use the exact same database source files MySQL were using including the incompatible sys scheme.
 
I don't know. Only thing I know is that all databases are dropped like I described above. And that I don't have any sys_scheme tables in any of my databases. And they were all upgraded from Mysql 5.7 to MariaDB 10.2.
Only first time it went wrong. But that was more to my fault that I hadn't stopped mysql before the upgrade. SMtalk had to fix things but in this way the DA upgrade script became more foolproof. After that it stopped mysql before upgrading if mysql was still running.
 
Back
Top