MySQL relay_log_purge=0 时的风险
来源:互联网 发布:最好的桌面主题软件 编辑:程序博客网 时间:2024/09/21 09:18
http://ourmysql.com/archives/1453
有时候,我们希望将 MySQL 的 relay log 多保留一段时间,比如用于高可用切换后的数据补齐,于是就会设置 relay_log_purge=0,禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话:
Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.
究竟是什么样的风险呢?查找了一番后,基本上明白了原因。
首先,为了让从库是 crash safe 的,必须设置 relay_log_recovery=1,这个选项的作用是,在 MySQL 崩溃或人工重启后,由于 IO 线程无法保证记录的从主库读取的 binlog 位置的正确性,因此,就不管 master_info 中记录的位置,而是根据 relay_log_info 中记录的已执行的 binlog 位置从主库下载,并让 SQL 线程也从这个位置开始执行。MySQL 启动时,相当于执行了 flush logs ,会新开一个 relay log 文件,新的 relay log 会记录在新的文件中。如果默认情况 relay_log_purge=1 时,SQL 线程就会自动将之前的 relay log 全部删除。而当 relay_log_purge=0 时,旧的 relay log 则会被保留。虽然这并不会影响从库复制本身,但还是会有地雷:
由于崩溃或停止 MySQL 时,SQL 线程可能没有执行完全部的 relay log,最后一个 relay log 中的一部分数据会被重新下载到新的文件中。也就是说,这部分数据重复了两次。
如果 SQL 跟得很紧,则可能在 IO 线程写入 relay log ,但还没有将同步到磁盘时,就已经读取执行了。这时,就会造成新的文件和旧的文件中少了一段数据。
如果我们读取 relay log 来获取数据,必须注意这一点,否则就会造成数据不一致。而保留 relay log 的目的也在于此。因此,在处理 relay log 时必须格外小心,通过其中 binlog 头信息来确保正确性。
关于如何配置 crash safe 的复制本身的配置,可以参照:
http://blog.itpub.net/22664653/viewspace-1752588/
http://www.innomysql.net/article/34.html
参考资料:
http://blog.booking.com/better_crash_safe_replication_for_mysql.html
https://bugs.mysql.com/bug.php?id=73038
http://bugs.mysql.com/bug.php?id=74324
- MySQL relay_log_purge=0 时的风险
- MySQL relay_log_purge=0 时的风险
- Mysql开二进制日志的风险
- MySQL drop table操作风险
- 期望风险、经验风险与结构风险之间的关系
- 期望风险、经验风险、结构风险的关系
- 风险管理的基础:风险评估
- Java门派的风险
- 测试风险的管理
- 测试风险的管理
- 测试风险的管理
- ERP的风险
- 外汇市场的风险控制
- 回归的风险
- 软件项目的风险
- 测试风险的管理
- SaaS的七大风险
- Scrum的风险管理
- 细说Executor框架(下)
- HDU 4514并查集判环+最长路
- Matlab实现线性回归和逻辑回归: Linear Regression & Logistic Regression
- 案例学习: MapReduce
- 简易HTTP服务器的实现
- MySQL relay_log_purge=0 时的风险
- 在android中通过java层程序调用命令行的一些备注
- C语言 有/无符号数 需要注意的问题
- bzoj 3206: [Apio2013]道路费用 最小生成树
- 动态规划之最少硬币
- margin与padding
- MATLAB数据处理快速学习教程
- 记于2016.4.6
- NSInvocation在获取返回值后crash问题