本篇文章给大家带来了关于mysql的相关常识，其间首要介绍了关于常见的高可用计划的相关问题，这儿只评论常用高可用计划的优缺陷以及高可用计划的选型，下面一起来看一下，希望对大家有协助。
- 推荐学习：mysql视频教程
1. 概述
咱们在考虑MySQL数据库的高可用的架构时，首要要考虑如下几方面：
- 假如数据库产生了宕机或许意外中断等毛病，能尽快恢复数据库的可用性，尽可能的削减停机时间，确保事务不会由于数据库的毛病而中断。
- 用作备份、只读副本等功用的非主节点的数据应该和主节点的数据实时或许终究保持共同。
- 当事务产生数据库切换时，切换前后的数据库内容应当共同，不会由于数据缺失或许数据不共同而影响事务。
关于对高可用的分级在这儿咱们不做具体的评论，这儿只评论常用高可用计划的优缺陷以及高可用计划的选型。
2. 高可用计划
2.1. 主从或主主半同步仿制
运用双节点数据库，树立单向或许双向的半同步仿制。在5.7今后的版本中，由于lossless replication、logical多线程仿制等一些列新特性的引进，使得MySQL原生半同步仿制愈加牢靠。
常见架构如下：
通常会和proxy、keepalived等第三方软件一起运用，即能够用来监控数据库的健康，又能够履行一系列管理指令。假如主库产生毛病，切换到备库后依然能够持续运用数据库。
长处：
- 架构比较简略，运用原生半同步仿制作为数据同步的依据；
- 双节点，没有主机宕机后的选主问题，直接切换即可；
- 双节点，需求资源少，布置简略；
缺陷：
- 彻底依赖于半同步仿制，假如半同步仿制退化为异步仿制，数据共同性无法得到确保；
- 需求额外考虑haproxy、keepalived的高可用机制。
2.2. 半同步仿制优化
半同步仿制机制是牢靠的。假如半同步仿制一直是收效的，那么便能够以为数据是共同的。可是由于网络动摇等一些客观原因，导致半同步仿制产生超时而切换为异步仿制，那么这时便不能确保数据的共同性。所以尽可能的确保半同步仿制，便可进步数据的共同性。
该计划相同运用双节点架构，可是在原有半同仿制的基础上做了功用上的优化，使半同步仿制的机制变得愈加牢靠。
可参考的优化计划如下：
2.2.1. 双通道仿制
半同步仿制由于产生超时后，仿制断开，当再次树立起仿制时，一起树立两条通道，其间一条半同步仿制通道从当时方位开端仿制，确保从机知道当时主机履行的进度。另外一条异步仿制通道开端追补从机落后的数据。当异步仿制通道追赶到半同步仿制的开始方位时，恢复半同步仿制。
2.2.2. binlog文件服务器
树立两条半同步仿制通道，其间衔接文件服务器的半同步通道正常状况下不启用，当主从的半同步仿制产生网络问题退化后，发动与文件服务器的半同步仿制通道。当主从半同步仿制恢复后，封闭与文件服务器的半同步仿制通道。
长处：
双节点，需求资源少，布置简略；
架构简略，没有选主的问题，直接切换即可;
比较于原生仿制，优化后的半同步仿制更能确保数据的共同性。
缺陷：
需求修正内核源码或许运用mysql通信协议。需求对源码有必定的了解，并能做必定程度的二次开发。
依旧依赖于半同步仿制，没有从根本上处理数据共同性问题。
2.3. 高可用架构优化
将双节点数据库扩展到多节点数据库，或许多节点数据库集群。能够依据自己的需求挑选一主两从、一主多从或许多主多从的集群。
由于半同步仿制，存在接收到一个从机的成功应答即以为半同步仿制成功的特性，所以多从半同步仿制的牢靠性要优于单从半同步仿制的牢靠性。而且多节点一起宕机的几率也要小于单节点宕机的几率，所以多节点架构在必定程度上能够以为高可用性是好于双节点架构。
可是由于数据库数量较多，所以需求数据库管理软件来确保数据库的可维护性。能够挑选MMM、MHA或许各个版本的proxy等等。常见计划如下：
2.3.1. MHA+多节点集群
MHA Manager会守时探测集群中的master节点，当master呈现毛病时，它能够主动将最新数据的slave提升为新的master，然后将一切其他的slave从头指向新的master，整个毛病转移过程对应用程序彻底透明。
MHA Node运行在每台MySQL服务器上，首要作用是切换时处理二进制日志，确保切换尽量少丢数据。
MHA也能够扩展到如下的多节点集群：
长处：
能够进行毛病的主动检测和转移;
可扩展性较好，能够依据需求扩展MySQL的节点数量和结构;
比较于双节点的MySQL仿制，三节点/多节点的MySQL产生不可用的概率更低
缺陷：
至少需求三节点，相对于双节点需求更多的资源;
逻辑较为复杂，产生毛病后排查问题，定位问题愈加困难;
数据共同性依然靠原生半同步仿制确保，依然存在数据不共同的风险;
可能由于网络分区产生脑裂现象;
2.3.2. zookeeper+proxy
Zookeeper运用分布式算法确保集群数据的共同性，运用zookeeper能够有用的确保proxy的高可用性，能够较好的避免网络分区现象的产生。
长处：
较好的确保了整个体系的高可用性，包括proxy、MySQL;
扩展性较好，能够扩展为大规模集群;
缺陷：
数据共同性依然依赖于原生的mysql半同步仿制;
引进zk，整个体系的逻辑变得愈加复杂;
2.4. 同享存储
同享存储完成了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生仿制功用，而是经过磁盘数据同步的手段，来确保数据的共同性。
2.4.1. SAN同享贮存
SAN的概念是允许存储设备和处理器（服务器）之间树立直接的高速网络（与LAN比较）衔接，经过这种衔接完成数据的集中式存储。常用架构如下：
运用同享存储时，MySQL服务器能够正常挂载文件体系并操作，假如主库产生宕机，备库能够挂载相同的文件体系，确保主库和备库运用相同的数据。
长处：
两节点即可，布置简略，切换逻辑简略；
很好的确保数据的强共同性；
不会由于MySQL的逻辑错误产生数据不共同的状况；
缺陷：
需求考虑同享存储的高可用；
价格昂贵；
2.4.2. DRBD磁盘仿制
DRBD是一种根据软件、根据网络的块仿制存储处理计划，首要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就能够确保实时同步。常用架构如下：
当本地主机呈现问题，远程主机上还保留着一份相同的数据，能够持续运用，确保了数据的安全。
DRBD是linux内核模块完成的快级别的同步仿制技术，能够与SAN达到相同的同享存储效果。
长处：
两节点即可，布置简略，切换逻辑简略；
比较于SAN贮存网络，价格低廉；
确保数据的强共同性；
缺陷：
对io性能影响较大；
从库不提供读操作；
2.5. 分布式协议
分布式协议能够很好处理数据共同性问题。比较常见的计划如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的布置计划，经过运用NDB存储引擎实时备份冗余数据，完成数据库的高可用性和数据共同性。
长处：
悉数运用官方组件，不依赖于第三方软件；
能够完成数据的强共同性；
缺陷：
国内运用的较少；
装备较复杂，需求运用NDB贮存引擎，与MySQL常规引擎存在必定差异；
至少三节点；
2.5.2. Galera
根据Galera的MySQL高可用集群， 是多主数据同步的MySQL集群处理计划，运用简略，没有单点毛病，可用性高。常见架构如下：
长处：
多主写入，无推迟仿制，能确保数据强共同性；
有老练的社区，有互联网公司在大规模的运用；
主动毛病转移，主动添加、除掉节点；
缺陷：
需求为原生MySQL节点打wsrep补丁
只支撑innodb贮存引擎
至少三节点；
2.5.3. POAXS
Paxos 算法处理的问题是一个分布式体系怎么就某个值（决议）达到共同。这个算法被以为是同类算法中最有用的。Paxos与MySQL相结合能够完成在分布式的MySQL数据的强共同性。常见架构如下：
长处：
多主写入，无推迟仿制，能确保数据强共同性；
有老练理论基础；
主动毛病转移，主动添加、除掉节点；
缺陷：
只支撑innodb贮存引擎
至少三节点；
3. 总结
跟着人们对数据共同性的要求不断的进步，越来越多的办法被尝试用来处理分布式数据共同性的问题，如MySQL本身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引进等等。
而运用分布式算法用来处理MySQL数据库数据共同性的问题的办法，也越来越被人们所接受，一系列老练的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模运用。
跟着官方MySQL Group Replication的GA，运用分布式协议来处理数据共同性问题已经成为了干流的方向。期望越来越多优异的处理计划被提出，MySQL高可用问题能够被更好的处理。
- 推荐学习：mysql视频教程
- 本文转载自：www.php.cn/mysql-tutor…
