Removed the option as it safe to always create the file when we have
created the MariaDB data directories. This fixes this issue not only
for debian but for all MariaDB users.
For compatibility this is under an extra option --upgrade-info
The goal here is to install a data directory with the required
info to let mysql_upgrade know that an upgrade isn't required.
MDEV-27107 prevent two mariadb-upgrade running in parallel
MDEV-27279 mariadb_upgrade add --check-if-upgrade-is-needed /
restrict tests to major version
Code is based of pull request from Daniel Black, but with a several
extensions.
- mysql_upgrade now locks the mysql_upgrade file with my_lock()
(Advisory record locking). This ensures that two mysql_upgrades
cannot be run in parallel.
- Added --check-if-upgrade-is-needed to mysql_upgrade. This will return
0 if one has to run mysql_upgrade.
Other changes:
- mysql_upgrade will now immediately exit if the major version and minor
version (two first numbers in the version string) is same as last run.
Before this change mysql_upgrade was run if the version string was different
from last run.
- Better messages when there is no need to run mysql_upgrade.
- mysql_upgrade --verbose now prints out a lot more information about
the version checking.
- mysql_upgrade --debug now uses default debug arguments if there is no
option to --debug
- "MySQL" is renamed to MariaDB in the messages
- mysql_upgrade version increased to 2.0
Notes
Verifying "prevent two mariadb-upgrade running in parallel" was
done in a debugger as it would be a bit complex to do that in mtr.
Reviewer: Danial Black <daniel@mariadb.org>
`mytop` and `my_print_defaults` for RPM
- Add `mytop` to client package
- Add man page of `my_print_defaults` to client package
- Add dependencies for RPMs
- Remove old comment
- Remove dead link
Reviewed by: serg@mariadb.com
This is a documentation-only patch to refine the description of
binary mode for the mariadb client.
Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>
Problem:
=======
The ALWAYS option of the mariadb-binlog --base64-output flag
formats its output incorrectly. This option is deprecated, and
MySQL 8.0 has removed it entirely.
Solution:
========
Adhere to MySQL and remove this option from MariaDB.
Behavioral Changes:
==================
Use Case: ./mariadb-binlog --base64-output
Previous Behavior: Sets base64-output mode to always
New Behavior: Error message indicating incomplete argument
Use Case: ./mariadb-binlog --base64-output=always
Previous Behavior: Sets base64-output mode to always
New Behavior: Error message indicating invalid argument value
Reviewed By:
==========
Andrei Elkin: <andrei.elkin@mariadb.com>
Add --system={all, users, plugins, udfs, servers, stats, timezones}
This will dump system information from the server in
a logical form like:
* CREATE USER
* GRANT
* SET DEFAULT ROLE
* CREATE ROLE
* CREATE SERVER
* INSTALL PLUGIN
* CREATE FUNCTION
"stats" is the innodb statistics tables or EITS and
these are dumped as INSERT/REPLACE INTO statements
without recreating the table.
"timezones" is the collection of timezone tables
which are important to transfer to generate identical
results on restoration.
Two other options have an effect on the SQL generated by
--system=all. These are mutually exclusive of each other.
* --replace
* --insert-ignore
--replace will include "OR REPLACE" into the logical form
like:
* CREATE OR REPLACE USER ...
* DROP ROLE IF EXISTS (MySQL-8.0+)
* CREATE OR REPLACE ROLE ...
* UNINSTALL PLUGIN IF EXISTS (10.4+) ... (before INSTALL PLUGIN)
* DROP FUNCTION IF EXISTS (MySQL-5.7+)
* CREATE OR REPLACE [AGGREGATE] FUNCTION
* CREATE OR REPLACE SERVER
--insert-ignore uses the construct " IF NOT EXISTS" where
supported in the logical syntax.
'CREATE OR REPLACE USER' includes protection against
being run as the same user that is importing the mysqldump.
Includes experimental support for dumping mysql-5.7/8.0
system tables and exporting logical SQL compatible with MySQL.
Updates mysqldump man page, including this information and
(removing obsolute bug reference)
Reviewed-by: anel@mariadb.org
To change all executables to have a mariadb name I had to:
- Do name changes in every CMakeLists.txt that produces executables
- CREATE_MARIADB_SYMLINK was removed and GET_SYMLINK added by Wlad to reuse the function in other places also
- The scripts/CMakeLists.txt could make use of GET_SYMLINK instead of introducing redundant code, but I thought I'll leave that for next release
- A lot of changes to debian/.install and debian/.links files due to swapping of real executable and symlink. I did not however change the name of the manpages, so the real name is still mysql there and mariadb are symlinks.
- The Windows part needed a change now when we made the executables mariadb -named. MSI (and ZIP) do not support symlinks and to not break backward compatibility we had to include mysql named binaries also. Done by Wlad
After the '.so' one is supposed to use the directory name, like we have
correctly in all old man pages:
mysql_client_test_embedded.1:.so man1/mysql_client_test.1
mysql_embedded.1:.so man1/mysql.1
mysqltest_embedded.1:.so man1/mysqltest.1
This change adds the 'man1/' component so the link has the correct format.
Actually using man links is a deprecated practice and using symlinks
would be better, but that can be fixed in a later commit.
From https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages:
> If one man page needs to be accessible via several names it is better
> to use a symbolic link than the .so feature
Detected via Lintian errors:
E: mariadb-server-10.5: bad-so-link-within-manual-page usr/share/man/man1/mariadb-show.1.gz
E: mariadb-client-10.5: bad-so-link-within-manual-page usr/share/man/man1/mariadb-binlog.1.gz
E: mariadb-client-10.5: bad-so-link-within-manual-page usr/share/man/man1/mariadb-plugin.1.gz
Related to MDEV-21769.
