复制功能作为MySQL/MariaDB实现高可用性的核心，几十年来一直扮演着至关重要的角色。然而，在复制过程中，DBA们经常会遇到一个令人头疼的问题——错误号1236。
1236错误号对DBA并不陌生，相信你看到过这段报错信息：
mysql > show replica status\G
Last_IO_Errno: 13114
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log
这个错误意味着从库无法在主库上找到所需的二进制日志（binlog）和对应的位置（position）或全局事务标识符（GTID）。结果，复制进程会报错并暂停。
造成这种情况的常见原因是：
- 主从同步出现较大延迟。
- 触发了主库上的
binlog_expire_logs_seconds或expire_logs_days变量设置。 - DBA手动执行了
PURGE BINARY LOGS TO 'mysql-bin.00000X'命令。
这些因素都可能导致主库上必要的binlog被删除，从而引发从库无法找到所需的binlog信息，最终导致复制中断（1236错误）。
为了应对这一挑战，MariaDB 11.4版本引入了一个新的参数选项 --slave-connections-needed-for-purge，其默认值为1。这个参数的作用是控制主库清除二进制日志(binlog)的条件。只有当连接到主库的从库数量达到或超过这个指定的阈值时，主库才会执行binlog的清除操作。如果连接的从库数量未达到阈值，主库将禁止清除二进制日志。
让我们以一个具体的例子来说明这个参数的应用:
假设我们有一个由1个主库和3个从库组成的MariaDB复制架构。如果我们将--slave-connections-needed-for-purge参数设置为3，那么只有在以下条件全部满足时，主库才会根据二进制日志的大小来删除旧的日志文件:
- 所有3个从库同时与主库保持连接状态。
- 所有3个从库都在积极地从主库的二进制日志中请求数据。
这种机制确保了在进行日志清理时，所有从库都有机会获取必要的复制数据，从而提高了数据一致性和复制的可靠性。
