我们的主服务器上只有 450 GB 的 nvme 空间，并且 binlog 占用了大量空间，即使它们只保存两天。
将 MySQL binlog 写入较慢的磁盘（例如远程目录）会降低 MySQL 的性能吗？
答案1
二进制日志记录在语句或事务完成后立即完成，但在释放任何锁或完成任何提交之前，因此我想象将日志放在较慢的磁盘上可能会产生影响，因为其他事务将被延迟，直到当前事务被记录下来。
我会将您的二进制日志保存在最快的存储器中，但通过仅保留仍然需要复制的日志来减少闪存驱动器上的日志量。
您可以自动化并更频繁地运行清除日志的程序按照手册中概述的步骤删除所有不再需要的日志，因为从属服务器已经处理了它们。
在每个从属服务器上，用来
SHOW SLAVE STATUS检查它正在读取哪个日志文件。使用 获取主服务器上的二进制日志文件列表
SHOW BINARY LOGS。确定所有从属服务器中最早的日志文件。这是目标文件。如果所有从属服务器都是最新的，则这是列表中的最后一个日志文件。
备份您要删除的所有日志文件。（此步骤是可选的，但始终建议这样做。）
清除所有日志文件，但不包括目标文件。
如果您想要保留更多日志（例如出于审计目的），请在步骤 4 中将这些日志复制到速度较慢（旋转）的磁盘，然后再使用PURGE BINARY LOGS TO或PURGE BINARY LOGS BEFOREMySQL 语句将它们从闪存驱动器中删除。
答案2
默认情况下，每次写入时二进制日志都会同步到磁盘 （
sync_binlog=1）。如果未启用 sync_binlog，并且操作系统或计算机（不仅是 MySQL 服务器）崩溃，则二进制日志的最后语句可能会丢失。为了防止这种情况，请启用 sync_binlog 系统变量，以便在每 N 个提交组之后将二进制日志同步到磁盘。请参见第 5.1.8 节“服务器系统变量”。sync_binlog 的最安全值是 1（默认值），但这也是最慢的。
上述引文的粗体部分意味着缓慢的存储将限制您的 INSERT 速率。作为部分缓解措施，binlog 是按顺序写入的，因此您无需为寻道延迟付费。
使用单个 7200 RPM 磁盘作为专用 binlog 设备的示例：平均旋转延迟约为 4.1 毫秒，每秒可预期约 250 次写入 I/O。这显然假设磁盘端没有 NVRAM/写回缓存：如果存在这样的缓存，则同步写入会立即被其吸收。
还请注意，您可以禁用 binlog 同步，基本上将问题从延迟限制转变为吞吐量限制。但一定要了解这对数据一致性意味着什么。