A suggestion as part of this if it identifies this state to not start networking so only localhost activity can be carried out - restricts the possibilities of issues from external sources when before or while the upgrade is run. Probably a low-risk issue with many use cases but in time that may be less true.

• +1 to not allow network access while this is going on. That would not be good.
• Also consider providing an option to NOT trigger the upgrade (and possibly not WRITE anything) but just warn if it needs to be done. Sometimes a DBA might want to check without actually touching the db server and they only way to know would be to startup the binaries, so this option might be handy under those circumstances or for people providing support.
• It is probably wise to see how other RDBMSes handle this as I've seen that Sybase and Oracle both will do automatic upgrades on startup and it might be interesting to see if there's anything else that might also need to be taken into account.
• See: http://bugs.mysql.com/bug.php?id=68834 as this is related. I would like to see a table containing this upgrade info (or an append only csv file etc) containing the timestamp, hostname, new mysql version and old mysql version and results of the attempted upgrade (success/failure etc) so that we have some auditing history of the upgrade processes on servers. This is currently not very visible and if you go through several binary upgrades that history can be quite informative.

In MySQL 8.0, this can be done with the --upgrade option.

https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_upgrade