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="\\[email protected]\\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

时间: 2024-10-06 02:21:41

mysql特性及部署规范的相关文章

Linux系统部署规范v1.0

Linux系统部署规范v1.0 目的: 1.尽可能减少线上操作: 2.尽可能实现自动化部署: 3.尽可能减少安装服务和启动的服务: 4.尽可能使用安全协议提供服务: 5.尽可能让业务系统单一: 6.尽可能监控可监控的一切信息: 7.尽可能控制一切可控制的安全策略: 8.尽可能定期更新补丁修补漏洞: 具体规范: A. 帐户和口令 帐户: 1.为每个系统维护人员建立一个独立的普通权限帐号,为监控机建立监控帐号,分别用于日常系统维护和系统监控: 2.FTP 服务器配置虚拟帐号: 3.禁止除root 帐

mysql cluster安装部署

mysql cluster安装部署: http://www.178linux.com/36462 IPADDR=192.168.0.71 NETMASK=255.255.255.0 GATEWAY=192.168.0.1 DNS1=192.168.0.1 管理节点(MGM):  192.168.1.71 数据节点1(NDBD1):192.168.1.72 数据节点2(NDBD2):192.168.1.73 sql节点1(SQL1):   192.168.1.74 sql节点2(SQL2):  

MySQL主从同步部署

mysql主从同步部署: master:192.168.2.67 slave:192.168.2.211 同步系统非默认库,master中其它库已经运行一段时间. master端: vim /etc/my.cnf server-id       = 1    master端ID号 log-bin=/data/logbin/mysql-bin    日志路径及文件名 #binlog-do-db = debit            同步debit,此处关闭的话,就是除不允许的,其它的库均同步. b

Amoeba实现Mysql读写分离部署文档

以下所有理解纯属个人理解,如若有误欢迎指出,不胜感激--o(∩_∩)o 两台服务器配置MYSQL主从复制实现数据高可用,这时读与写操作都有由master服务器来完成的,而从服务器只是复制了mster服务器的数据,这时可以利用一台服务器配置Amoeba实现mysql读写分离, master负责写,slave负责读取,当然 也可以有多个salve-- 从而减轻master服务器的压力,实现负载分摊: 拓扑图: Mysql主从复制原理: 两台mysql服务器一个作为master一个为slave:mas

nginx php mysql安装和部署

安装MySQL 安装mysql很简单,我用的是centos系统 安装mysql可以用yum命令安装 [html] view plain copy print? yum install -y mysql-server mysql-devel mysql yum install -y mysql-server mysql-devel mysql 安装PHP 安装php麻烦的地方是在configure的时候选项的配置 如果php版本是5.2.x 还需要安装php-fpm 先下载php-fpm代码,解压

多IDC数据分布--MySQL多机房部署 - 学习笔记 - 51CTO技术博客

多IDC数据分布--MySQL多机房部署 - 学习笔记 - 51CTO技术博客 多IDC数据分布--MySQL多机房部署

mysql数据库设计开发规范

1.设计 1. 一般都使用INNODB存储引擎,除非读写比率<1%,才考虑使用MYISAM存储引擎:其他存储引擎请在DBA的建议下使用. 2. Stored procedure (包括存储过程,函数,触发器)对于MYSQL来说还不是很成熟,没有完善的出错记录处理,不建议使用. 3. UUID(),USER()这样的MYSQL INSIDE函数对于复制来说是很危险的,会导致主备数据.不一致.所以请不要使用.如果一定要使用UUID作为主键,让应用程序来产生. 4. 请不要使用外键约束,如果数据存在外

实现MySQL读写分离 部署集群基础环境(有图)

实现MySQL读写分离 部署集群基础环境 1 实现MySQL读写分离1.1 问题 本案例要求配置2台MySQL服务器+1台代理服务器,实现MySQL代理的读写分离: 用户只需要访问MySQL代理服务器,而实际的SQL查询.写入操作交给后台的2台MySQL服务器来完成 其中Master服务器允许SQL查询.写入,Slave服务器只允许SQL查询 1.2 方案 使用4台RHEL 7.2虚拟机,如图-1所示.其中192.168.4.10.192.168.4.20分别作为MySQL主.从服务器,是整个服

MySQL生产库开发规范

MySQL开发规范 文件状态:[  ] 草稿[√] 正式发布[  ] 正在修改 文件标识:  当前版本: V1.0 作    者: 贺磊 完成日期: 2016-05-24 变更记录序号 修改日期 修改内容 修改人 审核人 批准人 批准日期1 2016-05-24 MySQL开发规范 贺磊 MySQL开发规范1. 简介持续借鉴.收集并整理一些开发规范和技巧,期望能更充分利用MySQL的特性,得到更好的性能.规范是死的,人是活的.现在定义的规范,是为以后推翻准备的.1.1 目的提供给开发人员参考,方