mysql特性及部署规范

--分支版本,mysql对cpu,内存,io子系统资源利用特点
--oracle mysql,mariadb,percona server
--部署规范建议,系统安装,mysql安装,其他规范
互联网业务为什么选择MySQL,主要是因为:
1、不要复杂事务支持,RR级别下,辅助next-key lock,就可以满足高一致性要求了;
2、真的需要物化视图时,可以采用触发器的方式变相实现;
3、不支持函数索引、hash join、bitmap索引,虽然是硬伤,但大部分互联网应用都不需要这么强的功能需求,
或者可以对产品需求进行改造;
4、查询优化器在持续改进中,需要一个过程,而且绝大多数都是简单应用,整体来说还好;

评论数量,计数器,就存储在redis
云数据库
文档类型的
大数量运算
基于LBS的引用--地理位置应用
都可以采用mongodb

MySQL利用硬件资源特点
CPU的利用特点
• <5.1,多核心支持较弱
• 5.1,可利用4个核
• 5.5,可利用24个核
• 5.6,可利用64个核
• 每个连接对应一个线程,每个并发query只能使用到一个核
内存利用特点:
• 类似ORACLE的SGA、PGA模式,注意PGA不宜分配过大
• 内存管理简单、有效。在高TPS、高并发环境下,可增加物理内存以减少物理IO,提高并发性能
• 官方分支锁并发竞争比较严重,MariaDB、Percona进行优化
• 有类似ORACLE library cache的query cache,但效果不佳,建议关闭
• 执行计划没有缓存(类似ORACLE的library cache)
• 通常内存建议按热点数据总量的15%-20%来规划,专用单实例则可以分配物理内存的50~70%左右
• 类似K-V简单数据,采用memcached、Redis等NOSQL来缓存
磁盘
• undo log的I/O特征:顺序写,随机读;
• Redo Log、Binlog的I/O特征:顺序写,顺序读;
• 数据文件的I/O特征:随机写,随机读;
• OLTP业务以随机IO为主,建议加大内存,尽量合并随机IO为顺序IO
• OLAP业务以顺序IO为主,极大内存的同时增加硬盘数量提高顺序IO性能
• MyISAM是堆组织表(HOT),InnoDB是索引组织表(IOT)
• InnoDB相比MyISAM更消耗磁盘空间
3、 MySQL DBA必备知识体系
a) 硬件知识
• PC Server,了解DELL/HP/IBM,以及国产服务器的管理(idrac,ilo,imm)
• 了解阵列卡的工作原理(阵列组成、条带、WB/WT、BBU),以及如何进行优化
• 了解服务器硬件健康状态、性能监控机制
• 了解磁盘的关键技术指标:转速,有条件的也了解下SSD、PCIe-SSD设备(关键指标:擦写次数,总写入字节数,写放大)。
延迟、iops、吞吐、平均无故障时长、Flash颗粒(MLC/SLC)、读/写带宽、读/写延迟、读/写IOPS、寿命(总写入字节数)
i. 计算机体系结构
北桥被用来处理高速信号,通常处理CPU(处理器),RAM(内存),AGP端口或PCI Express,和南桥芯片之间的通信。
南桥芯片负责I/O总线之间的通信,如PCI总线、USB、LAN、ATA、SATA、音频控制器、键盘控制器、实时时钟控制器、高级电源管理等。
NUMA
CPU通过QPI总线直接控制内存
PCIE/PCI-E,PCI-Express是最新的总线和接口标准,由英特尔提出的,代表着下一代I/O接口标准。
它的主要优势就是数据传输速率高,目前最高的16X 2.0版本可达到10GB/s,而且还有相当大的发展潜力。
ii. SAS 和SATA区别
SAS是为了以任务为中心的企业应用程序而设计的,而SATA则是在消费者市场上常见的拥有一般用途的接口
- SAS支持多个启动程序,而SATA不提供这种功能
- SAS是双端口的,而SATA是单端口的。因此,SAS可以在没有额外的硬件的情况下支持多路径I/O。
iii. SSD架构
iv. PCIe SSD和普通SSD的区别
一个是PCIE上进行数据交换(绕过总线),一个是SAS/SATA(经过总线)。
前者带宽更加大,且PCIe SSD一般存储总容量也大很多。
b) 系统知识
i. Linux管理
基础知识、基本操作
常规服务管理技能
网络、安全相关知识
内核相关参数理解

安装规范
a) 系统安装规范
硬件设置
• 偶数盘组成RAID 1+0,FORCE WB策略,CACHE卡越大越好,可将所有CACHE都用于写缓存加速,关闭预读
可将所有CACHE都用于写缓存加速,关闭预读 = FORCE WB 、以及 NORA 的cache策略
--双电源,双电路,ups
• 如果是SSD,建议RAID1(两块不同使用生命周期的盘,降低同时故障的概率),保证数据安全性
DELL服务器的阵列卡为例:
Default Cache Policy: WriteBack, ReadAdaptive, Direct, Write Cache OK if Bad BBU
MegaCli64 -ldsetprop NORA -lall -aall -nolog
NORA = NO readahead
opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop NORA -lall -aall -nolog
WriteBack = WB
ReadAheadNone = NORA
WriteBack + Write Cache OK if Bad BBU = FORCE WB

raid10 ,先做raid1,对2组raid1做raid0
操作系统
• CentOS/RHRL/ORACLE Linux 5.x/6.x x86_64发行版
CentOS、Ubuntu、RHEL,优先建议这三种OS
文件系统
• datadir及backupdir所在分区采用xfs,最起码也要用ext4,# df -T
ioscheduler
• SSD使用noop策略,其他使用deadline策略
最大文件数
• ulimit -n 65535,默认的1024一般都不够用
最大进程数
• ulimit -u 65535,默认的一般都不够用
其他需要注意的地方有
• 关闭selinux
• 设置 vm.swappiness = 0减少swap( RHEL 7以上设置为10,避免OOM)
• 关闭NUMA,提高内存利用率和CPU性能
• 关闭CPU节能模式,提高CPU性能
datadir
• 单实例 /data/mysql
• 多实例 /data/mysql/yejr_3306 、 /data/mysql/yejr_3307
backupdir
• /backup 或其他独立分区下的目录
其他
• 多实例默认使用 mysqld_multi 来管理
• 默认关键参数
• transaction_isolation = READ-COMMITTED
• innodb_flush_method = O_DIRECT (尤其是从ORACLE转到MySQL的要注意)O_DIRECT,饶过OS page cache,直接写阵列卡
• innodb_file_per_table = 1
• innodb_flush_log_at_trx_commit = 1
• innodb_data_file_path = ibdata1:1G:autoextend
• long_query_time = 1
• log-output=file
• slow_query_log = 1
• lower_case_table_names = 0
[mysql]
prompt="\u@\h \D \R:\m:\s [\d]&get;
#pager="less -i -n -S"
tee=/home/mysql/query.log
no-auto-rehash
c) 其他规范要点
开发环境规范
• 启用log_queries_not_using_indexes
• 设置long_query_time为最小值
• 定期检查分析slow log
• 授权和生产环境一致
• 关闭Query Cache
• 设置较小InnoDB Buffer Pool、key buffer size
• 数据量不能太少,否则有些性能问题无法提前规避

假设有这么一个slow log
# Query_time: 0.01034848 Lock_time: 0.000697 Rows_sent: 1 Rows_examined: 1708000
SET timestamp=1399534522;
select * from global_status_diff;
需要注意:
1、扫描大数据集,但返回很少结果
2、没有LIMIT
3、没有WHERE
4、SELECT *
行为规范
• 批量导入、导出数据须提前通知DBA,请求协助观察
• 推广活动或上线新功能须提前通知DBA,请求压力评估
• 不使用SUPER权限连接数据库
• 单表多次ALTER操作必须合并为一次操作
• 数据库DDL及重要SQL及早提交DBA评审
• 重要业务库须告知DBA重要等级、数据备份及时性要求
• 不在业务高峰期批量更新、查询数据库
• 提交线上DDL需求,所有SQL语句须有备注说明
有SUPER权限的用户,是可以对read-only的slave库写入数据的

原文地址:https://www.cnblogs.com/yhq1314/p/10278235.html