MariaDB Updates

@smtalk @fln @DirectAdmin Support


Any ETA on adding these? Pretty big updates for all versions with performance updates.. and this:

Security​

 
Update don't upgrade to new version, stick on old (only on one server) - CL8:

Code:
Executing /usr/local/directadmin/plugins/custombuild/admin/build mysql...
Dumping database a..........
.............
Downloading mysql/centos8-64.txt...
######################################################################## 100.0%
Found /usr/local/directadmin/custombuild/mysql/MariaDB-client-10.5.16-1.el8.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-devel-10.5.16-1.el8.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-server-10.5.16-1.el8.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-shared-10.5.16-1.el8.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-common-10.5.16-1.el8.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-backup-10.5.16-1.el8.x86_64.rpm
Installing dependencies...
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 1:40:23 ago on Mon Jun 6 15:09:03 2022.
Package boost-program-options-1.66.0-10.el8.x86_64 is already installed.
Package perl-Compress-Raw-Bzip2-2.081-1.el8.x86_64 is already installed.
Package perl-Compress-Raw-Zlib-2.081-1.el8.x86_64 is already installed.
Package perl-DBI-1.641-3.module_el8.3.0+2054+fbe55708.x86_64 is already installed.
Package perl-Data-Dumper-2.167-399.el8.x86_64 is already installed.
Package perl-IO-Compress-2.081-1.el8.noarch is already installed.
No match for argument: perl-PlRPC
Package lsof-4.93.2-1.el8.x86_64 is already installed.
Package rsync-3.1.3-12.el8.x86_64 is already installed.
Package pcre2-10.32-2.el8.x86_64 is already installed.
Package socat-1.7.4.1-1.el8.x86_64 is already installed.
Error: Unable to find a match: perl-PlRPC
Installing galera...
Found /usr/local/directadmin/custombuild/mysql/galera-4-26.4.8-1.el8.x86_64.rpm
warning: /usr/local/directadmin/custombuild/mysql/galera-4-26.4.8-1.el8.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
Stopping mysqld ...
Service didn't get stopped, sleeping for 20 secs and re-trying ...
Stopping mysqld ...
Updating MariaDB 10.5.15 to 10.5.16
warning: MariaDB-client-10.5.16-1.el8.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
Created symlink /etc/systemd/system/mysql.service → /etc/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/mysqld.service → /etc/systemd/system/mariadb.service.
Ensuring local-infile is disabled for security reasons in MySQL configuration file...
Giving mysqld a few seconds to start up...
This installation of MariaDB is already upgraded to 10.5.13-MariaDB.
There is no need to run mysql_upgrade again for 10.5.15-MariaDB.
You can use --force if you still want to run mysql_upgrade
CageFS: Executing 'cagefsctl --force-update'...
Copying /usr/bin/msql2mysql to /usr/share/cagefs-skeleton/usr/bin/msql2mysql
Copying /usr/bin/my_print_defaults to /usr/share/cagefs-skeleton/usr/bin/my_print_defaults
Copying /usr/bin/mariadb to /usr/share/cagefs-skeleton/usr/bin/mariadb
Copying /usr/bin/mariadb-access to /usr/share/cagefs-skeleton/usr/bin/mariadb-access
Copying /usr/bin/mariadb-admin to /usr/share/cagefs-skeleton/usr/bin/mariadb-admin
Copying /usr/bin/mariadb-binlog to /usr/share/cagefs-skeleton/usr/bin/mariadb-binlog
Copying /usr/bin/mariadb-check to /usr/share/cagefs-skeleton/usr/bin/mariadb-check
Copying /usr/bin/mariadb-dump to /usr/share/cagefs-skeleton/usr/bin/mariadb-dump
Copying /usr/bin/mariadb-find-rows to /usr/share/cagefs-skeleton/usr/bin/mariadb-find-rows
Copying /usr/bin/mariadb-import to /usr/share/cagefs-skeleton/usr/bin/mariadb-import
Copying /usr/bin/mariadb-show to /usr/share/cagefs-skeleton/usr/bin/mariadb-show
Copying /usr/bin/mariadb-waitpid to /usr/share/cagefs-skeleton/usr/bin/mariadb-waitpid
Updating users ...
Updating statuses of users ...
Restarting MySQL.
Installation completed.
Done
 
Can someone translate for me what happened? I noticed the update took a long time on my server.
 
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
Is this the issue, the upgrade threw this error and they were not able to run the update?
 
Yes there was an error during update, this error which he posted in the log:
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
Removing the /var/lib/rpm/.rpm.lock file remove this error for Apogee so he could do the upgrade without errors.
 
Is this the issue, the upgrade threw this error and they were not able to run the update?
I don't think the issue is related to MariaDB. But is just related to his RPM database being locked. Probably by another process or a process that failed to clean up after itself (perhaps stopped mid install).

I don't think there is an issue with the MariaDB update. This was just specific to this one specific user having their RPM database locked.
 
it occurred only on one server, but on one of the dev servers the update took almost 7 minutes (but without any other error messages)
 
Dumping the databases took that long or the upgrade itself? Pretty quick here, around 30-40 seconds to install.

One thing I noticed is that mysql_upgrade isn't run anymore after the upgrade:

Code:
Giving mysqld a few seconds to start up...
This installation of MariaDB is already upgraded to 10.6.5-MariaDB.
There is no need to run mysql_upgrade again for 10.6.8-MariaDB.
You can use --force if you still want to run mysql_upgrade
Restarting MySQL.
Installation completed.

A change in CustomBuild? I've had some issues in the past with this so I ran it manually with --force

Code:
This installation of MariaDB is already upgraded to 10.6.8-MariaDB.
There is no need to run mysql_upgrade again for 10.6.8-MariaDB.
You can use --force if you still want to run mysql_upgrade
 
One thing I noticed is that mysql_upgrade isn't run anymore after the upgrade:
Same here but the you get message like
This installation of MariaDB is already upgraded to 10.5.13-MariaDB. There is no need to run mysql_upgrade again for 10.5.15-MariaDB.
So this make me confused,although checking sql version shows the latest version, but now I am worried..
 
If ./build versions shows the latest version it’s ok.

mysql_upgrade saves the MySQL version number in a file named mysql_upgrade_info in the data directory. This is used to quickly check whether all tables have been checked for this release so that table-checking can be skipped. To ignore this file and perform the check regardless, use the --force option.

To make sure everything is ok and upgrade this file run it manually

Code:
mysql_upgrade --force -u root -p
 
This installation of MariaDB is already upgraded to 10.5.13-MariaDB. There is no need to run mysql_upgrade again for 10.5.15-MariaDB.
I saw this during my upgrade too, which confused me so I did check to make sure the upgrade was successful - which it was.
 
but now I am worried..
You don't need to be worried, as mysql-upgrade only needs to be run when doing major version upgrades or migrations. So MariaDB 10.4 to 10.5 for example, but not within the 10.4 or 10.5 range.

The current update is a minor version so you don't need to run the command. Which is what the notice also says.
It's safe to do it, but it's not needed.

You can find this info at the Mariadb info page here:

I wonder why nobody else went on Google and checked this if people are worried. ;)
 
I am worried..
same about recommended PHP recompile - it's only needed after mysql upgrade between different branches, any update in same branch - don't need to change anything because usually nobody implements any new incompatible features in same branch.
 
Back
Top