埋在 MySQL 数据库应用中的17个关键问题!

  • 时间:
  • 浏览:1

其中最重要的环节是数据备份,原困 是交易量非常低,统统具有非常明确的服务时间段行态句子,简单的mysqldump是都能不能胜任的。统统这是有严重不足的,数据还原然后注定从备份点到还原点之间的数据会丢失。然而在极多数的情况下,备份的工作是这麼 马虎的,如下列举的几点小细节,下学期将分享更多操作性的文章。

恢复:恢复表空间文件,应用重做日志文件。

与其说这次责内容讨论后边5种场景的混合,不如说这次责内容是做总结。后边的5种场景中,一共列举了17个现象点,这17个现象点基本上全部都会叠加式的,越往深入的框架去做就越能够 考虑齐这17个现象点。17个现象点考虑全了,混合模式下的现象就不成现象了。

2)热备: Ibbackup原困 XtraBackup工具,记录重做日志文件检查点的LSN,copy共享表空间文件以及独立表空间文件(不产生任何阻塞),记录copy后重做日志文件检查点的LSN,copy备份是产生的重做日志。

二进制半同步克隆好友,主从服务器增量克隆好友

mysqldump,--single-transaction参数进行事务管理保证数据一致性。备份时不到用DDL句子。 恢复:直接执行文件,mysql –uroot –p <文件名.sql>

恢复:把文件copy到对应目录。

本文来自云栖社区相互合作伙伴“数据和云”,了解相关信息都能不能关注“OraNews”微信公众号

三、一主 n 从

原文发布时间为:2018-12-4

横向集群的切分思路最终是切分子系统,而纵向集群最后遇到的最棘手的现象是扩缩容,我运维的统统系统是提前对数据做了256个切片,256切片中0~127切片和128~255切片分别居于统统一主两从的数据库集群中,系统运维了3年多,目前还这麼 扩容需求。设计初衷应该是考虑得到,假设有一天数据量非常大,都能不能把256个切片分4大片,分别存储到统统一主两从的集群中,从而实现扩容。

五、纵向集群

考虑一主一从的多数初衷是系统性能和系统高可用性现象,除了单Master场景中的备份工作能够 做好以外,还有性能优化、读写分离、负载均衡三项重点工作能够 考虑。其中性能优化的内容比较多,也是一块大主题,要从系统的服务指标作为妙招采取相应的动作,多数系统要求的是3秒内完成请求,总体换算下来,数据库合适都能不能有1.5秒的总执行时间,能满足这一性能要求统统合理的优化方案。下学期以另统统的优先级来分别收集内容:索引优化 -》 表设计优化 -》数据库配置优化 -》硬件优化。

一、单Master

系统庞大到能够 分库分表,人太好是一件可喜可贺的事情,统统切记的是要前面提到性能优化工作做到极致然后才好考虑哪些地方地方会增加系统复杂化度的除理方案。横向集群主统统从业务行态的深度对系统进行切分,最彻底统统切分成了各个子系统,子系统之间通过有些数据同步的方案来把有些核心数据进行共享,以除理跨库调用跨库join。

读写分离和负载均衡的实现相对简单些,我目前维护的系统比较落后,这麼 做读写分离,原困 是一套以报表类功能为主的系统,而负载均衡是依赖php代码来做的,从实际运维效果来看,不大理想,统统负载均衡的代码过分嵌入到业务逻辑代码中,给代码维护带来一定噪音。下学期计划对各种后边件进行实践和性能测试,到然后把有些测试数据分享出来。

恢复:mysqlbinlog

3)温备:

1)冷备:停机,直接copy物理文件,InnoDB引擎(frm文件、共享表空间文件、独立表空间文件、重做日志文件、my.cnf)。

原文:https://blog.csdn.net/weixin_42882439/article/details/830029937

本文作者:数据和云

如下图收集,我试着把Mysql的应用场景分为6种,次责场景下能够 考虑的重点现象不一样,从而引出不同现象点下能够 补齐的知识点,后续继续基于哪些地方地方知识点进行学习和收集。(期待朋友 的意见和提供学习材料,谢谢!)

Mysql的使用非常普遍,跟MySQL有关句子题也非常多,如性能优化、高可用性、强一致性、安全、备份、集群、横向扩展、纵向扩展、负载均衡、读写分离等。下面从应用场景的深度切入,对MySQL的技术点进行组织,写一份知识图谱,方便进行更深入的学习和总结。

转载自:民工哥技术之路

六、混合模式

下学期将介绍有些实现了库路由功能的后边件的使用,也根据实际情况把想到的有些扩缩容方案实践一遍,敬请期待实操效果的分享。

单Master的情况是普遍居于的,对于统统此人 站点、初创公司、小型内内外部系统,考虑到成本、更新频率、系统重要性等现象,系统只依赖统统单例数据库提供服务,基本上原困 满足需求。这一场景下我人太好重点应该关注句子题有上图所示的四点。

统统是各种系统接口调用,把大事务拆成小事务,事务之间做好隔离和同步。上图中的统统现象在横向集群的架构体系中应属于很有特色的现象,在实际项目中人太好是尽量去除理哪些地方地方需求的居于的,不过原困 人太好能够 了,也得有除理方案。下学期也将针对哪些地方地方现象进行逐一收集,并测试一下有些号称支持哪些地方地方功能的后边件。

这一思路的确是可取的,统统朋友 的分库逻辑当前是php代码实现,全部都会一定程度上影响了业务代码的逻辑,运维起来怪怪的心惊胆战,还是保持业务代码清爽比较好。

二、一主一从

一旦始于考虑一主多从的服务器架构,则证明你的系统对可用性、一致性、性能中这一原困 多种的要求比较高。好多系统在始于搭建的然后都会往这一方向看齐,毕竟另统统“看起来”系统会健壮统统。不过人太好何必 能单单依靠mysql的配置和mysql自带的后边件来除理可用性、一致性方面的现象。

四、横向集群