When acting as a Galera receiver node, server startup may take
more than 30 secs (the current default) as it has to wait for
SST/IST operation to complete besides spending some time doing
wsrep recovery.
Fixed by raising the default value of MYSQLD_STARTUP_TIMEOUT
to 60 secs. Also sourced /etc/default/mariadb into the init
script so that it can be used to set MYSQLD_STARTUP_TIMEOUT.
Logrotate script assumed an error if mysqladmin failed to connect to server
and there's mysqld process exists. However there can be non-system instance of
mysqld running (e.g. in docker) making this assumption wrong.
Check pid file existance instead.
Unmask the systemd mysql.service if left behind by mysql-server-5.6
Without this a simple 'apt-get install mariadb-server' would end
up with a system where mysqld is not running despite it was
running OK with mysql-server-5.6 installed, and users might wrongly
think mariadb-server package is broken when the real cause was
the removal of mysql-server-5.6 that left a /etc/systemd/system/
file behind pointing to /dev/null.
Set umask so that newly created file is not readable by others. This is a quick
fix to close security gap. To be replaced by MDEV-8375 - passwordless root
login.
Make dependency on mysql-common package in debian/control
versioned to force that it is installed together with the other
mariadb-* packages. This ensures that the init.d and systemd
files for MariaDB mysqld are the ones from MariaDB.org repos.
This is useful for developers who run autobake-deb.sh directly
from the source tree as the resulting source tar package will be
90% smaller and all operations regarding it consequently 10x faster.
This should make the provides/breaks/replaces/conflicts lines
work properly when upgrading from mysql-5.6 to mariadb-packages.
Conflicts:
debian/control
The only difference between the files was the Debian standards
line by one micro version. There was no logical motivation why
there was separate control file for Debian and Ubuntu.
The new debian/control file lives directly at the correct location
and has the correct contents.
Modify autobake.sh to take into account new control file location.
myisam_recover is only an alias for myisam_recover_options.
Use the option name instead of the alias is more correct.
This also avoids an note about the use of an alias instead of the option
name on every server start.
A comment in debian/mariadb-server-10.1.postinst says: "can safely run on
upgrades with existing databases". While this is true there're a few reasons not
to do that:
- it increases installation time (it has to run rather heavy mysqld multiple times)
- as well as it increases mysqld downtime
- it may fail if database has some plugin specific configs (see MDEV-8437)
- there should be no need to run this script on upgrade: they should be handled
by mysql_upgrade to
- RPM postin doesn't call it if database directory exists
Also postinst is not supposed to create database directories: let
mysql_install_db do that intead.
There was code that was supposed to "catch upgrades from previous versions where
the root password wasn't set". But it is wrong in many regards:
- it is supposed to be executed against running server, but at this point server
should be down, which makes this code no-op
- if the above is fixed, root password will be requested twice (initial root
password request + this one)
- it asks for a password only once, while "initial root password request" asks
twice (password + password verification)
- it may give false positive if unix socket based authentication is in effect
Removed this code since it didn't work for quite a while (at least since
mysql-5.1) and nobody cared about it.
There is no strong need to change password column: the only side effect is
that 4.0 -> 10.1 upgrades may get root/debian-sys-maint passwords stored in old
format. This should be perfectly acceptable, since all password at this point
are stored in old format.
Removed redundant attempt to create mysql.plugin table:
- original code was supposed to INSTALL some plugins:
INSERT INTO plugin VALUES ('innodb', 'ha_innodb.so'),
('federated', 'ha_federated.so'), ('blackhole', 'ha_blackhole.so'),
('archive', 'ha_archive.so');
- original code was supposed to fail if mysql.plugin exists:
The query sequence is supposed to be aborted if the CREATE TABLE fails due
to an already existent table in which case the admin might already have
chosen to remove one or more plugins.
- mysql.plugin must've been created by preceeding mysql_install_db anyway
This reverts commit 6bd94cf542.
Without galera as a compulsory dependency, test suite will not pass
due to failing:
wsrep.pool_of_threads wsrep.binlog_format wsrep.mdev_6832 wsrep.mdev_7798
Plus minor other fixes to debian/control file, wrap-and-sort,
versioned mariadb-common dependency etc. All changes based on
comparison with mariadb-10.0 packaging in official Debian
repositories.
Having galera-3 as a Depends stops installation of proceeding
on systems where package galera-3 is not available. The server
can run fine withouth galera enabled, therefore a more slack
relationship is more appropriate.
