MYSQL企业常用架构与调优经验分享

一、选择Percona Server、MariaDB还是MYSQL


1、Mysql三种存储引擎

MySQL提供了两种存储引擎:MyISAM和 InnoDB,MySQL4和5使用默认的MyISAM存储引擎。从MYSQL5.5开始,MySQL已将默认存储引擎从MyISAM更改为InnoDB。

MyISAM没有提供事务支持,而InnoDB提供了事务支持。

XtraDB是InnoDB存储引擎的增强版本,被设计用来更好的使用更新计算机硬件系统的性能,同时还包含有一些在高性能环境下的新特性。

2、Percona  Server分支

Percona Server由领先的MySQL咨询公司Percona发布。

Percona Server是一款独立的数据库产品,其可以完全与MySQL兼容,可以在不更改代码的情况了下将存储引擎更换成XtraDB。是最接近官方MySQL Enterprise发行版的版本。

Percona提供了高性能XtraDB引擎,还提供PXC高可用解决方案,并且附带了percona-toolkit等DBA管理工具箱,

3、MariaDB

MariaDB由MySQL的创始人开发,MariaDB的目的是完全兼容MySQL,包括API和命令行,使之能轻松成为MySQL的代替品。

MariaDB提供了MySQL提供的标准存储引擎,即MyISAM和InnoDB,10.0.9版起使用XtraDB(名称代号为Aria)来代替MySQL的InnoDB。

4、如何选择

综合多年使用经验和性能对比,首选Percona分支,其次是MariaDB,如果你不想冒一点风险,那就选择MYSQL官方版本。

二、 常用的MYSQL调优策略


1、硬件层相关优化

修改服务器BIOS设置

选择Performance Per Watt Optimized(DAPC)模式,发挥CPU最大性能。

Memory Frequency(内存频率)选择Maximum Performance(最佳性能)

内存设置菜单中,启用Node Interleaving,避免NUMA问题

2、磁盘I/O相关

使用SSD硬盘

如果是磁盘阵列存储,建议阵列卡同时配备CACHE及BBU模块,可明显提升IOPS。

raid级别尽量选择raid10,而不是raid5.

3、文件系统层优化

使用deadline/noop这两种I/O调度器,千万别用cfq

使用xfs文件系统,千万别用ext3;ext4勉强可用,但业务量很大的话,则一定要用xfs;

文件系统mount参数中增加:noatime, nodiratime, nobarrier几个选项(nobarrier是xfs文件系统特有的);

4、内核参数优化

修改vm.swappiness参数,降低swap使用率。RHEL7/centos7以上则慎重设置为0,可能发生OOM

调整vm.dirty_background_ratio、vm.dirty_ratio内核参数,以确保能持续将脏数据刷新到磁盘,避免瞬间I/O写。产生等待。

调整net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse都设置为1,减少TIME_WAIT,提高TCP效率。

5、Mysql参数优化建议

建议设置default-storage-engine=InnoDB,强烈建议不要再使用MyISAM引擎。

调整innodb_buffer_pool_size的大小,如果是单实例且绝大多数是InnoDB引擎表的话,可考虑设置为物理内存的50% -70%左右。

设置innodb_file_per_table = 1,使用独立表空间。

调整innodb_data_file_path = ibdata1:1G:autoextend,不要用默认的10M,在高并发场景下,性能会有很大提升。

设置innodb_log_file_size=256M,设置innodb_log_files_in_group=2,基本可以满足大多数应用场景。

调整max_connection(最大连接数)、max_connection_error(最大错误数)设置,根据业务量大小进行设置。

另外,open_files_limit、innodb_open_files、table_open_cache、table_definition_cache可以设置大约为max_connection的10倍左右大小。

key_buffer_size建议调小,32M左右即可,另外建议关闭query cache。

mp_table_size和max_heap_table_size设置不要过大,另外sort_buffer_size、join_buffer_size、read_buffer_size、read_rnd_buffer_size等设置也不要过大。

三、   MYSQL常见的应用架构分享

1、主从复制解决方案

这是MySQL自身提供的一种高可用解决方案,数据同步方法采用的是MySQL replication技术。MySQL replication就是从服务器到主服务器拉取二进制日志文件,然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作,通过这种方式保证数据的一致性。

为了达到更高的可用性,在实际的应用环境中,一般都是采用MySQL replication技术配合高可用集群软件keepalived来实现自动failover,这种方式可以实现95.000%的SLA。

2、MMM/MHA高可用解决方案

MMM提供了MySQL主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。在MMM高可用方案中,典型的应用是双主多从架构,通过MySQL replication技术可以实现两个服务器互为主从,且在任何时候只有一个节点可以被写入,避免了多点写入的数据冲突。同时,当可写的主节点故障时,MMM套件可以立刻监控到,然后将服务自动切换到另一个主节点,继续提供服务,从而实现MySQL的高可用。

3、Heartbeat/SAN高可用解决方案

在这个方案中,处理failover的方式是高可用集群软件Heartbeat,它监控和管理各个节点间连接的网络,并监控集群服务,当节点出现故障或者服务不可用时,自动在其他节点启动集群服务。在数据共享方面,通过SAN(Storage Area Network)存储来共享数据,这种方案可以实现99.990%的SLA。

4、Heartbeat/DRBD高可用解决方案

此方案处理failover的方式上依旧采用Heartbeat,不同的是,在数据共享方面,采用了基于块级别的数据同步软件DRBD来实现。

DRBD是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。和SAN网络不同,它并不共享存储,而是通过服务器之间的网络复制数据。

四、MYSQL经典应用架构

其中:

Dbm157是mysql主,dbm158是mysql主的备机,dbs159/160/161是mysql从。

MySQL写操作一般采用基于heartbeat+DRBD+MySQL搭建高可用集群的方案。通过heartbeat实现对mysql主进行状态监测,而DRBD实现dbm157数据同步到dbm158。

读操作普遍采用基于LVS+Keepalived搭建高可用高扩展集群的方案。前端AS应用通过提高的读VIP连接LVS,LVS有keepliaved做成高可用模式,实现互备。

最后,mysql主的从节点dbs159/160/161通过mysql主从复制功能同步mysql主的数据,通过lvs功能提供给前端AS应用进行读操作,并实现负载均衡。

时间: 2024-12-14 12:03:13

MYSQL企业常用架构与调优经验分享的相关文章

JVM调优经验分享

前言 一.JVM调优知识背景简介 二.JVM调优参数简介 三.JVM调优目标 四.JVM调优经验 结束语 <br/> 本次分享探讨的JVM调优是指server端运行的JVM调优,适应版本为[1.6– 1.7], 不涉及最新的1.8版本. 假设线程池.连接池.程序代码等都已经做过优化,效果(系统吞吐量.响应性能)仍然不理想,我们就可以考虑JVM调优了. <br/> 一. JVM调优知识背景简介 1.堆与栈的概念 堆和栈是程序运行的关键:栈是运行时的单位,而堆是存储的单位. 栈解决程序

MySQL数据库调优经验

?RDS for MySQL 由亚洲唯一WebScaleSQL团队维护内核源码,结合阿里巴巴多年MySQL数据库调优经验,从数据库源码层及数据库参数进行了性能优化,在相近规格配置下,RDS for MySQL性能值能达到自建数据库性能的3倍以上. RDS for MySQL针对通用的场景,在内核做了一系列的优化: 1. 改进了InnoDB redo组提交功能,多线程并发写入的情况下能有10%以上的速度提升. 2. 优化锁,对一些会引起串行化的大锁进行了拆分,能够有效避免长时间的读锁等待,提升数据

MySQL 5.6初始配置调优

原文链接: What to tune in MySQL 5.6 after installation原文日期: 2013年09月17日翻译日期: 2014年06月01日翻译人员: 铁锚 随着 大量默认选项的改进, MySQL 5.6比以前版本需要调优的选项大为减少. 在本文中我将讲述需要优化的配置项. InnoDB设置 innodb_buffer_pool_size  -- 默认值为 128M. 这是最主要的优化选项,因为它指定 InnoDB 使用多少内存来加载数据和索引(data+indexe

MySQL企业常用集群图解

mysql集群架构图片 1.mysql企业常用集群架构 在中小型互联网的企业中.mysql的集群一般就是上图的架构.WEB节点读取数据库的时候读取dbproxy服务器.dbproxy服务器通过对SQL语句的判断来进行数据库的读写分离.读请求负载到从库(也可以把主库加上),写请求写主库. 这里的dbproxy是数据库集群的唯一出口所以也需要做高可用. drproxy是数据库读写分离的常用软件,amoeba.mycat.cobar也很常用.这类软件不仅带有读写分离功能,还可以实现负载均衡以及后端节点

GC浅析之三-性能调优经验总结

性能调优经验总结 问题的出现: 在日常环境下,以某server 为例,该机器的每秒的访问量均值在368左右,最大访问量在913.对外提供服务的表现为每两三个小时就有秒级别的时间客户端请求超时,在访问量增大的情况下用户请求超时频率明显增多. 现象的直接分析: 通过监控GC发现该现象,GC中比较频繁的出现promotion failed和concurrent mode failure.由于promotion failed产生的直接原因为在发送YGC时,old区因为碎片.可用空间不够,造成无法晋升对象

性能调优案例分享:Mysql的cpu过高

性能调优案例分享:Mysql的cpu过高 问题:一个系统,Mysql数据库,数据量变大之后.mysql的cpu占用率很高,一个测试端访问服务器时mysql的cpu占用率为15% ,6个测试端连服务器的时候mysql cpu占用率为50%~60% .ps 1: 每个测试端所做事情就是插入记录,不过插入前会先查询一下是否已经有相同的记录,有的话就更新原有记录,没有就直接插入. ps 2: CPU--Pentium Dual E1240 @ 1.60GHZ内存--2GOS--Windows 2003调

深入理解JVM虚拟机10:JVM常用参数以及调优实践

微信公众号[Java技术江湖]一位阿里 Java 工程师的技术小站.作者黄小斜,专注 Java 相关技术:SSM.SpringBoot.MySQL.分布式.中间件.集群.Linux.网络.多线程,偶尔讲点Docker.ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!(关注公众号后回复”Java“即可领取 Java基础.进阶.项目和架构师等免费学习资料,更有数据库.分布式.微服务等热门技术学习视频,内容丰富,兼顾原理和实践,另外也将赠送作者原创的Java学习指南.Java程序员面试指

MySQL Replication 常用架构

转自: http://www.cnblogs.com/ggjucheng/archive/2012/11/13/2768879.html 前言 MySQLReplicaion本身是一个比较简单的架构,就是一台MySQL服务器(Slave)从另一台MySQL服务器(Master)进行日志的复制然后再解析日志并应用到自身.一个复制环境仅仅只需要两台运行有MySQLServer的主机即可,甚至更为简单的时候我们可以在同一台物理服务器主机上面启动两个mysqldinstance,一个作为Master而另

Mysql千万级数据性能调优配置

背景: 笔者的源数据一张表大概7000多万条,数据大小36G,索引6G,加起来表空间有40G+,类似的表有4张,总计2亿多条 数据库mysql,引擎为innodb,版本5.7,服务器内存256G,物理内存几个T,硬件参数杠杠的,然而处理这些数据踩了不少坑,因 为之前没做过这方面的工作,现在记录下清洗的过程,详细的业务清洗过程和规则均记录在https://gitee.com/yanb618/zhirong/wikis 感受: 清洗从表名,字段名,字段类型,字段值,索引创建与删除做起,每每看到那秒数