最近学习mysql MHA 当然学习的话 肯定要看官方文档的 分享下 顺便翻译下 注释出重要的
A primary objective of MHA is automating master failover and slave promotion within short (usually 10-30 seconds) downtime, without suffering from replication consistency problems, without spending money for lots of new servers, without performance penalty, without complexity (easy-to-install), and without changing existing deployments.
MHA 主要目标是自动化主故障转移和从内部晋升(通常10 - 30秒)停机时间短,没有遭受复制的一致性问题,不花钱很多新的服务器,没有性能损失,没有复杂性(能够),在不改变现有的部署。
通常的时间为 10-30 秒
对现有的架构不改变 对复制的一致性进行进行校验 没有性能损失
MHA also provides a way for scheduled online master switch: changing currently running master to a new master safely, within a few seconds (0.5-2 seconds) of downtime (blocking writes only).
MHA 还提供了一种方法将在线总开关:改变当前运行主新主人安全,在几秒(0.5 2秒)的停机时间(阻塞)写道。
vides the following functionality, and can be useful in many deployments where requirements such as high availability, data integrity, almost non-stop master maintenance are desired.
MHA has a functionality to monitor MySQL master in an existing replication environment, detecting master failure, and doing master failover automatically. Even though some of slaves have not received the latest relay log events, MHA automatically identifies differential relay log events from the latest slave, and applies differential events to other slaves. So all slaves can be consistent. MHA normally can do failover in seconds (9-12 seconds to detect master failure, optionally 7-10 seconds to power off the master machine to avoid split brain, a few seconds for applying differential relay logs to the new master, so total downtime is normally 10-30 seconds). In addition, you can define a specific slave as a candidate master (setting priorities) in a configuration file. Since MHA fixes consistencies between slaves, you can promote any slave to a new master and consistency problems (which might cause sudden replication failure) will not happen.
- Automated master monitoring and failover
You can also use MHA for just failover, not for monitoring master. You can use MHA for master failover interactively.
- Interactive (manual) Master Failover
Non-interactive master failover (not monitoring master, but doing failover automatically) is also supported. This feature is useful especially when you have already used a software that monitors MySQL master. For example, you can use Pacemaker(Heartbeat) for detecting master failure and virtual ip address takeover, and use MHA for master failover and slave promotion.
- Non-interactive master failover
In many cases, it is necessary to migrate an existing master to a different machine (i.e. the current master has H/W problems on RAID controller or RAM, you want to replace with faster machine, etc). This is not a master crash, but scheduled master maintenance is needed to do that. Scheduled master maintenance causes downtime (at least you can not write master) so should be done as quickly as possible. On the other hand, you should block/kill current running sessions very carefully because consistency problems between different masters might happen (i.e "updating master1, updating master 2, committing master1, getting error on committing master 2" will result in data inconsistency). Both fast master switch and graceful blocking writes are required. MHA provides a way to do that. You can switch master gracefully within 0.5-2 seconds of writer block. In many cases 0.5-2 seconds of writer downtime is acceptable and you can switch master even without allocating scheduled maintenance window. This means you can take actions such as upgrading to higher versions, faster machine, etc much more easily.
- Online switching master to a different host
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29896444/viewspace-1965423/，如需转载，请注明出处，否则将追究法律责任。