Cloud SQL技术问题：副本实例复制失败但存储每日持续增长

咱们一步步拆解你的问题，先搞定存储增长的排查，再解释那些看起来反常的InnoDB写入操作：

一、核心排查步骤：找出存储增长的源头 #

1. 先检查复制相关的中继日志（Relay Log） #

这是最容易被忽略的点——虽然你的副本实例禁用了二进制日志，但中继日志（Relay Log）是独立的，专门用来存储从主库拉取的binlog内容。如果复制失败（SQL_THREAD卡住），但IO_THREAD还在正常拉取主库的日志，中继日志会不断堆积，每天5GB的增长很可能来自这里。

• 执行命令查看复制状态：

  SHOW SLAVE STATUS\G
  

  重点看Relay_Log_Space字段，这个数值就是所有中继日志的总大小，如果持续攀升，那就是它在搞鬼。
• 另外，也可以查中继日志的存储位置：

  SHOW VARIABLES LIKE 'relay_log';
  

2. 检查InnoDB的内部日志与表空间 #

即使没有用户数据变更，InnoDB的后台操作也可能产生大量写入，尤其是复制异常时：

• 查看undo表空间的情况：

  SELECT @@innodb_undo_tablespaces;
  SHOW TABLESPACE STATUS;
  

  如果复制过程中出现事务失败、回滚，undo日志会堆积，占用存储空间。
• 查看redo日志的大小与配置：

  SHOW VARIABLES LIKE 'innodb_log_file_size';
  SHOW VARIABLES LIKE 'innodb_log_files_in_group';
  

  虽然redo日志是循环使用的，但如果复制异常导致日志刷新异常，也可能出现临时的增长。
• 执行InnoDB状态命令，找异常信息：

  SHOW ENGINE INNODB STATUS;
  

  重点看TRANSACTIONS和BUFFER POOL AND MEMORY板块，有没有未完成的事务、脏页堆积的情况。

3. 检查系统级日志文件 #

Cloud SQL的错误日志、慢查询日志如果没有自动轮转，也可能无限增长：

• 查找错误日志路径：

  SHOW VARIABLES LIKE 'log_error';
  

  通过Cloud SQL控制台的Logs页面查看日志大小，或者用gcloud sql instances describe my-instance输出中的settings.logsConfig字段确认日志配置。

4. 验证备份配置的实际状态 #

你提到创建实例默认启用PITR，但当前实例没有备份记录、backUpConfiguration也不在describe结果中：

• 先确认副本的二进制日志是否真的禁用：

  SHOW VARIABLES LIKE 'log_bin';
  

  PITR的启用依赖二进制日志，如果log_bin为OFF，PITR实际上是无法工作的，所以备份配置显示false是正常的。
• 另外，如果你是通过克隆主库创建的副本，可能继承了主库的备份配置，但如果主库本身没启用PITR，副本也会保持这个状态。

二、解释：为什么有InnoDB写入峰值但无读取？ #

你看到的InnoDB写入操作，大概率和复制过程中的后台处理有关：

• 当IO_THREAD拉取主库的binlog到中继日志后，SQL_THREAD尝试应用日志时如果失败，InnoDB会生成undo日志来记录回滚信息，这会产生写入操作，但因为事务没成功应用，所以没有对应的读取操作。
• 即使SQL_THREAD完全停止，InnoDB的后台purge线程可能仍在清理旧的undo页，或者缓冲池的脏页刷新（比如innodb_flush_log_at_trx_commit配置导致的定时刷新），这些都会产生写入，但不会触发用户层面的读取。
• 如果主库有DDL操作，副本收到后尝试执行但失败，InnoDB在处理DDL的过程中（比如创建临时表空间、修改元数据）也会产生写入，但因为DDL失败，没有后续的读取操作。

临时缓解方案 #

如果确认是中继日志堆积，可以先停止复制（STOP SLAVE;），清理旧的中继日志（PURGE RELAY LOGS BEFORE NOW();），然后排查复制失败的根本原因（比如主从数据不一致、权限问题、SQL兼容性问题），修复后再启动复制（START SLAVE;）。

内容的提问来源于stack exchange，提问作者Cat Named Dog