MySQL 5.7 DMR5 Release Notes – what we know so far

The release notes for MySQL 5.7 DMR5 are starting to take shape on dev.mysql.com.

For me, what is one of the most exciting changes is that “Strict SQL mode is now enabled by default for transactional storage engines”. This aligns very nicely with a post I wrote just recently about transitioning changes using initially a whitelist and then a blacklist.

User’s with legacy applications still be able to opt-out of STRICT mode, but importantly new applications won’t be accidentally trapped into sub-optimal defaults.

Published by

morgo

I joined MySQL AB in 2006, left, and am now back at Oracle working on the MySQL team. I’ve also worked at Percona and InPowered.

  • Simon J Mudd

    If we’re going to look at transitioning new variables then I’d like to see this one’s default changed. Logging from 5.6.X on restarting MySQL:

    2014-09-13 16:45:06 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).

    It’s no good to state that a value will be deprecated at some time in the future without actually doing something about it. The optional new 5.6 behaviour is good, but we have to be careful with those systems still replicating with a MySQL 5.5 master. Ideally if the master version is known the SQL thread should mimic 5.5 behaviour, or we just temporarily _explicitly_ set this value explicit_defaults_for_timestamp=0 for backwards compatibility.

    Either way leaving the new functionality disabled by default means that this like other features may get left off when they are indeed good, even if the new behaviour is different from previous behaviour.

    So my vote in 5.7 would be for explicit_defaults_for_timestamp would be:
    (1) for it to have a default value of 1
    (2) for the SQL thread if it can know the upstream master runs 5.6 or earlier, to behave as if the value were set to 0.

    (3) in MySQL 5.7 only (given this is a change) on startup to log that the value is different from previous major versions and the DBA should pay attention to this.

    I’d also suggest that MySQL 5.7 logs something about the fact that in 5.7 the behaviour of sql_mode has changed on startup too. That gives a bit of noise, enough for a single major MySQL release for people to not have it slip by and cause issues. I’m pretty certain that the sql_mode is passed downstream so you may not notice the change in behaviour until switching to a new 5.7 master, so making this warning visible gives people a bit of time to adjust their configuration if needed prior to the 5.7 switch which might surprise them.

    • These are great suggestions! Thank you for sharing.