ll-powerful
user with the same name as a system user that owns the data directory. In
local (not system-wide) installations, this will be the user who installed
MariaDB — they automatically get convenient password-less root-like access,
because they can access all the data files anyway.

Even if MariaDB is installed system-wide, you may not want to run your
database maintenance scripts as system root — now you can run them as system
mysql user. And you will know that they will never destroy your entire system,
even if you make a typo in a shell script.

However, seasoned MariaDB DBAs who are used to the old ways do need to make
some changes. See the examples below for common tasks.

Cookbook
--------

After installing MariaDB system-wide the first thing you’ve got used to doing
is logging in into the unprotected root account and protecting it, that is,
setting the root password:

$ sudo dnf install MariaDB-server
$ mysql -uroot
...
MariaDB> set password = password("XH4VmT3_jt");

This is not only unnecessary now, it will simply not work — there is no
unprotected root account. To login as root use

$ sudo dnf install MariaDB-server
$ sudo mysql

Note that it implies you are connecting via the unix socket, not tcp. If you
happen to have protocol=tcp in a system-wide /etc/my.cnf file, use sudo mysql
--protocol=socket.

After installing MariaDB locally you’ve also used to connect to the
unprotected root account using mysql -uroot. This will not work either, simply
use mysql without specifying a username.

If you've forgotten your root password, no problem — you can still connect
using sudo and change the password. And if you've also removed unix_socket
authentication, to restore access do as follows:

* restart MariaDB with --skip-grant-tables
* login into the unprotected server
* run FLUSH PRIVILEGES (note, before 10.4 this would’ve been the last step,
not anymore). This disables --skip-grant-tables and allows you to change the
stored authentication method
* run SET PASSWORD FOR root@localhost to change the root password.

To view inside privilege tables, the old mysql.user table still exists. You
can select from it as before, although you cannot update it anymore. It
doesn’t show alternative authentication plugins and this was one of the
reasons for switching to the mysql.global_priv table — complex authentication
rules did not fit into rigid structure of a relational table. You can select
from the new table, for example:

select concat(user, '@', host, ' => ', json_detailed(priv)) from
mysql.global_priv;

Reverting to the Previous Authentication Method for root@localhost
------------------------------------------------------------------

If you don't want the root@localhost user account created by
mariadb-install-db to use unix_socket authentication by default, then there
are a few ways to revert to the previous mysql_native_password authentication
method for this user account.

Configuring mariadb-install-db to Revert to the Previous Authentication Method
------------------------------------------------------------------------------

One way to revert to the previous mysql_native_password authentication method
for the root@localhost user account is to execute mariadb-install-db with a
special option. If mariadb-install-db is executed while
--auth-root-authentication-method=normal is specified, then it will create the
default user accounts using the default behavior of MariaDB 10.3 and before.

This means that the root@localhost user account will use mysql_native_password
authentication by default. There are some other differences as well. See
mariadb-install-db: User Accounts Created by Default for more information.

For example, the option can be set on the command-line while running
mariadb-install-db:

mariadb-install-db --user=mysql --datadir=/var/lib/mysql
--auth-root-authentication-method=normal

The option can also be set in an option file in an option group supported by
mariadb-install-db. For example:

[mysql_install_db]
auth_root_authentication_method=normal

If the option is set in an opt\®ö¾