应从生成、保留、转移三端控制Binlog：设binlog_expire_logs_seconds为2592000，max_binlog_size为1GB；用mysqlbinlog+inotifywait自动同步至OSS，重命名含实例ID/日期/序号/起止pos，并校验sha256sum。
Binlog 日志爆满导致磁盘写满怎么办
MySQL 的 binlog 不设限增长，是线上最常触发磁盘 100% 的元凶之一。不是靠“定期删”，而是必须从生成、保留、转移三端同时控制。
-
expire_logs_days已被弃用（8.0.11+），必须改用binlog_expire_logs_seconds，设为2592000（30 天）才真正生效 - 单纯调大过期时间没用——如果主库写入量极大，
binlog在过期前就已占满磁盘，得配合max_binlog_size控制单文件上限（建议1073741824，即 1GB） - 删除动作本身会阻塞 DDL，用
PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00'比按天数更可控，但务必在低峰执行
怎么把 Binlog 自动同步到 OSS，不卡主库
不能用 mysqldump 或 SELECT … INTO OUTFILE，那是全量导出；Binlog 是增量流式日志，必须靠 mysqlbinlog + 后台拉取 + 分段上传。
- 用
mysqlbinlog --read-from-remote-server --host=xxx --user=xxx --password=xxx --raw --stop-never --result-file=/tmp/binlog/拉取，注意加--stop-never和--raw，否则无法持续追加且格式错乱 - 每生成一个
mysql-bin.0000xx文件，就立刻用ossutil cp /tmp/binlog/mysql-bin.0000xx oss://my-bucket/binlog/上传，传完立即rm，避免本地堆积 - 别用 Python 脚本轮询
SHOW BINARY LOGS来判断新文件——有延迟、易漏、还增加主库压力；直接监听文件系统事件（inotifywait）更稳
OSS 上 Binlog 文件怎么命名才方便回溯
默认的 mysql-bin.000001 在 OSS 上毫无上下文，恢复时根本不知道它属于哪天、哪个实例、有没有被截断。
- 重命名规则必须含三要素：
实例ID_日期_序号_起始pos_结束pos，例如rm-bp1abc123_20240615_000001_154_123456789 - 起始 pos 从
mysqlbinlog -v --base64-output=DECODE-ROWS mysql-bin.000001 | head -20里取# at行；结束 pos 用mysqlbinlog -v mysql-bin.000001 | tail -20 | grep '# at' | tail -1 - OSS 不支持原子重命名，上传后要写一个
.meta.json文件存校验值和时间戳，否则遇到断点续传或网络抖动，无法判断文件是否完整
扩容 Binlog 存储时，为什么新加的磁盘经常不生效
MySQL 不会自动识别新挂载的磁盘路径，log_bin 路径一旦初始化就锁定，改配置重启也不行——除非重建 Binlog 索引。
- 先停写，执行
FLUSH LOGS，确保当前mysql-bin.0000xx写满并滚动 - 修改
my.cnf中的log_bin指向新路径（如/data2/mysql/binlog/mysql-bin），然后mysqld --initialize-insecure不适用——正确做法是：停库 → 移动旧 binlog 文件到新路径 → 修改auto.cnf和mysql-bin.index里的路径引用 → 启动 - 验证是否生效：看
SHOW VARIABLES LIKE 'log_bin_basename';返回值，以及ls -l /proc/$(pidof mysqld)/fd/ | grep binlog是否指向新路径
归档链路里最容易被跳过的环节，是校验 OSS 上文件和本地原始文件的 sha256sum 是否一致。只要有一次上传中断没检测，后面拿它做 PITR 就是赌运气。
