--no-defaults in mysql_install_db can prevent server startup

Bug #1195000 reported by Stephane VAROQUI
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Sandbox
Invalid
Undecided
Unassigned

Bug Description

MySQL-Sandbox-3.0.25

low_level_make_sandbox --force --no_show -c server-id=5054 --db_user=skysql --db_password=skyvodka -d db-78b9ef7a --sandbox_port=5054 --upper_directory=/var/lib/skysql --install_version=5.5 --no_ver_after_name --basedir=/usr/local/skysql/mariadb -v -m /usr/local/skysql/ncc/etc/maria.template

This call
/usr/local/skysql/mariadb/scripts/mysql_install_db --no-defaults --user=root --basedir=/usr/local/skysql/mariadb --datadir=/var/lib/skysql/db-78b9ef7a/data

This create

InnoDB: Setting log file ./ib_logfile0 size to 5 MB

then MariaDB 10 wan't start because the redo log are set to different size inside my_file /usr/local/skysql/ncc/etc/maria.template

propose fix :
--- /home/svar/src/MySQL-Sandbox-3.0.25/bin/low_level_make_sandbox.old 2013-06-26 16:24:23.722830225 +0200
+++ /home/svar/src/MySQL-Sandbox-3.0.25/bin/low_level_make_sandbox 2013-06-26 16:29:58.670824875 +0200
@@ -528,8 +528,9 @@
         }

         my $additional_options ="$osx_options";
- my $cmd = sprintf '%s --no-defaults --user=%s --basedir=%s --datadir=%s/data',
+ my $cmd = sprintf '%s --defaults-file=%s --user=%s --basedir=%s --datadir=%s/data',
             $script,
+ $msb->{options}{my_file},
             $msb->{options}{operating_system_user},
             $msb->{options}{basedir},
             $sandbox_directory;

Revision history for this message
Giuseppe Maxia (giuseppe-maxia) wrote :

MySQL Sandbox already supports MariaDB 10 using make_sandbox.
Further support may be provided when MariaDB 10 becomes more stable.

Usage of low_level_make_sandbox standalone is discouraged.

 make_sandbox ./downloads/mariadb-10.0.1-linux-x86_64.tar.gz
unpacking /home/tungsten/downloads/mariadb-10.0.1-linux-x86_64.tar.gz
Executing low_level_make_sandbox --basedir=/home/tungsten/downloads/10.0.1 \
 --sandbox_directory=msb_10_0_1 \
 --install_version=10.0 \
 --sandbox_port=10001 \
 --no_ver_after_name \
 --my_clause=log-error=msandbox.err
    The MySQL Sandbox, version 3.0.38
    (C) 2006-2013 Giuseppe Maxia
installing with the following parameters:
upper_directory = /home/tungsten/sandboxes
sandbox_directory = msb_10_0_1
sandbox_port = 10001
check_port =
no_check_port =
datadir_from = script
install_version = 10.0
basedir = /home/tungsten/downloads/10.0.1
tmpdir =
my_file =
operating_system_user = tungsten
db_user = msandbox
remote_access = 127.%
bind_address = 127.0.0.1
ro_user = msandbox_ro
rw_user = msandbox_rw
repl_user = rsandbox
db_password = msandbox
repl_password = rsandbox
my_clause = log-error=msandbox.err
master =
slaveof =
high_performance =
prompt_prefix = mysql
prompt_body = [\h] {\u} (\d) >
force =
no_ver_after_name = 1
verbose =
load_grants = 1
no_load_grants =
no_run =
no_show =
do you agree? ([Y],n) y
loading grants
. sandbox server started
Your sandbox server was installed in $HOME/sandboxes/msb_10_0_1

Changed in mysql-sandbox:
status: New → Invalid
Revision history for this message
Stephane VAROQUI (svar) wrote :

Giuseppe,

The issue is not about MariaDB it happen on MySQL as well just when you wan't to start a sandbox with you own configuration file , that configuration is not pass to the system MySQL install script and redo log may then be of different size preventing the server to start

May be it is not a supported feature to create Sanboxes on custom configuration file like this ?

Thanks

Revision history for this message
Giuseppe Maxia (giuseppe-maxia) wrote :

Stephane,
the conflict that happens in this case will be easily resolved by removing the redo files before restarting. A similar problem arises if your ibdata file has different sizes.

Allowing the bootstrap with indiscriminate option files will create more problems than what this case shows. A better solution should be to check that properties from a custom options file do not clash with the defaults.

Since the proposed patch is certainly dangerous, while a simple workaround exists, I won't take action on this issue now, but I will introduce an options check for the next release.

Revision history for this message
Stephane VAROQUI (svar) wrote :

Giuseppe,

Thanks for the effort have a good WE .

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.