探索MySQL高可用架构之MHA(9)

探索MySQL高可用架构之MHA(9)-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的mha不足的修复！ 本篇文章主要介绍relay log的清除！ MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被 用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严 重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式） MHA节点中包含了pure_relay_logs命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay_log_purge=1,等待几秒钟以便SQL线程切换到新的中继日志，再执行SET GLOBAL relay_log_purge=0。 pure_relay_logs脚本参数如下所示： --user mysql 用户名 --password mysql 密码 --port 端口号 --workdir 指定创建relay log的硬链接的位置，默认是/var/tmp， 由于系统不同分区创建硬链接文件会失败， 故需要执行硬链接具体位置，成功执行脚本后， 硬链接的中继日志文件被删除 --disable_relay_log_purge 默认情况下，如果relay_log_purge=1， 脚本会什么都不清理，自动退出，通过设定这个参数， 当relay_log_purge=1的情况下会将relay_log_purge设置0。 清理relay log之后，最后将参数设置为OFF。 下面我们开始操作一下purge_relay_logs脚本删除中继日志不会阻塞SQL线程。下面我们手动执行看看什么情况。 purge_relay_logs --user=root --password=mysql --port=3306 -disable_relay_log_purge --workdir=/app/masterha/app1 2015-04-20 15:47:24: purge_relay_logs script started. Found relay_log.info: /data/mysql/relay-log.info Removing hard linked relay log files server03-relay-bin* under /data/.. done. Current relay log file: /data/mysql/server03-relay-bin.000002 Archiving unused relay log files (up to /data/mysql/server03-relay-bin.000001) ... Creating hard link for /data/mysql/server03-relay-bin.000001 under /data//server03-relay-bin.000001 .. ok. Creating hard links for unused relay log files completed. Executing SET GLOBAL relay_log_purge=1; FLUSH LOGS; sleeping a few seconds so that SQL thread can delete older relay log files (if it keeps up); SET GLOBAL relay_log_purge=0; .. ok. Removing hard linked relay log files server03-relay-bin* under /data/.. done.2014-04-20 15:47:27: All relay log purging operations succeeded.
weblogic集群的应用发布工作就成功结束了！ 结束语： 到此为此，构建mysql高可用系列共9篇文章，就全部结束了。 送给想学习mysql的朋友、送给想学又不敢实践操作的朋友、送给怕实现出现错误的朋友！！！ 想和做是两个过程，有的时候其实你和成功只差那么一步，只要你别放弃坚持下去，你的辛苦是不会白付出的,因为你永远不会知道未来的你是多么的强大！！！