我刚刚阅读了这篇关于 MySQL 上的中继日志空间限制的博客文章。我确信“无限”默认设置确实不是很好。但是我如何为它选择一个好的价值呢?
如果这很重要,我们正在使用主-主循环复制。
这将取决于四(4)个因素
Relay_Log_Space
from 的任何监控做出反应的速度有多快SHOW SLAVE STATUS\G
(请参阅我的Feb 09, 2012
帖子以编程方式测试从站状态 - SHOW SLAVE STATUS 中的哪些字段指示从站状态正常/错误?在relay_log_space_limit 上)随着Relay_Log_Space
深远relay_log_space_limit
没有日志发生旋转,直到最古老的继电器每个SQL语句进行处理。
如果 SQL 线程由于某些 SQL 错误而中断怎么办?您需要使用 设置的天数来解决错误expire_logs_days
。如果错过了这一点,当修复复制时,下载到中继日志但从主服务器旋转的 SQL 将不会使其成为从服务器。如果不修复,中继日志只会增长,因为 IO 线程仍然会启动并从 Master 收集新的 SQL。
如果 IO 线程由于某些通信错误而中断怎么办?如果最后一个中继日志在逻辑上被破坏(一种可能性),这可能会更加关键。一旦知道 Master 和 Slave 之间的通信正常,你必须得到
Relay_Master_Log_File
(如 mysql-bin.000128)Exec_Master_Log_Pos
(比如 82323232)从SHOW SLAVE STATUS\G
. 使用这些命令进行清理
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='mysql-bin.000128',
MASTER_LOG_POS=82323232;
START SLAVE;
Run Code Online (Sandbox Code Playgroud)
这将清除所有中继日志并重新开始。
我有一个 DB Hosting 客户端,它每 18 分钟生成一个完整的 1GB 二进制日志(是的,每天 80GB)。由于客户端的 expire_logs_days = 3,客户端每天有 240 GB。
想象一下上面的场景,并在没有适当的警报或中继日志的足够磁盘空间的情况下尝试处理它们。由于使用循环复制,这变得更加复杂,因为默认情况下二进制日志和中继日志共享相同的空间。也许将二进制日志存储在单独的磁盘上可以帮助缓解一些磁盘空间问题。
如果您可以快速修复复制错误或者磁盘空间非常宝贵,则可以设置relay_log_space_limit
低(例如 10G)
您可能想要确定在一小时内为二进制日志占用多少空间,并将其设置relay_log_space_limit
为 12 小时之类的值。
归档时间: |
|
查看次数: |
8830 次 |
最近记录: |