在MySQL半同步复制环境中提交大事务时，常因Binlog传输所需时间过长而导致半同步超时。这会使半同步复制降级为异步复制，引致数据可靠性下降，同时阻塞后续事务，造成业务性能抖动。为解决此问题，RDS MySQL推出了Binlog实时传输功能。该功能可以在大事务执行过程中就将其Binlog流式传输至备库，从而在事务提交时将同步耗时降至毫秒级，保障数据高可靠与业务性能的稳定。
功能简介
背景信息
原生MySQL主备之间依赖单一通道传输Binlog。当一个大事务的Binlog占据该通道时，会阻塞其后所有事务的Binlog传输，导致主库上等待提交的事务大量堆积，实例出现短暂的不可写。为了避免服务长时间不可用，MySQL引入了rpl_semi_sync_master_timeout参数。若Binlog在规定时间内未获得备库确认，半同步复制便会退化为异步复制。因此，大事务可能引发两个核心问题：
性能抖动：实例出现秒级不可写，大量提交请求成为慢SQL。
可靠性下降：复制模式降级，极端场景下可能丢失数据。
RDS MySQL Binlog实时传输
传统模式下，事务的Binlog在执行期间暂存于主库的Binlog Cache，直到事务提交时才一次性写入Binlog文件并发送至备库。RDS MySQL的Binlog实时传输功能优化了这一过程。对于超过特定阈值的大事务，该功能会将生成的Binlog Event从Binlog Cache中持续地发送到备库，暂存在备库的Relay Log Cache中。当主库事务提交时，只需发送一个“提交”指令，备库即可快速将缓存数据写入Relay Log文件并返回确认。通过这种“边执行边传输”的流式设计，大事务提交时的Binlog传输耗时从数秒缩短至毫秒级，有效避免了传输瓶颈。
技术原理：Relay Log Cache的设计
为在备库上暂存实时传输的Binlog Event，RDS MySQL为每个大事务设计了独立的Relay Log Cache。在写入数据前，系统会在Cache头部预留一段空间，用于后续填充Relay Log Event的Header信息，从而实现从Cache到Relay Log文件的快速转换。当预留空间不足或富余时，系统会通过回退到原有逻辑或填充Empty Event等方式智能处理，确保机制的健壮性。
适用范围
数据库版本：RDS MySQL 8.0
内核小版本：20250531及以上
使用说明
您可以同时在主库和备库分别设置以下全局参数来开启该功能。参数修改立即生效，无需重启实例。
开启方式：
主库：
loose_binlog_realtime_transmit_source_enabled=ON备库：
loose_binlog_realtime_transmit_replica_enabled=ON
核心参数：
loose_binlog_realtime_transmit_long_transaction_limit_size作用：定义触发实时传输的事务大小阈值。当一个事务产生的Binlog超过该值，其实时传输功能便会自动激活。
默认值：128 MB。
优化效果
通过在半同步复制实例上叠加一个2 GB的大事务来模拟高负载场景。测试结果如下图所示：
优化前（原生MySQL）：提交大事务后，实例的QPS瞬间降至零，性能出现严重波动。随后，由于半同步超时，系统降级为异步模式，性能虽然有所回升，但数据的可靠性却降低。
优化后（RDS MySQL）：开启Binlog实时传输后，即使在提交大事务期间，实例QPS始终保持平稳，有效避免了性能抖动和复制模式降级。
