3
This behaviour is described in explicit_defaults_for_timestamp system variable which is by default disabled for 5.6,5.7 (and effectively disabled on 5.1) and it is enabled in 8.0.
Quoting from above link:
(5.7) If explicit_defaults_for_timestamp is disabled, the server enables
the nonstandard behaviors and handles TIMESTAMP columns as follows:
...
1
SELECT 1 Start, t1.time `Start Time`, 0 Stop, MIN(t2.time) `Stop Time`
FROM src_table t1
JOIN src_table t2 ON t2.time > t1.time AND t2.ign = 0
GROUP BY t1.time
WHERE t1.ign = 1
1
Perhaps a better policy:
When registering a user, store the fee charged into the user's history.
Derive the fee from some business logic that may or may not be stored in a database table.
Note how this policy freezes the fee as soon as it is billed. This is safer than having it in some other table that might accidentally be changed for unrelated reasons.
1
Settings in my.cnf (etc) are seen only when mysqld starts up.
Settings changed by SET GLOBAL... are not seen until someone logs in. But, such settings go away when mysqld is restarted. (This item probably explains what you encountered.)
Settings changed for the "session" last only for that one connection, and only until disconnecting.
(MySQL 8.0 has ...
1
(re: MySQL/MariaDB) It depends.
For small columns, say under 1KB, don't bother with the hash.
For large columns, say over 7KB, it may not matter -- InnoDB puts large columns "off-record" in a block separate from the main part of the record.
For medium-sized columns, say 1KB-7KB, the column is likely to be kept "on record", thereby making any action on the ...
1
FLUSH LOGS gracefully does most of what you want. It stops writing to a log, renames the file and starts a new one. After that, you can deal with copying/moving/archiving/etc the files.
FLUSH LOGS can be run at any time without damaging anything or losing any log entries.
Caveat: There are many different log files; FLUSH may not work the same way on ...
1
Answering my own question, in case other might benefit.
The explanation, it turns out, was that although the upgrade succeeded, the restart of the daemon had failed silently. It took a kill -9 and systemctl start mysql to sort that out.
Only top voted, non community-wiki answers of a minimum length are eligible
