Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-22678

Upgrade from MySQL Community Edition fails with "Plugin 'auth_socket' is not loaded"

Details

    Description

      Tested upgrading from MySQL Community Edition 5.7 to latest MariaDB 10.5 head. Otherwise it went well, but after the upgrade the server fails to accept connections from root as the auth_socket -> unix_socket that is supposed to be run by mysql_upgrade has not happened (fixed https://github.com/mariadb/server/commit/c1bdf62452139e9310d3234266802748ba4c74b8, part of https://jira.mariadb.org/browse/MDEV-11170).

      Log from https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/756113

      $ service mysql status
      1117 /usr/bin/mysqladmin: connect to server at 'localhost' failed
      1118 error: 'Plugin 'auth_socket' is not loaded'
      

      Upgrade from MySQL 5.7 in Debian works just fine and the auth_socket rename runs correctly: https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/756107

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            Second one sounds safer.

            I've also looked briefly to at it might be possible to do minimal a mysql_upgrade linked to the embedded mysql server library(with ---bootstrap --skip-innodb), that can be run as part of the postinst or a pre-server start script.

            danblack Daniel Black added a comment - Second one sounds safer. I've also looked briefly to at it might be possible to do minimal a mysql_upgrade linked to the embedded mysql server library(with ---bootstrap --skip-innodb ), that can be run as part of the postinst or a pre-server start script.
            danblack Daniel Black added a comment -

            In the interest of time, the original Sergei suggested solution was implemented. A linked mysql_upgrade to the mysql server would of been large indistinguishable in practice to the work around provided. --skip-innodb was chosen as only the myisam based mysql.user table is changed. key-buffersize is set to 0 as no secondary use of keys occurs and in some scenarios where myisam is dominate this may be large memory useage.

            Two major checks for reviews/merge:

            • is this the right debian location to place the hook?
            • Is the mysql-5.7 detection mechanism subject to false positives or negatives. The fast positive will be largely a noop so its less important.

            cause:
            https://github.com/mysql/mysql-server/blob/5.7/packaging/deb-in/mysql-packagesource-server.postinst.in#L80

            danblack Daniel Black added a comment - In the interest of time, the original Sergei suggested solution was implemented. A linked mysql_upgrade to the mysql server would of been large indistinguishable in practice to the work around provided. --skip-innodb was chosen as only the myisam based mysql.user table is changed. key-buffersize is set to 0 as no secondary use of keys occurs and in some scenarios where myisam is dominate this may be large memory useage. Two major checks for reviews/merge: is this the right debian location to place the hook? Is the mysql-5.7 detection mechanism subject to false positives or negatives. The fast positive will be largely a noop so its less important. cause: https://github.com/mysql/mysql-server/blob/5.7/packaging/deb-in/mysql-packagesource-server.postinst.in#L80

            Should we remove https://github.com/mariadb/server/commit/c1bdf62452139e9310d3234266802748ba4c74b8 then since it does not always work, and we manually need to boostrap the server anyway and run the same SQL statement?

            What about RPM packages? The fix now suggested is purely a Debian maintainer script based workaround. While I do understand how it runs and fixes the issue with a quick instance of the server in bootstrap mode I still feel this is very unelegant. Why can't the actual mysqld server fix itself?

            We just need to rename one plugin name, how hard can that be to do inside the server so we get rid of all the extra management of remembering to run extra upgrade steps and taking care an excess mysqld/mariadbd instance is not restarted too often?

            otto Otto Kekäläinen added a comment - Should we remove https://github.com/mariadb/server/commit/c1bdf62452139e9310d3234266802748ba4c74b8 then since it does not always work, and we manually need to boostrap the server anyway and run the same SQL statement? What about RPM packages? The fix now suggested is purely a Debian maintainer script based workaround. While I do understand how it runs and fixes the issue with a quick instance of the server in bootstrap mode I still feel this is very unelegant. Why can't the actual mysqld server fix itself? We just need to rename one plugin name, how hard can that be to do inside the server so we get rid of all the extra management of remembering to run extra upgrade steps and taking care an excess mysqld/mariadbd instance is not restarted too often?
            danblack Daniel Black added a comment -

            c1bdf62452139e9310d3234266802748ba4c74b8 works when an auth is available. So its useful when ordinary ordinary users have auth_socket that needs to be changed and there is an admin user.

            MDEV-21411 is a task for an inplace upgrade that will work for this as well.

            Its only Debian mysql packages that install the auth socket https://github.com/mysql/mysql-server/blob/5.7/packaging/deb-in/extra/mysql-helpers#L159, well done on being a trend setter

            I comprehend the minimisation of startups, I'm trying to get back to MDEV-23494 to fix the multiple start ups in container implementations to do all the things that mysql_install_db doesn't (and hence requiring multiple startups there unconditionally).

            Debian has one conditional start of mariadbd --bootstrap where I put a reasonable effort into minimizing time and other behaviours. While I appreciate that you desired something more elegant, at the moment there are more significant inelegant problems to solve.

            danblack Daniel Black added a comment - c1bdf62452139e9310d3234266802748ba4c74b8 works when an auth is available. So its useful when ordinary ordinary users have auth_socket that needs to be changed and there is an admin user. MDEV-21411 is a task for an inplace upgrade that will work for this as well. Its only Debian mysql packages that install the auth socket https://github.com/mysql/mysql-server/blob/5.7/packaging/deb-in/extra/mysql-helpers#L159 , well done on being a trend setter I comprehend the minimisation of startups, I'm trying to get back to MDEV-23494 to fix the multiple start ups in container implementations to do all the things that mysql_install_db doesn't (and hence requiring multiple startups there unconditionally). Debian has one conditional start of mariadbd --bootstrap where I put a reasonable effort into minimizing time and other behaviours. While I appreciate that you desired something more elegant, at the moment there are more significant inelegant problems to solve.
            otto Otto Kekäläinen added a comment - Tested and confirmed to work in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1040660

            People

              danblack Daniel Black
              otto Otto Kekäläinen
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.