mirror of
				https://github.com/MariaDB/server.git
				synced 2025-10-31 02:46:29 +01:00 
			
		
		
		
	 a1211a4eda
			
		
	
	
	a1211a4eda
	
	
	
		
			
			Use MariaDB named executables. Also remove unnecessary slave references. rename 50-mysql-clients.cnf -> 50-mariadb-clients.cnf 50-mysqld_safe.cnf -> 50-mariadb_safe.cnf
		
			
				
	
	
		
			203 lines
		
	
	
	
		
			8.1 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			203 lines
		
	
	
	
		
			8.1 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| * MARIADB WON'T START OR STOP?
 | |
| ==============================
 | |
| 
 | |
| The most common reasons the server does not start are:
 | |
| - AppArmor is enforced and something is wrong with the confinement profile.
 | |
| - Process supervisor scripts (init, systemd etc) fail to execute normally.
 | |
| - The configuration in /etc/mysql/... is wrong and prevents server from running.
 | |
| 
 | |
| First check the contents of syslog (or systemd journal) and then check the
 | |
| logs at /var/log/mysql/ for any hints of what might be wrong.
 | |
| 
 | |
| Examples:
 | |
|   grep mariadbd /var/log/syslog
 | |
|   journalctl -u mariadb
 | |
| 
 | |
| 
 | |
| * NEW SERVICE NAME, PROCESS AND BINARY NAMES SINCE MARIADB 10.5
 | |
| ===============================================================
 | |
| 
 | |
| Starting form MariaDB 10.5, the default SysV init service name is 'mariadb',
 | |
| and can be accessed at path /etc/init.d/mariadb. The alias 'mysql' is only
 | |
| created on upgrades.
 | |
| 
 | |
| On systemd services both 'mariadb' and alias 'mysql' are available all the time.
 | |
| 
 | |
| Note that the new daemon name is 'mariadbd' instead of 'mysqld' and also most
 | |
| of the binaries have been renamed to mariadb-something, yet the old mysql-something
 | |
| name has been kept as a symbolic link to the new name for backwards compatibility.
 | |
| 
 | |
| 
 | |
| * NATIVE SYSTEMD SERVICE INTRODUCED IN MARIADB 10.1
 | |
| ===================================================
 | |
| 
 | |
| From MariaDB 10.1 onward the upstream mariadb.service and mariadb@.service are
 | |
| used to provide the full systemd experience. Some features available in
 | |
| traditional /etc/init.d/mysql have been changed. For details see
 | |
| https://mariadb.com/kb/en/mariadb/systemd/
 | |
| 
 | |
| 
 | |
| * MIXING PACKAGES FROM MARIADB.ORG AND OFFICIAL DEBIAN REPOSITORIES
 | |
| ===================================================================
 | |
| 
 | |
| Please note that the MariaDB packaging in official Debian repositories are of
 | |
| a completely new generation compared to the legacy packaging used in MariaDB.org
 | |
| repositories. You cannot mix and match MariaDB 10.1 packages from official
 | |
| Debian (or Ubuntu) repositories with packages from MariaDB.org repositories.
 | |
| Packages from the MariaDB.org repositories include the revision string '+maria'.
 | |
| 
 | |
| If a MariaDB.org repository is enabled, learn to use apt pinning properly.
 | |
| 
 | |
| Please do not file bugs in Debian regarding packages with '+maria' in the
 | |
| revision string.
 | |
| 
 | |
| 
 | |
| * ROOT USER AUTHENTICATION VIA UNIX SOCKET
 | |
| ==========================================
 | |
| 
 | |
| On new installs no root password is set and no debian-sys-maint user is
 | |
| created anymore. Instead the MariaDB root account is set to be authenticated
 | |
| using the Unix socket, e.g. any mariadb invocation by root or via sudo will
 | |
| let the user see the MariaDB prompt.
 | |
| 
 | |
| You may never ever delete the MariaDB user "root". Although it has no password
 | |
| is set, the unix_auth plugin ensure that it can only be run locally as the root
 | |
| user.
 | |
| 
 | |
| The credentials in /etc/mysql/debian.cnf specify the user which is used by the
 | |
| init scripts to stop the server and perform log rotation. This used to be the
 | |
| debian-sys-maint user which is no longer used as root can run directly.
 | |
| 
 | |
| If you have start/stop problems make sure that the /etc/mysql/debian.cnf file
 | |
| specifies the root user and no password. In the long run please stop using that
 | |
| file as is has been obsoleted.
 | |
| 
 | |
| 
 | |
| * MARIADB IS SECURE BY DEFAULT
 | |
| ==============================
 | |
| 
 | |
| MariaDB in Debian is secure by default, because:
 | |
| 
 | |
| - It only listens to the localhost socket and cannot be accessed remotely unless
 | |
|   the sysadmin changes the configuration in /etc/mysql to allow so.
 | |
| - There is no debian-sys-maint with password in /etc/mysql/debian.cnf anymore.
 | |
| - There is no root account with password anymore. The system admin needs to
 | |
|   create one themselves if they need it. With no password, all issues related
 | |
|   to password management and password leaking are gone. Sysadmins can access
 | |
|   the database without a password simply by running 'sudo mariadb' thanks to
 | |
|   socket based authentication, which detects the system root user and allows
 | |
|   them to use the mariadb console as the MariaDB root user. For details see
 | |
|   https://www.slideshare.net/ottokekalainen/less-passwords-more-security-unix-socket-authentication-and-other-mariadb-hardening-tips
 | |
| - There is no test database nor test accounts in the out-of-the-box Debian
 | |
|   installation.
 | |
| 
 | |
| Therefore there is also no need to run the 'mariadb-secure-installation'. In fact
 | |
| that script will try to do things that are already prevented, and might fail.
 | |
| 
 | |
| 
 | |
| * WHAT TO DO AFTER UPGRADES
 | |
| ===========================
 | |
| 
 | |
| The privilege tables are automatically updated so all there is left is read
 | |
| the release notes on https://mariadb.com/kb/en/release-notes/ to see if any
 | |
| changes affect custom apps.
 | |
| 
 | |
| There should not be any need to run 'mariadb-upgrade' manually, as the upgrade
 | |
| scripts do that automatically.
 | |
| 
 | |
| 
 | |
| * WHAT TO DO AFTER INSTALLATION
 | |
| ===============================
 | |
| 
 | |
| The MariaDB manual describes certain steps to do at this stage in a separate
 | |
| chapter. They are not necessary as the Debian packages does them
 | |
| automatically.
 | |
| 
 | |
| There should not be any need to run 'mariadb-install-db' manually, as the install
 | |
| scripts do that automatically.
 | |
| 
 | |
| The only thing that is left over for the admin is
 | |
|  - creating new users and databases
 | |
|  - read the rest of this text
 | |
| 
 | |
| 
 | |
| * NETWORKING
 | |
| ============
 | |
| 
 | |
| For security reasons, the Debian package has enabled networking only on the
 | |
| loop-back device using "bind-address" in /etc/mysql/mariadb.cnf.  Check with
 | |
| "netstat -tlnp" where it is listening. If your connection is aborted
 | |
| immediately check your firewall rules or network routes.
 | |
| 
 | |
| * WHERE IS THE DOCUMENTATION?
 | |
| =============================
 | |
| 
 | |
| https://mariadb.com/kb
 | |
| 
 | |
| 
 | |
| * PASSWORDS
 | |
| ===========
 | |
| 
 | |
| It is recommended you create additional admin users for your database
 | |
| administration needs in addition to the default root user.
 | |
| 
 | |
| If your local Unix account is the one you want to have local super user
 | |
| access on your database with you can create the following account that will
 | |
| only work for the local Unix user connecting to the database locally.
 | |
| 
 | |
|   sudo /usr/bin/mariadb -e "GRANT ALL ON *.* TO '$USER'@'localhost' IDENTIFIED VIA unix_socket WITH GRANT OPTION"
 | |
| 
 | |
| To create a local machine account username=USERNAME with a password:
 | |
| 
 | |
|   sudo /usr/bin/mariadb -e "GRANT ALL ON *.* TO 'USERNAME'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION"
 | |
| 
 | |
| To create a USERNAME user with password 'password' admin user that can access
 | |
| the DB server over the network:
 | |
| 
 | |
|   sudo /usr/bin/mariadb -e "GRANT ALL ON *.* TO 'USERNAME'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION"
 | |
| 
 | |
| Scripts should run as a user who have the required grants and be identified via unix_socket.
 | |
| 
 | |
| It is wise to run scripts as the "mysql" system user. Like root,
 | |
| mysql@localhost is created by default to have all privileges in MariaDB
 | |
| and to use unix_socket authentication. But scripts running under "mysql"
 | |
| won't have system-wide root so they won't be able to corrupt your system.
 | |
| 
 | |
| If you are too tired to type the password in every time and unix_socket auth
 | |
| doesn't suit your needs, you can store it in the file $HOME/.my.cnf. It should
 | |
| be chmod 0600 (-rw------- username usergroup .my.cnf) to ensure that nobody else
 | |
| can read it.  Every other configuration parameter can be stored there, too.
 | |
| 
 | |
| For more information in the MariaDB manual in/usr/share/doc/mariadb-doc or
 | |
| https://mariadb.com/kb/en/configuring-mariadb-with-mycnf/.
 | |
| 
 | |
| 
 | |
| * FURTHER NOTES ON REPLICATION
 | |
| ==============================
 | |
| 
 | |
| If the MariaDB server is acting as a replica, you should not set --tmpdir to
 | |
| point to a directory on a memory-based file system or to a directory that is
 | |
| cleared when the server host restarts. A replica needs some of its temporary
 | |
| files to survive a machine restart so that it can replicate temporary tables
 | |
| or LOAD DATA INFILE operations. If files in the temporary file directory are
 | |
| lost when the server restarts, replication fails.
 | |
| 
 | |
| 
 | |
| * DOWNGRADING
 | |
| =============
 | |
| 
 | |
| Unsupported. Period.
 | |
| 
 | |
| You might get lucky downgrading a few minor versions without issued. Take a
 | |
| backup first. If you break it you get to keep both pieces. Do a restore from
 | |
| backup or upgrade to the previous version.
 | |
| 
 | |
| If doing a major version downgrade, take a mariadb-dump/maria-backup consistent
 | |
| backup using the current version and reload after downgrading and purging
 | |
| existing databases.
 | |
| 
 | |
| 
 | |
| * BACKUPS
 | |
| =========
 | |
| 
 | |
| Backups save jobs. Don't get caught without one.
 |