Mysql的使用很是广泛,跟mysql有关的话题也很是多,如性能优化、高可用性、强一致性、安全、备份、集群、横向扩展、纵向扩展、负载均衡、读写分离等。php
要想掌握其中的精髓,可得花费很多功力,虽然目前流行的mysql替代方案有不少,但是从最小成本最容易维护的角度而言,mysql仍是首选。mysql
下面从应用场景的角度切入,对mysql的技术点进行组织,写一份知识图谱,方便进行更深刻的学习和总结。sql
单Master数据库
单Master的状况是广泛存在的,对于不少我的站点、初创公司、小型内部系统,考虑到成本、更新频率、系统重要性等问题,系统只依赖一个单例数据库提供服务,基本上已经知足需求。这种场景下我以为重点应该关注的话题有上图所示的四点。编程
其中最重要的环节是数据备份,若是是交易量很是低,而且具备很是明确的服务时间段特性的话,简单的mysqldump是能够胜任的。可是这是有缺陷的,数据还原以后注定从备份点到还原点之间的数据会丢失。安全
然而在极多数的状况下,备份的工做是无法马虎的,以下列举的几点小细节,下学期将分享更多操做性的文章。性能优化
1)冷备:停机,直接copy物理文件,InnoDB引擎(frm文件、共享表空间文件、独立表空间文件、重作日志文件、my.cnf)。服务器
恢复:把文件copy到对应目录。架构
2)热备: Ibbackup或者XtraBackup工具,记录重作日志文件检查点的LSN,copy共享表空间文件以及独立表空间文件(不产生任何阻塞),记录copy后重作日志文件检查点的LSN,copy备份是产生的重作日志。负载均衡
恢复:恢复表空间文件,应用重作日志文件。
3)温备:
mysqldump,–single-transaction参数进行事务管理保证数据一致性。备份时不能用DDL语句。 恢复:直接执行文件,mysql –uroot –p <文件名.sql>
二进制半同步复制,主从服务器增量复制
恢复:mysqlbinlog
一主一从
考虑一主一从的多数初衷是系统性能和系统高可用性问题,除了单Master场景中的备份工做须要作好之外,还有性能优化、读写分离、负载均衡三项重点工做须要考虑。其中性能优化的内容比较多,
也是一块大主题,要从系统的服务指标做为依据采起相应的动做,多数系统要求的是3秒内完成请求,整体换算下来,数据库大概能够有1.5秒的总执行时间,能知足这个性能要求就是合理的优化方案。
读写分离和负载均衡的实现相对简单些,我目前维护的系统比较落后,没有作读写分离,由于是一套以报表类功能为主的系统,而负载均衡是依赖php代码来作的,从实际运维效果来看,
不大理想,并且负载均衡的代码过度嵌入到业务逻辑代码中,给代码维护带来必定噪音。
一主 n 从
一旦开始考虑一主多从的服务器架构,则证实你的系统对可用性、一致性、性能中一种或者多种的要求比较高。好多系统在开始搭建的时候都会往这个方向看齐,毕竟这样“看起来”系统会健壮不少。不过其实并不能单单依靠mysql的配置和mysql自带的中间件来解决可用性、一致性方面的问题。
横向集群
系统庞大到须要分库分表,实际上是一件可喜可贺的事情,可是切记的是要前面提到性能优化工做作到极致以后才好考虑这些会增长系统复杂度的解决方案。横向集群主要是从业务特性的角度对系统进行切分,
最完全就是切分红了各个子系统,子系统之间经过一些数据同步的方案来把一些核心数据进行共享,以免跨库调用跨库join。
而后是各类系统接口调用,把大事务拆成小事务,事务之间作好隔离和同步。上图中的三个问题在横向集群的架构体系中应属于颇有特点的问题,在实际项目中实际上是尽可能去避免这些需求的存在的,
不过若是确实须要了,也得有解决方案。
纵向集群
横向集群的切分思路最终是切分子系统,而纵向集群最后遇到的最棘手的问题是扩缩容,我运维的一个系统是提早对数据作了256个切片,256切片中0~127切片和128~255切片分别存在两个一主两从的数据库集群中,
系统运维了3年多,目前尚未扩容需求。设计初衷应该是考虑获得,假设有一天数据量很是大,能够把256个切片分4大片,分别存储到4个一主两从的集群中,从而实现扩容。
这个思路的确是可取的,只是咱们的分库逻辑当前是php代码实现,也有必定程度上影响了业务代码的逻辑,运维起来有点心惊胆战,仍是保持业务代码清爽比较好。
另外若是你想更好的提高你的编程能力,学好C语言C++编程!弯道超车,快人一步!笔者这里或许能够帮到你~
欢迎转行和学习编程的伙伴,利用更多的资料学习成长比本身琢磨更快哦!
免费学习资料: