> Corruption in the sense of allowing data that is invalid ( clobbering valid data even on transaction error) is corruption by my definition. OK. Do you have a

> Corruption in the sense of allowing data that is invalid ( clobbering valid data even on transaction error) is corruption by my definition. OK. Do you have any examples of a modern version of MySQL or InnoDB doing this? > how many people have avoided upgrading to 5.7 because of this change As I said, 5.7 just changed the default. This setting has been available since mysql 5.0.2 in early 2004 -- it just wasn't the default. Or you can use 5.7 and override the new default to get the old unsafe behavior. This change is absolutely a non-issue in terms of avoiding upgrades. > other issues regarding the new revamped query planner which makes software like Zabbix slow to a crawl I have heard of very few issues from the query planner improvements. Anecdotal, sure, but I am pretty "in the loop" fwiw. > Ah, the old "it's not a footgun if you know better" argument. How is that my argument? I directly said "I agree this could be improved to be less of a footgun for new users"! The database won't force read_only for replicas because there are replication topologies (e.g. master-master) where nodes are replicating but also still need to be directly writable. These topologies are a bad practice (IMO) but nonetheless are used by enough places that MySQL cannot simply force read_only for replicas. In any case, these days administrators who are completely unfamiliar with MySQL replication concepts should probably be using a DBaaS rather than setting up replication manually. The DBaaS platforms enforce read_only properly, making this all a non-issue.