This is a good call out. Data corruption is always possible due to software, firmware, hardware bugs and failures... but that’s not specific to OOMs. You coul

This is a good call out. Data corruption is always possible due to software, firmware, hardware bugs and failures... but that’s not specific to OOMs. You could have non-crash safe settings like sync_binlog != 1 or innodb_flush_log_at_trx_commit != 1, but with the default settings of MySQL 8.0 it’s entirely crash safe in every way (binlog events etc). I think that part of the post needs to be updated. It was a bit of an off-handed comment but it's not as clear and accurate as it should be. I’m going to replace `potential data corruption` with `potential downtime` as it could initiate a failover and the process will have to restart and go through crash recovery which can take some time.