Documentation enhancement request- mysql

[Kevin M. Hildebrand]

I might have missed it, but I didn't see any place in the SLURM install docs that mention that InnoDB is a requirement when using MySQL.
I've just spent a couple of hours debugging why when using sacctmgr, answering "no" to any of the commit questions is the same as answering "yes".
It turns out that my MySQL default engine is MyISAM, which doesn't support transactions, so rollbacks on "no" responses don't work.
The most frustrating part is that MySQL runs along happily without any warnings to tell you that all of the transaction controls are being ignored.

So, I'd suggest adding a warning to the install docs that InnoDB is required and must be the default when the tables are initially created.

Thanks!
Kevin

--
Kevin Hildebrand
Division of IT
University of Maryland, College Park

[Danny Auble]

This has been added to the accounting web page. Thanks for the note. I
agree with the frustration of MySQL just chirping right along, no error
is even given when we specifically set the engine to InnoDB. Hopefully
this has only bitten a couple of people, and hopefully the documentation
update will help others.

Danny

Post by Kevin M. Hildebrand
I might have missed it, but I didn't see any place in the SLURM
install docs that mention that InnoDB is a requirement when using MySQL.
I've just spent a couple of hours debugging why when using sacctmgr,
answering "no" to any of the commit questions is the same as answering
"yes".
It turns out that my MySQL default engine is MyISAM, which doesn't
support transactions, so rollbacks on "no" responses don't work.
The most frustrating part is that MySQL runs along happily without any
warnings to tell you that all of the transaction controls are being
ignored.
So, I'd suggest adding a warning to the install docs that InnoDB is
required and must be the default when the tables are initially created.
Thanks!
Kevin
--
Kevin Hildebrand
Division of IT
University of Maryland, College Park

[Christopher Samuel]

Post by Kevin M. Hildebrand
I might have missed it, but I didn't see any place in the SLURM
install docs that mention that InnoDB is a requirement when using
MySQL.

I'd suggest that for these cases it should use Engine=InnoDB when
creating MySQL tables, that way you don't need to remember.

All the best,
Chris
- --
Christopher Samuel Senior Systems Administrator
VLSCI - Victorian Life Sciences Computation Initiative
Email: samuel-***@public.gmane.org Phone: [phone]
http://www.vlsci.org.au/ http://twitter.com/vlsci

[Danny Auble]

That is exactly what it does. Evidently if innodb isn't there it just goes along quietly without issue without innodb.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Kevin M. Hildebrand
I might have missed it, but I didn't see any place in the SLURM
install docs that mention that InnoDB is a requirement when using
MySQL.

I'd suggest that for these cases it should use Engine=InnoDB when
creating MySQL tables, that way you don't need to remember.
All the best,
Chris
- --
Christopher Samuel Senior Systems Administrator
VLSCI - Victorian Life Sciences Computation Initiative
http://www.vlsci.org.au/ http://twitter.com/vlsci
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO16RsACgkQO2KABBYQAh8I2wCeMQUiMlrDsCMV4kuMHUZig+Ld
b5IAniZ2PuWHp4hRXCK7NZwC+ywMAeEH
=rqjS
-----END PGP SIGNATURE-----

[Christopher Samuel]

That is exactly what it does. Evidently if innodb isn't there it
just goes along quietly without issue without innodb.

Wow, I'd assumed it would report an error in that case, but apparently
not. This describes what happens and how to get it to fail instead.

http://dev.mysql.com/doc/refman/5.6/en/storage-engine-setting.html

# By default, a warning is generated whenever CREATE TABLE or
# ALTER TABLE cannot use the default storage engine. To prevent
# confusing, unintended behavior if the desired engine is
# unavailable, enable the NO_ENGINE_SUBSTITUTION SQL mode. If
# the desired engine is unavailable, this setting produces an
# error instead of a warning, and the table is not created or
# altered. See Section 5.1.7, “Server SQL Modes”.

cheers!
Chris
- --
Christopher Samuel Senior Systems Administrator
VLSCI - Victorian Life Sciences Computation Initiative
Email: samuel-***@public.gmane.org Phone: [phone]
http://www.vlsci.org.au/ http://twitter.com/vlsci

[Danny Auble]

Thanks for the tip Chris, I hadn't noticed it before. It is committed
in 14.11 commit da24acfc359ef9e28866c82fb9f9e9880235fcaa

The DBD will now print a nice error about InnoDB not existing and halt
if it isn't available.

Danny

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That is exactly what it does. Evidently if innodb isn't there it
just goes along quietly without issue without innodb.

Wow, I'd assumed it would report an error in that case, but apparently
not. This describes what happens and how to get it to fail instead.
http://dev.mysql.com/doc/refman/5.6/en/storage-engine-setting.html
# By default, a warning is generated whenever CREATE TABLE or
# ALTER TABLE cannot use the default storage engine. To prevent
# confusing, unintended behavior if the desired engine is
# unavailable, enable the NO_ENGINE_SUBSTITUTION SQL mode. If
# the desired engine is unavailable, this setting produces an
# error instead of a warning, and the table is not created or
# altered. See Section 5.1.7, “Server SQL Modes”.
cheers!
Chris
- --
Christopher Samuel Senior Systems Administrator
VLSCI - Victorian Life Sciences Computation Initiative
http://www.vlsci.org.au/ http://twitter.com/vlsci
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO2HdIACgkQO2KABBYQAh+x+gCfcA8tzRbYvK3X+kZz3DSQgohS
i6AAn1I72z5GRUCEnN+qncD3Dgxz3269
=I5Bo
-----END PGP SIGNATURE-----

[Christopher Samuel]

Post by Danny Auble
Thanks for the tip Chris, I hadn't noticed it before. It is
committed in 14.11 commit da24acfc359ef9e28866c82fb9f9e9880235fcaa
The DBD will now print a nice error about InnoDB not existing and
halt if it isn't available.

Wonderful, thanks so much!

- --
Christopher Samuel Senior Systems Administrator
VLSCI - Victorian Life Sciences Computation Initiative
Email: samuel-***@public.gmane.org Phone: [phone]
http://www.vlsci.org.au/ http://twitter.com/vlsci