fix for Bug #55672 "mysql_upgrade dies with internal error":
it couldn't parse the --ssl option.
client/mysql_upgrade.c:
mysql_upgrade parses its options and passes some of them to the underlying
tools (mysqlcheck etc). To do this passdown, it reconstructs a
command-line-suitable text from the my_option object (which
contains the option's name and option's value). For options
which expect no parameter, it just had to use the option's name;
for other options, it had to concatenate the option's name,
a "=" symbol, and the option's value; it had code to handle
this latter case, but only for GET_STR options (options taking a
string as value). But since the work on WL 4738, the --ssl
option, a GET_BOOL, which used to have no parameter (NO_ARG), can
now have one (OPT_ARG), so with --ssl we came to the "default"
label, error. Fixed by constructing the command-line-suitable
representation for GET_BOOL too. For --ssl it will produce
--ssl=1 ; for --ssl=0, it will produce --ssl=0.
mysql-test/include/mysql_upgrade_preparation.inc:
handles requirements of tests which use mysql_upgrade
mysql-test/r/mysql_upgrade_ssl.result:
result; without the code fix we would get "internal error".
mysql-test/t/mysql_upgrade.test:
This test has requirements before running; moved them
to an include file in order to share with mysql_upgrade_ssl.
mysql-test/t/mysql_upgrade_ssl.test:
test for bug. Couldn't go into mysql_upgrade.test as this new test requires
SSL support. --force is needed, in case mysql_upgrade.test run before
(in which case mysql_upgrade_ssl would say that upgrade has already been
done); --force forces the upgrade in all cases.
2010-08-11 19:56:56 +02:00
-- source include/mysql_upgrade_preparation.inc
2009-10-05 15:22:23 +02:00
-- source include/have_working_dns.inc
2012-08-22 23:32:25 +02:00
-- source include/have_innodb.inc
2017-07-20 15:08:24 +02:00
-- source include/have_partition.inc
2009-07-28 21:59:38 +02:00
2015-08-11 18:45:38 +02:00
set sql_mode="";
2006-11-13 13:39:49 +01:00
#
2007-04-18 13:21:39 +02:00
# Basic test that we can run mysql_upgrde and that it finds the
2006-11-13 13:39:49 +01:00
# expected binaries it uses.
#
--echo Run mysql_upgrade once
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force 2>&1
2007-04-18 13:21:39 +02:00
# It should have created a file in the MySQL Servers datadir
2007-12-12 18:19:24 +01:00
let $MYSQLD_DATADIR= `select @@datadir`;
file_exists $MYSQLD_DATADIR/mysql_upgrade_info;
2006-11-13 13:39:49 +01:00
--echo Run it again - should say already completed
2007-04-23 21:27:43 +02:00
--replace_result $MYSQL_SERVER_VERSION VERSION
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE 2>&1
2007-04-18 13:21:39 +02:00
# It should have created a file in the MySQL Servers datadir
2007-12-12 18:19:24 +01:00
file_exists $MYSQLD_DATADIR/mysql_upgrade_info;
2007-04-18 13:21:39 +02:00
2015-12-08 10:13:13 +01:00
--echo Force should run it regardless of whether it has been run before
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force 2>&1
2007-04-18 13:21:39 +02:00
# It should have created a file in the MySQL Servers datadir
2007-12-12 18:19:24 +01:00
file_exists $MYSQLD_DATADIR/mysql_upgrade_info;
2007-04-18 13:21:39 +02:00
#
# Bug #25452 mysql_upgrade access denied.
#
# Password protect a root account and run mysql_upgrade
CREATE USER mysqltest1@'%' IDENTIFIED by 'sakila';
GRANT ALL ON *.* TO mysqltest1@'%';
--echo Run mysql_upgrade with password protected account
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force --user=mysqltest1 --password=sakila 2>&1
2006-11-13 13:39:49 +01:00
2007-04-18 13:21:39 +02:00
DROP USER mysqltest1@'%';
2006-11-13 13:39:49 +01:00
2014-01-22 14:16:57 +01:00
#
# check that we get proper error messages if wrong user
--error 1
--exec $MYSQL_UPGRADE --force --user=mysqltest1 --password=sakila 2>&1
2006-11-13 13:39:49 +01:00
2007-04-18 13:21:39 +02:00
#
# Bug #26639 mysql_upgrade exits successfully even if external command failed
#
--echo Run mysql_upgrade with a non existing server socket
--replace_result $MYSQLTEST_VARDIR var
2012-06-05 13:09:18 +02:00
--replace_regex /.*mysqlcheck.*: Got/mysqlcheck: Got/ /\([0-9|-]*\)/(errno)/
2007-04-18 13:21:39 +02:00
--error 1
2013-03-21 18:21:40 +01:00
# NC: Added --skip-version-check, as the version check would fail when
# mysql_upgrade tries to get the server version.
2013-07-16 19:09:54 +02:00
--exec $MYSQL_UPGRADE --verbose --force --host=not_existing_host --skip-version-check 2>&1
2007-05-19 18:15:08 +02:00
#
# Bug #28401 mysql_upgrade Failed with STRICT_ALL_TABLES, ANSI_QUOTES and NO_ZERO_DATE
#
# The SQL commands used by mysql_upgrade are written to be run
# with sql_mode set to '' - thus the scripts should change sql_mode
# for the session to make sure the SQL is legal.
# Test by setting sql_mode before running mysql_upgrade
set GLOBAL sql_mode='STRICT_ALL_TABLES,ANSI_QUOTES,NO_ZERO_DATE';
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force 2>&1
2007-05-19 18:15:08 +02:00
eval set GLOBAL sql_mode=default;
2009-10-28 11:02:00 +01:00
2009-12-03 17:15:47 +01:00
--echo #
--echo # Bug #41569 mysql_upgrade (ver 5.1) add 3 fields to mysql.proc table
--echo # but does not set values.
--echo #
# Create a stored procedure and set the fields in question to null.
# When running mysql_upgrade, a warning should be written.
CREATE PROCEDURE testproc() BEGIN END;
UPDATE mysql.proc SET character_set_client = NULL WHERE name LIKE 'testproc';
UPDATE mysql.proc SET collation_connection = NULL WHERE name LIKE 'testproc';
UPDATE mysql.proc SET db_collation = NULL WHERE name LIKE 'testproc';
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force 2> $MYSQLTEST_VARDIR/tmp/41569.txt
2009-12-03 17:15:47 +01:00
CALL testproc();
DROP PROCEDURE testproc;
2009-12-04 17:00:20 +01:00
--cat_file $MYSQLTEST_VARDIR/tmp/41569.txt
--remove_file $MYSQLTEST_VARDIR/tmp/41569.txt
2009-12-11 17:40:58 +01:00
2010-07-01 11:05:09 +02:00
--echo #
--echo # Bug #53613: mysql_upgrade incorrectly revokes
--echo # TRIGGER privilege on given table
--echo #
GRANT USAGE ON *.* TO 'user3'@'%';
GRANT ALL PRIVILEGES ON `roelt`.`test2` TO 'user3'@'%';
--echo Run mysql_upgrade with all privileges on a user
2010-09-06 01:15:34 +02:00
--exec $MYSQL_UPGRADE --force 2>&1
2010-07-01 11:05:09 +02:00
SHOW GRANTS FOR 'user3'@'%';
DROP USER 'user3'@'%';
--echo End of 5.1 tests
2010-07-05 12:22:13 +02:00
2009-10-28 11:02:00 +01:00
#
# Test the --upgrade-system-tables option
#
2009-10-29 07:03:16 +01:00
--replace_result $MYSQLTEST_VARDIR var
2011-04-25 17:22:25 +02:00
--exec $MYSQL_UPGRADE --force --upgrade-system-tables
2009-10-28 11:02:00 +01:00
Bug#11827359 60223: MYSQL_UPGRADE PROBLEM WITH
OPTION SKIP-WRITE-BINLOG
System tables were not getting upgraded when
mysql_upgrade was run with --skip-write-binlog
option. (Same for --write-binlog.) Also, with
this option, mysql_upgrade_info file was not
getting created after the upgrade.
mysql_upgrade makes use of mysql client tool in
order to run upgrade scripts, while doing so it
passes some of the command line options (used to
start mysql_upgrade) directly to mysql client.
The reason behind this bug being, some options
like skip-write-binlog and upgrade-system-tables
were being passed to mysql tool along with other
options, and hence mysql execution failed due
presence of these invalid options.
Fixed this issue by filtering out the above mentioned
options from the list of options that will be passed to
mysql and mysqlcheck tools. However, since --write-binlog
is supported by mysqlcheck, this option would be used
explicitly while running mysqlcheck. (not part of patch,
already there)
Checking the contents of general log after the upgrade
is not doable via an mtr test. So performed manual test.
Added a test to verify the creation of mysql_upgrade_info.
client/mysql_upgrade.c:
Bug#11827359 60223: MYSQL_UPGRADE PROBLEM WITH
OPTION SKIP-WRITE-BINLOG
With this patch, --upgrade-system-tables and
--write-binlog options will not be added to the
list of options, used to start mysql and mysqlcheck
tools.
mysql-test/r/mysql_upgrade.result:
Added a testcase for Bug#11827359.
mysql-test/t/mysql_upgrade.test:
Added a testcase for Bug#11827359.
2011-11-15 13:18:42 +01:00
--echo #
--echo # Bug#11827359 60223: MYSQL_UPGRADE PROBLEM WITH OPTION
--echo # SKIP-WRITE-BINLOG
--echo #
let $MYSQLD_DATADIR= `select @@datadir`;
--echo # Droping the previously created mysql_upgrade_info file..
--remove_file $MYSQLD_DATADIR/mysql_upgrade_info
--echo # Running mysql_upgrade with --skip-write-binlog..
--replace_result $MYSQLTEST_VARDIR var
2012-01-16 20:16:35 +01:00
--exec $MYSQL_UPGRADE --skip-write-binlog
Bug#11827359 60223: MYSQL_UPGRADE PROBLEM WITH
OPTION SKIP-WRITE-BINLOG
System tables were not getting upgraded when
mysql_upgrade was run with --skip-write-binlog
option. (Same for --write-binlog.) Also, with
this option, mysql_upgrade_info file was not
getting created after the upgrade.
mysql_upgrade makes use of mysql client tool in
order to run upgrade scripts, while doing so it
passes some of the command line options (used to
start mysql_upgrade) directly to mysql client.
The reason behind this bug being, some options
like skip-write-binlog and upgrade-system-tables
were being passed to mysql tool along with other
options, and hence mysql execution failed due
presence of these invalid options.
Fixed this issue by filtering out the above mentioned
options from the list of options that will be passed to
mysql and mysqlcheck tools. However, since --write-binlog
is supported by mysqlcheck, this option would be used
explicitly while running mysqlcheck. (not part of patch,
already there)
Checking the contents of general log after the upgrade
is not doable via an mtr test. So performed manual test.
Added a test to verify the creation of mysql_upgrade_info.
client/mysql_upgrade.c:
Bug#11827359 60223: MYSQL_UPGRADE PROBLEM WITH
OPTION SKIP-WRITE-BINLOG
With this patch, --upgrade-system-tables and
--write-binlog options will not be added to the
list of options, used to start mysql and mysqlcheck
tools.
mysql-test/r/mysql_upgrade.result:
Added a testcase for Bug#11827359.
mysql-test/t/mysql_upgrade.test:
Added a testcase for Bug#11827359.
2011-11-15 13:18:42 +01:00
# mysql_upgrade must have created mysql_upgrade_info file,
# so the following command should never fail.
--remove_file $MYSQLD_DATADIR/mysql_upgrade_info
2015-10-29 09:05:32 +01:00
--echo #
--echo # Bug #21489398: MYSQL_UPGRADE: FATAL ERROR: UPGRADE FAILED - IMPROVE ERROR
--echo #
--echo Run mysql_upgrade with unauthorized access
--error 1
--exec $MYSQL_UPGRADE --skip-verbose --user=root --password=wrong_password 2>&1
2014-04-28 00:56:53 +02:00
2014-04-28 00:38:03 +02:00
--echo #
--echo # MDEV-4332 Increase username length from 16 characters
--echo # MDEV-6068, MDEV-6178 mysql_upgrade breaks databases with long user names
--echo #
connection default;
GRANT SELECT ON mysql.* TO very_long_user_name_number_1;
GRANT SELECT ON mysql.* TO very_long_user_name_number_2;
GRANT ALL ON *.* TO even_longer_user_name_number_3_to_test_the_grantor_and_definer_field_length@localhost WITH GRANT OPTION;
--change_user even_longer_user_name_number_3_to_test_the_grantor_and_definer_field_length
GRANT INSERT ON mysql.user TO very_long_user_name_number_1;
GRANT INSERT ON mysql.user TO very_long_user_name_number_2;
GRANT UPDATE (User) ON mysql.db TO very_long_user_name_number_1;
GRANT UPDATE (User) ON mysql.db TO very_long_user_name_number_2;
CREATE PROCEDURE test.pr() BEGIN END;
--change_user root
--replace_result $MYSQLTEST_VARDIR var
--exec $MYSQL_UPGRADE --force 2>&1
SELECT definer FROM mysql.proc WHERE db = 'test' AND name = 'pr';
SELECT grantor FROM mysql.tables_priv WHERE db = 'mysql' AND table_name = 'user';
DROP USER very_long_user_name_number_1, very_long_user_name_number_2, even_longer_user_name_number_3_to_test_the_grantor_and_definer_field_length@localhost;
DROP PROCEDURE test.pr;
2017-07-20 15:08:24 +02:00
#
# MDEV-13274 mysql_upgrade fails if dbname+tablename+partioname > 64 chars
#
use test;
2017-08-17 11:32:16 +02:00
call mtr.add_suppression('Column last_update in table `mysql`.`innodb_table_stats` is INT NOT NULL but should be');
2017-07-20 15:08:24 +02:00
alter table mysql.innodb_table_stats modify last_update int not null;
create table extralongname_extralongname_extralongname_extralongname_ext (
id int(10) unsigned not null,
created_date date not null,
created timestamp not null,
primary key (created,id,created_date)
) engine=innodb stats_persistent=1 default charset=latin1
partition by range (year(created_date))
subpartition by hash (month(created_date))
subpartitions 2 (
partition p2007 values less than (2008),
partition p2008 values less than (2009)
);
--exec $MYSQL_UPGRADE --skip-verbose --force 2>&1
select length(table_name) from mysql.innodb_table_stats;
drop table extralongname_extralongname_extralongname_extralongname_ext;
--echo End of 10.0 tests
2017-08-08 10:18:43 +02:00
2015-08-11 18:45:38 +02:00
set sql_mode=default;
2015-09-12 12:16:05 +02:00
#
# Enforce storage engine option should not effect mysql_upgrade
#
--echo # Droping the previously created mysql_upgrade_info file..
--remove_file $MYSQLD_DATADIR/mysql_upgrade_info
create table test.t1(a int) engine=MyISAM;
--echo # Trying to enforce InnoDB for all tables
SET GLOBAL enforce_storage_engine=InnoDB;
--replace_result $MYSQLTEST_VARDIR var
--exec $MYSQL_UPGRADE --force 2>&1
--echo # Should return 2
SELECT count(*) FROM information_schema.tables where ENGINE="InnoDB";
SHOW CREATE TABLE test.t1;
DROP TABLE test.t1;
# mysql_upgrade must have created mysql_upgrade_info file,
# so the following command should never fail.
--remove_file $MYSQLD_DATADIR/mysql_upgrade_info
SET GLOBAL enforce_storage_engine=NULL;
2017-08-08 10:18:43 +02:00
--echo End of 10.1 tests