简单来说，我有一个独立 mysql 实例在托管于可抢占节点。这意味着至少每 24 小时，底层节点就会被杀死一次，并且永远无法保证彻底关闭。
在采用这种方式之前，我通过在不同负载下模拟此场景、执行写入操作以及通过触发内核恐慌来杀死底层节点来测试设置：即使经过数千次重启也没有问题。
在现实世界中，有时 - 比如说每月超过 3000 个 mysql 实例 - 一个数据库会损坏，并且需要恢复（强制恢复、完全转储、重新加载转储）。
我可以配置哪些最佳选项来确保 mysql 以某种方式运行，即使服务器频繁关闭，也不会写入不一致的数据？牺牲性能不是问题。
该磁盘是 Google 云计算引擎的“标准持久磁盘”。这是它当前的配置（mysql 在 docker 上运行，因此需要aio = 关闭)：
max_connections = 60
innodb_buffer_pool_size = 16M
tmp_table_size = 4M
key_buffer_size = 8M
query_cache_size = 4M
query_cache_limit = 512K
thread_stack = 128K
performance_schema = 0
show_compatibility_56 = 1
innodb-use-native-aio = OFF
我正在寻找 my.cfg 设置以使 mysql 尽可能防崩溃，而不是架构解决方案
编辑 25/03/21我目前正在测试以下内容：
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_flush_method = O_DIRECT
前两个是默认的，只是为了确保万无一失而添加的。看起来 O_DIRECT 是距离目标更近一步。有关 mysql 写入 google 云盘和数据同步技术的有趣文档：https://dotmanila.com/2017/09/o_dsync-flush-method-for-mysql-on-google-cloud/
答案1
每个 3K 实例有 3 台服务器。这些 9K MySQL 实例可以位于虚拟机或 docker 或其他任何位置。
但是...每个数据集的 3 个实例必须位于 3 个地理位置。并且位于这 3 个节点的 Galera 集群中。（InnoDB 集群是另一种选择。）
任何实例都可能被突然终止。它既可以恢复，也可以用一台“空”机器代替。Galera 将恢复——通过增量更新 (IST) 恢复的实例或从头开始 (SST)。
即使整个数据中心瘫痪，也应该可以完全恢复。该数据中心可能拥有 3K 集群中的每个节点，但它一定不任何集群都有两个节点。
它可以处理任何“单点故障”——磁盘、服务器、甚至数据中心。
甚至可以说，这消除了对磁盘 RAID-1/5/6/10 的需求。
我还没有考虑清楚所有的细节，但我认为分布在 5 个数据中心的 5 个 Galera 节点对于任何 2 个故障点来说都是完全安全的。
不要忘记担心网络故障。例如，数据中心是否有二电缆是否连接到互联网（或私人电缆）？软件是否失败。