我们在 MySQL RDS 服务器上创建了只读副本，并且我们的主实例启用了多可用区，当我们尝试强制故障转移测试时，我们的只读副本的 IO 线程停止了，我们得到
Error 1236 fatal error 我们的二进制日志已损坏。
为避免此副本失败，必须启用 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1，但如果我们按照建议设置这些变量，则它会将我们的写入操作降低 50% - 60%。
有什么方法可以避免这种复制错误，而不是设置高于推荐值，否则如果有必要根据推荐进行设置，那么请建议我们如何改进写入操作？
【问题讨论】：
标签： mysql amazon-web-services innodb rds
这个答案一般适用于 MySQL 复制，而不仅仅是 AWS。
如果您接近超出系统的容量，您需要认真研究发生了什么。
简短的回答是将多个交易（在可行的情况下）合并为一个。 innodb_flush_log_at_trx_commit=1 在每个事务结束时都涉及一个“额外的”fsync。因此，更少的事务 --> 更少的 I/O --> 更少的争用。
在我明白发生了什么之前，我选择了sync_binlog=0。当某些东西确实崩溃时，二进制日志实际上并没有“损坏”，但奴隶会指向一个“不可能的位置”。这是因为位置信息在实际写入 Master 上的磁盘之前已经发送到 Slave。解决方案很简单：将指针（在 Slave 上）移动到下一个 binlog（在 Master 上）的开头（Pos=0 或 4）。
我怀疑（没有任何真实证据）innodb_flatc 比 sync_binlog 对性能的影响更大。
现在介绍一些 AWS 细节。如果“多可用区”意味着每个磁盘写入都在写入两个不同数据中心的机器，那么问题不仅仅是您提出的两个设置。相反，如果这意味着从站远离主站，那么它的行为就像普通的 MySQL 复制（对于这个问答）。
【讨论】：
innodb_flush_log_at_trx_commit=2 和sync_binlog =1，然后我的写入性能下降了，当我们将其设置为 50 或 0 时，它再次使我们恢复了性能.