MYSQL Group replication Crash 的快速恢复方法

最近，在检测开发的语句后，发现有些语句的问题，根本不在语句优化，MYSQL的系统优化，慢的根本原因是，客户的要求太奇葩。

奇葩到什么程度，要求每次启动页面后，要显示200多万条数据，这是我在检测语句和优化语句后，发现的问题，并且询问开发人员，开发人员告知，由于客户不大懂IT 技术，按照自己的想法要求，并认为这并不是什么难事。

个人观点，这样的客户我们的引导，教化，虽然在21世纪，还是要允许有些人不懂IT的逻辑，终归人家不是做这方面工作的，这就要求我们的工作的深度和广度。

好了话归正题，MGR 崩溃的后怎么来快速修复，这里的方法首先是快速的并且是稳定的，能应对任何环境中的。当然方法既然这么好那么好，必然有他的限制。

系统是怎么坏的，这个系统本来是一个测试，但这个系统上的架设的测试时马上就要上线的系统并且由于测试人员也在测试，所以这个测试系统就变得不那么“测试” 了，坏了会有很多人 challange 你。

具体过程时这样的，由于压力测试需求，这个机器上的内存已经开始使用SWAP了，其实这里和运维人员还有一段交流，就是他们认为从虚拟机上看内存交换不频繁就说明内存不缺少。我个人是不大同意这样的观点的，首先数据库和其他基础设施不一样，内存必须富裕，另一个问题是，数据库都是原因自己HOLD 内存的，就算是MYSQL 这样把很多系统和内存的管理都交给 LINUX 系统的东西还是愿意 H 住更多的内存。

虽然是虚拟机，但添加内存还是要关机，（我怎么记得，虚拟机添加内存都应该是在线的），当然如果在线添加，也就不会有这段子和这篇文字了。

在关闭集群的机器后，添加内存后，启动MYSQL，重做了集群的初始化，并且将另一台机器添加到集群中，在添加另一台机器的过程中报错。

尝试，重新添加机器，到集群失败。这里采用了最快速的方法，备份在恢复的手段，选中其中一台机器进行备份，备份后将数据恢复到已经损坏的机器中，重新启动机器，但还是报错。

报错信息如上，看了是GTID 重复执行的问题， 直接在对应的库上停止复制，然后reset 主机信息， 然后重新设置 gtid_purged (相关的信息从备份中找)。然后在

重新启动集群加入节点

相关的机器已经回到集群中并开始工作

修复的过程看似上面简单，其实为了找寻其他的方法和其实过程时曲折和糟心的（这里就不说了）。好在早上开始工作前，这个事情结束了，要不又一天很难过。