MHA 学习（一）

最近学习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.


提供以下功能,可用于许多部署要求,比如高可用性、数据完整性、几乎不间断的主维护所需的。

• Automated master monitoring and failover
•  自动化主监控和故障转移

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.

MHA 在现有功能监控MySQL主复制环境,检测主失败,做主人的自动故障转移。 尽管SLAVE没有收到最新的中继日志事件,MHA自动识别差动继电器日志事件从最新的slave,并应用微分事件其他奴隶。 所以所有的slave都可以一致。 MHA通常可以在几秒钟内故障转移(9 - 12秒检测主失败,选择7 - 10秒关机主机避免分裂的大脑,几秒钟应用差动继电器日志的新主人,所以总停机时间通常是10 - 30秒)。 此外,您可以定义一个特定的slave作为候选人的主(设置优先级)在一个配置文件。 因为尼MHA修复奴隶之间的一致性,可以促进任何新主人的奴隶和一致性问题(这可能导致突然的复制失败)不会发生。

• 
  
• Interactive (manual) Master Failover

You can also use MHA for just failover, not for monitoring master. You can use MHA for master failover interactively.

• Non-interactive 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.
非交互式主故障转移(不是监控主,而是做自动故障转移)也支持。这个特性是有用的,特别是当你已经软件使用监测MySQL的主人。例如,您可以使用起搏器(心跳)检测主收购失败和虚拟ip地址,并使用主故障转移和从促进MHA。

• Online switching master to a different host
• 在线主切换到一个不同的主机
  

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.

在许多情况下,有必要现有主迁移到另一台计算机上(即当前大师H / W RAID控制器上的问题或内存,你想替换为更快的机器,等)。这不是一个主崩溃,但计划主维护需要这样做。安排主维护导致停机时间(至少你不能写主)所以应该尽快完成。另一方面,你应该仔细块/杀死当前运行的会话,因为不同大师可能发生(我之间的一致性问题。e”master1更新,更新主2犯master1错误提交主2”将导致数据不一致)。快总开关和优雅的阻塞写都是必需的。尼古拉斯提供了一种方法。您可以切换主优雅地作家的0.5 - 2秒内块。在许多情况下0.5 2秒的作家停机时间是可以接受的,您可以切换主即使没有分配计划的维护窗口。这意味着您可以采取行动,如升级到更高版本更快的机器等更容易。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29896444/viewspace-1965423/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29896444/viewspace-1965423/