开发者学堂课程【MySQL企业常见架构与调优经验分享：MYSQL常见应用架构经验分享】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/383/detail/4814
MYSQL常见应用架构经验分享
内容简介
一、 MYSQL 常见的应用架构分享
1、主从复制解决方案
2、MMM/MHA 高可用解决方案
一、MYSQL 常见的应用架构分享
1、主从复制解决方案
主从复制其实是 MySQL 主库会产生二进的文件，那么从库呢，他其实是把二进的文件拉到从库去，然后通过解析，把二进的文件解析成 SQL 语句，然后在从库在执行一遍这个 SQL 操作。
这个方法就保证主库和从库是一致的。这是最原始的一种主从复制方式。
最简单的给 MySQL 做备份的方法就是通过主从的方式，对 MySQL 做备份方式有很多种，首先如果我们 MySQL 数据不是很大的话，比如几百兆几个 G 的话，对数据要求不是很高的话，那我觉得最简单的方式是通过一个 Keepalived 做一个备份，因为数据不是很大，那么主从复制这个场景他一般情况下是这个数据库它的数据量非常非常大，并且每天增量也非常高，啊，比如说几 T 几 T 的这么一个数据，那么每天通过做全备的话，那其实是不现实的，并且每天增长，比如说几十 G 上百 G 对吧。
那么这种情况通过去做一个增量备份，或者说如果全备的话，效率是非常非常低的。
那么这种情况下，这个主从复制他这个就显得就比较好了。他的这种主动复制方式可以实时的就是把数据从这个主库然后拉到从库上去。这样其实也就实现了主库数据一个实时备份，那么当主库故障的时候，我们直接把数据切到从库就可以去用了。
当然随着就说我们对这个架构的这个调整，然后对这个 MySQL ，对这个数据库这个实质性，包括他的一些安全性要求的一个进一步的提升，那么简单的主动复制，在满足备份的情况下，它还可以，但是如果说我们要实现一些自动，更高级更自动的功能，比如说在这个主从僵局之后，对我们业务要自动的切到从上去，不需要人为揭露的情况下，这个主从复制往往就实现不了了。
那么针对这种情况，相关的这个业界人又提供了很多种方法，那么最常见的就是，我们在这个实际环境当中，通过主从复制技术，然后配合这个高可用的一个集训软件就是 keepalived ，去实现这个 failover 那么就说就说通过这个 keepalived ，去保证我们这个业务的连续性，当主库到了之后，我们不用去做这种 IP 的切换操作，那么随着业务全这个切到存货上去啊，去实现这么一个操作，具体实现过程如上图，DB1 和 DB2 互为主从的关系， DB1 既是主库，又是从库，同理， DB2 也是一样。
如何维护这种关系呢？
通过 keepalived 实现决策的切换。
如图 DB1 主要是一个读写操作， DB2 负责拉日志，同步操作，当 DB1 出现问题之后，本身 keepalived 会出现检测机制，检测出 DB1 上主从同步失效之后，它就会自动做切换。
当 DB1 出现故障之后，首先有 keepalived ，他有一个检测胶板，会检测到 DB1 他的故障，比如说同步出现故障了，或说网络出现故障了，或说数据库，当他检测出来之后，它会自动把 VIP 从 DB1 飘到 DB2 ，首先是一个 VIP 的漂移操作。
飘过来之后，我们前端程序连的数据库就是 keepalived 它的一个 VIP 地址。那么这会飘到 DB2 之后呢，我们前端程序就不用做改动，因为我们 VIP 程序不管是在 DB1 还是 DB2 他都是一样的·，只不过同一时刻只在一台机器上。
这是迁到 DB2 之后的，那么接下来 DB2 他要完成的工作就是把所有程序在 DB2 进行读写操作。
那么现在 DB1 是故障的，我们就可以腾出时间对 DB1 进行修复，那么修复完成之后，我们可以把 DB1 的数据和 DB2 的数据做一个反向同步，也就说，把这个故障这段时间的数据从这个 DB2 上在同步到 DB1 上，同步完之后我们可以把这个整个的角色切换到原生状态下。也可以这个角色局域型就可以了。
也可以说，这个结构是通过 keepalived 实现了这个的角色的转换。并且还实现了 DB1 和 DB2 他们的服务的监测。那么这个方案的他们就是常说的 MYSQL 主主复制技术，说是主主复制技术，他不完全正确，其实在同一时间也只有一个主库在运行。
这是 MySQL 自身提供的一种高可用解决方案，数据同步方法采用的是 MySQL replication 技术。
MySQL replication 就是从服务器到主服务器拉取二进例日志文件，然后再将日志文件解析成相应的 SQL 在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。
为了达到更高的可用性，在实际的应用环境中，一般都是采用 MySQL replication 技术配合高可用集群软件keepalived 来实现自动 failover ，这种方式可以实现 95.000% 的 SLA。
它的实现方式比较简单，企业应用也比较灵活，但这个方式呢，它的 SLA 级别是非常低的。它的性能和安全性方面也都不是最好的。当然它的这个方案也是最廉价的，最成熟的。
- MMM/MHA 高可用解决方案
这个套件其实最早是有一个日本的搞技术的提供了解决方案。这个解决方案其实是根据 PAO 语言去编写的。这个方案现在其实已经集成到默认版本里面去了。
那么可以通过 yum 直接去安装 MMM ，就直接可以安装上去。要装的话就是 yumest MySQL/MMM ，他就直接把这个套件给安装了。因为这个套件确实是一个比较成熟稳定的技术，在企业里边应用也是非常多的。
MMM 提供了 MySQL 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。
在 MMM 高可用方案中，典型的应用是双主多从架构，通过 MySQL replication 技术可以实现两个服务器互为主从，且在任何时候只有一个节点可以被写入，避免了多点写入的数据冲突。同时，当可写的主节点故障时，MMM 套件可以立刻监控到，然后将服务自动切换到另一个主节点，继续提供服务，从而实现 MySQL 的高可用。
首先前端是有一个应用程序 Application ，那么正常情况下，这个应用程序会在 Master1 级进行一个可读可写的这么一个操作。
那么这个 Master1 和 Master2 也是互为主从关系的，那么通过这点的话，和刚才我们看到的 keepalived 加 MySQL 主从是一样的。但是也有不一样的，不一样的是 Master2 他提供了一个读的操作，这个架构在我们刚才上面 DB2 它仅仅是做一个同步 DB1 的数据，他没有做一个可读的功能。
那么在这个 MMM 这个里面 Master2 他在做一个从的 MySQL 的时候，还可以提供一个读的服务。这个是他的一个优势。
那么这个 Master1 和 Master2 也是互为完全主从的，那么他的数据同步的方式也是通过主从复制来实现的。
所以 MMM 的核心也是通过主从复制架构来实现的，重点我们看最后一部分，在 MMM 套件里面，他有一个监控模块 Monitor ，这个监控模块怎么监控呢？
先监控 Master1 和 Master2 的状态，比如说他现在监控到 Master1 他这个同步出现故障，那么他要做的操作就是把这个 Master1 给隔离出去。
那么同时它会把这个地址，可读可写的地址，就是 VIP 地址迁到 Master2 去，那么 Master2 现在充当着 Master1 的角色，就是可以实现可读可写，那么现在就是 Master2 可读可写了，那么同理如果说这个监控这个模块发现 Master2 出现故障，它就会把 Master2 这个可读链表里面剔除出去，也就是不让 Master2 去提供服务了。那么这块呢，完全是有这个监控进程来完成。
还有一些 VIP 的切换也是有这个 Monitor 这么一个进程来完成，这仅仅是它的一部分功能，最主要的功能是什么，就是如果说我们这个 Master1 出现故障，他能做的一个点，它会记录这个 Master1 和 Master2 之间他们同步到了那个点，那么如果说 Master2 他现在变成主之后，它就会把之前没有同步过的记录关系，做一个重记录过程。这个点是 MMM 套件非常好的地方。
