The .deb packages provided by MariaDB Foundation's and MariaDB Corporation's repositories are not identical to the official .deb packages provided by Debian's and Ubuntu's default repositories.

The packages provided by MariaDB Foundation's and MariaDB Corporation's repositories are generated using the Debian packaging in MariaDB's official source code. The Debian packaging scripts are specifically in the debian/ directory.

The packages provided by Debian's and Ubuntu's default repositories are generated using the Debian packaging in Debian's mirror of MariaDB's source code, which contains some custom changes. The source tree can be found here:

• mariadb-server

As a consequence, MariaDB behaves a bit differently if it is installed from Debian's and Ubuntu's default repositories.

Option File Locations

• The located at /etc/mysql/my.cnf is handled by the mechanism when the mysql-common package is installed. It is a symbolic link that references either mysql.cnf or mariadb.cnf depending on whether MySQL or MariaDB is installed. Most of the MariaDB are therefore actually located in /etc/mysql/mariadb.d/.

System Variables

Since there is no system variable difference from the Standard MariaDB.

Options

TLS

• MariaDB binaries from packages provided by Debian's and Ubuntu's default repositories are linked with a different TLS library than MariaDB binaries from packages provided by MariaDB Foundation's and MariaDB Corporation's repositories.

• MariaDB Server binaries:

  • MariaDB Server is statically linked with the bundled libraries in packages provided by Debian's and Ubuntu's default repositories.

Authentication

• The authentication plugin is installed by default in new installations that use the packages provided by Debian's default repositories in Debian 9 and later and Ubuntu's default repositories in Ubuntu 15.10 and later.

• The root@localhost created by will also be created to authenticate via the authentication plugin in these builds.

See Also

More Information

For details, check out the Debian and Ubuntu official repositories:

_{This page is licensed: CC BY-SA / Gnu FDL}

After running apt-upgrade mariadb, it's possible that apt shows a fail in trying to start the server, but in fact the database is up and running, which then provokes apt to remain in a non finished state.

For example:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up mariadb-server-10.1 (10.1.10+maria-1~trusty) ...
 * Stopping MariaDB database server mysqld
   ...done.
 * Starting MariaDB database server mysqld
   ...fail!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing package mariadb-server-10.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mariadb-server:
 mariadb-server depends on mariadb-server-10.1 (= 10.1.10+maria-1~trusty); however:
  Package mariadb-server-10.1 is not configured yet.
 
dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
 mariadb-server-10.1
 mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

This situation could occur if the timeout for the init script was too short. For example, see MDEV-9382, a situation where the timeout was 30 seconds, but the server was taking 48 seconds to start.

To overcome this, the timeout needs to be increased. This can be achieved as follows:

• On systems where systemd is not enabled/supported: The timeout can be increased by setting MYSQLD_STARTUP_TIMEOUT either directly in the script or via the command line. The init script also sources /etc/default/mariadb, so it can also be used to set MYSQLD_STARTUP_TIMEOUT to persistently change the startup timeout.

• On systems that support systemd: The startup timeout can be increased by setting option.

_{This page is licensed: CC BY-SA / Gnu FDL}

Shortly after the release we became aware of some installation issues with the Debian and Ubuntu repositories. These issues were fixed in , but due to how apt works, steps need to be taken to solve the broken dependencies before upgrading.

We know of three scenarios when dependencies were broken. The steps to fix each of them are pretty much the same, only the list of broken dependencies and hence the list of packages to take care of them differs. The basic idea is to downgrade those certain packages to 5.5.32 temporarily before upgrading them to 5.5.33a.

If you ran into issues when moving from to , look through each of the three scenarios to see which one applies to you and then follow the steps to apply that fix.

Applying the fix

To get your system ready to apply the fix, do the following:

• Comment out the standard repo in the /etc/apt/sources.list or /etc/apt/sources.list.d/mariadb.repo file (or wherever you have the repositories configured).

• Add a repository to the sources.list. The easiest way is to add the following. Just replace '{os}' and '{dist}' with the appropriate values.

For example, on Debian Wheezy the line would be:

And on Ubuntu Raring the line would be:

• Then run 'sudo apt-get update'

• Then 'sudo apt-get install' the list of packages to downgrade as given in the applicable section below.

• Next, modify our sources.list to remove the 5.5.32 repo and switch back to the normal 5.5 repo

5.5.32 server + 5.5.32 client upgraded to the initial (17 Sep 2013) release of 5.5.33

In this first scenario, both client and server were partially upgraded to 5.5.33 before the process aborted. The problem looks like this:

To fix it, the following server and client packages need to be temporarily downgraded to 5.5.32 (replace 'wheezy' with the name of whatever distribution you are using):

5.5.32 Galera server and 5.5.32 MariaDB client upgraded to 5.5.33

In this scenario, the client upgraded, but Galera-server did not. The problem looks like this:

To fix it, only the client packages need to be temporarily downgraded to 5.5.32 (replace wheezy with whatever your distribution is):

5.3.12 server + 5.3.12 client + 5.5.32 libmariadbclient18 upgraded to 5.5.33

In this scenario, only the library upgraded. The problem looks like this:

To fix it, the library needs to be downgraded to 5.5.32 (replace wheezy with your distribution):

After switching back to the 5.5 repo, the libraries won't get upgraded, they will stay 5.5.32 until you upgrade the server to 5.5.33a.

_{This page is licensed: CC BY-SA / Gnu FDL}

A member of the MariaDB community, Mark <ms (at) it-infrastrukturen (dot) org>, has created some Debian "squeeze" 6.0.4 based, live iso images with or 5.3 pre-installed on them and some Debian "squeeze" 6.0.5 based, live iso images with pre-installed on them.

These live and install images can be used to quickly run a MariaDB server in live mode for learning or testing purposes, or to simplify and speed up off-line installations of Debian-based MariaDB servers onto harddisk.

To work in live mode the system boots from a usb stick (or CD/DVD) and runs in RAM without touching the system's harddisk drive.

MariaDB 10.1 is now the default mysql server in Debian 9 "Stretch". This page provides information on this change and instructions to help with upgrading your Debian 8 "Jessie" version of MySQL or MariaDB to MariaDB 10.1 in Debian 9 "Stretch".

Background information

The version of MySQL in Debian 8 "Jessie" is 5.5. When installing, most users will install the mysql-server package, which depends on the mysql-server-5.5 package. In Debian 9 "Stretch" the mysql-server package depends on a new package called default-mysql-server. This package in turn depends on mariadb-server-10.1. There is no default-mysql-server package in Jessie.

In both Jessie and Stretch there is also a mariadb-server package which is a MariaDB-specific analog to the mysql-server package. In Jessie this package depends on mariadb-server-10.0 and in Stretch this package depends on mariadb-server-10.1 (the same as the default-mysql-server package).

So, the main repository difference in Debian 9 "Stretch" is that when you install the mysql-server package on Stretch you will get instead of MySQL, like you would with previous versions of Debian. Note that mysql-server is just an empty transitional meta-package and users are encouraged to install MariaDB using the actual package mariadb-server.

All apps and tools, such as the popular LAMP stack, in the repositories that depend on the mysql-server package will continue to work using MariaDB as the database. For new installs there is nothing different that needs to be done when installing the mysql-server or mariadb-server packages.

Before you upgrade

If you are currently running MySQL 5.5 on Debian 8 "Jessie" and are planning an upgrade to on Debian 9 "Stretch", there are some things to keep in mind:

Backup before you begin

This is a major upgrade, and so complete database backups are strongly suggested before you begin. is compatible on disk and wire with MySQL 5.5, and the MariaDB developer team has done extensive development and testing to make upgrades as painless and trouble-free as possible. Even so, it's always a good idea to do regular backups, especially before an upgrade. As the database has to shut down anyway for the upgrade, this is a good opportunity to do a backup!

Changed, renamed, and removed options

Some default values have been changed, some have been renamed, and others have been removed between MySQL 5.5 and . The following sections detail them.

Options with changed default values

Most of the following options have increased a bit in value to give better performance. They should not use much additional memory, but some of them do use a bit more disk space. []

Options that have been removed or renamed

The following options should be removed or renamed if you use them in your config files:

Suggested upgrade procedure for replication

If you have a , the normal procedure is to first upgrade your slaves to MariaDB, then move one of your slaves to be the master and then upgrade your original master. In this scenario you can upgrade from MySQL to MariaDB or upgrade later to a new version of MariaDB without any downtime.

Other resources to consult before beginning your upgrade

It may also be useful to check out the section. It contains several articles on upgrading from MySQL to MariaDB and from one version of MariaDB to another. For upgrade purposes, MySQL 5.5 and are very similar. In particular, see the and articles.

If you need help with upgrading or setting up replication, you can always to find experts to help you with this.

Upgrading to from MySQL 5.5

Pre-Upgrade Preparation

1. Set InnoDB for a Full Shutdown Set innodb_fast_shutdown to 0. This is to ensure that if you make a backup as part of the upgrade, all data is written to the InnoDB data files, which simplifies any restore in the future.

2. Shutdown MySQL Shutdown your MySQL 5.5 server.

3. Take a Full Backup

OS and Database Upgrade

1. Perform the OS Upgrade Proceed with the upgrade from Debian 8 to Debian 9.

   • Automatic Database Upgrade Process During the Debian upgrade, the mysql_upgrade script will be run automatically. This script does two things:

Post-Upgrade Configuration

1. Update Configuration and Restart You can now add new options to your my.cnf file to enable new features.

   • After changing my.cnf, you must restart the mysqld service.

   or

Upgrading to from an older version of MariaDB

If you have installed or on your Debian 8 "Jessie" machine from the MariaDB repositories you will need to upgrade to when upgrading to Debian 9 "Stretch". You can choose to continue using the MariaDB repositories or move to using the Debian repositories.

If you want to continue using the MariaDB repositories edit the MariaDB entry in your sources.list and change every instance of 5.5 or 10.0 to 10.1. Then upgrade as suggested .

If you want to move to using from the Debian repositories, delete or comment out the MariaDB entries in your sources.list file. Then upgrade as suggested .

If you are already using on your Debian 8 "Jessie" machine, you can choose to continue to use the MariaDB repositories or move to using the Debian repositories as with and 10.0. In either case, the upgrade will at most be just a minor upgrade from one version of to a newer version. In the case that you are already on the current version of MariaDB that exists in the Debian repositories or a newer one) MariaDB will not be upgraded during the system upgrade but will be upgraded when future versions of MariaDB are released.

You should always perform a compete backup of your data prior to performing any major system upgrade, even if MariaDB itself is not being upgraded!

MariaDB Galera Cluster

If you have been using MariaDB Galera Cluster 5.5 or 10.0 on Debian 8 "Jessie" it is worth mentioning that is included by default in , there is no longer a need to install a separate mariadb-galera-server package.

Configuration options for advanced database users

To get better performance from MariaDB used in production environments, here are some suggested additions to which in Debian is at /etc/mysql/mariadb.d/my.cnf:

The reason for the above change is that MariaDB is using the newer storage engine for disk based temporary files instead of MyISAM. The main benefit of Aria is that it can cache both indexes and rows and thus gives better performance than MyISAM for large queries.

Secure passwordless root accounts only on new installs

Unlike the old MySQL packages in Debian, onwards in Debian uses unix socket authentication on new installs to avoid root password management issues and thus be more secure and easier to use with provision systems of the cloud age.

This only affects new installs. Upgrades from old versions will continue to use whatever authentication and user accounts already existed. This is however good to know, because it can affect upgrades of dependant systems, typically e.g. require users to rewrite their Ansible scripts and similar tasks. The new feature is much easier than the old, so adjusting for it requires little work.

See also

Comments and suggestions

If you have comments or suggestions on things we can add or change to improve this page. Please add them as comments below.

Notes

1. The innodb-open-files variable defaults to the value of table-open-cache (400 is the default) if it is set to any value less than 10 so long as innodb-file-per-table is set to 1 or TRUE (the default). If innodb_file_per_table is set to 0 or FALSE and innodb-open-files

_{This page is licensed: CC BY-SA / Gnu FDL}