MySQL数据库性能优化与监控实战(阶段四)
作者 |
刘畅 |
时间 |
2020-10-20 |
目录
7.5
Sleep线程或者连接数异常过多的原因及解决办法 7
1 sys数据库
2 系统变量
mysql> show global variables\G;
# 查看mysql全局可修改变量
mysql> show global status\G;
# 查看mysql全局不可修改变量,该变量由系统运行时生成
3 性能优化
3.1
硬件层
(1) cpu:双路cpu
(2)
内存:双路内存条
(3)
硬盘:ssd代替sas/sata机械硬盘
(4) RAID卡:建议RAID0或者RADI10,中高端RAID,带缓存。
H330阵列卡是无缓存的,H730阵列卡是1G的缓存,H730P阵列卡是2G的缓存。
3.2
系统层
(1)
Linux磁盘I/0调度算法
磁盘io使用deadline调度算法
1) CFQ(完全公平排队I/O调度程序)
CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择。
2) NOOP(电梯式调度程序)
NOOP对于闪存设备(SSD),RAM,嵌入式系统是最好的选择。
3) Deadline(截止时间调度程序)
Deadline对数据库环境(ORACLE
RAC,MYSQL等)是最好的选择。
4) 如何修改当前系统的磁盘io调度算法
查看当前操作系统版本
# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
查看当前系统的调度算法
# cat /sys/block/sda/queue/scheduler
noop [deadline]
cfq
修改io调度算法(临时生效)
# echo "deadline"
>/sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
修改io调度算法(永久生效)
# grubby --update-kernel=ALL
--args="elevator=deadline"
# reboot
提示:
该操作会对所有的/dev/sda
/dev/sdb进行操作。如果只对特定
的盘进行设置,可将上面临时生效的命令加入到开机自启文件中。
(2)
减少swap分区使用
1) 临时生效
# echo "0"
>/proc/sys/vm/swappiness
2) 永久生效
# echo "vm.swappiness = 0"
>>/etc/sysctl.conf
# sysctl -p
(3) 增大打开文件数大小
1) 临时生效
# ulimit -SHn 65535
# ulimit -n
65535
2) 永久生效
# cat >>/etc/security/limits.conf
<<EOF
* soft nofile 65535
* hard nofile 65535
EOF
# reboot
(4) 内核参数优化
# cat >>/etc/sysctl.conf<<
EOF
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024
65000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_tw_buckets = 20480
net.ipv4.tcp_max_syn_backlog = 20480
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_fin_timeout = 20
EOF
# sysctl -p
补充:
# 临时生效内核参数
sysctl -w
net.ipv4.tcp_fin_timeout=20
或
echo "20"
>/proc/sys/net/ipv4/tcp_fin_timeout
# 查看生效的内核参数
sysctl -a | grep "tcp_fin_timeout"
3.3 软件层
/etc/my.cnf配置文件参数项优化
[mysqld]
(1)
通用优化参数
max_connections = 10240
# 最大连接数
open_files_limit = 65535
# 文件描述符限制
innodb_buffer_pool_instances = 4
# InnoDB缓冲池划分为的区域数,减少不同线程对缓存页面进行读写的争用,提高并发性。
innodb_buffer_pool_size = 4G
# InnoDB缓存池大小,一般是内存的50%~80%
innodb_flush_log_at_trx_commit = 2
# 每次事务提交时MySQL都会把log buffer的数据写入log file,但是flush(刷到磁盘)操作并不会同时进行,MySQL会每秒执行一次 flush(刷到磁盘)操作。
sync_binlog = 1
# 每次事务提交,MySQL都会把binlog刷下去,是最安全但是性能损耗最大的设置。
innodb_log_file_size = 256M
# 事物日志文件大小,文件位置为 /usr/local/mysql/data/ib_logfile0或/usr/local/mysql/data/ib_logfile1
innodb_flush_method = O_DIRECT
# 数据文件的写入操作是直接从mysql innodb
buffer到磁盘的,并不用通过操作系统的缓冲,而真正的完成也是在flush这步,日志还是要经过OS缓冲。
interactive_timeout = 1800
# 设置客户端交互式连接超时为30分钟,默认28800秒(8小时)。
wait_timeout = 1800
# 设置客户端非交互式连接超时为30分钟,默认28800秒(8小时)。
(2) slave端优化
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 8
# 从库开启多线程事物组复制,降低从库复制延迟
master-info-repository = TABLE
# 将master.info文件存储的主复制信息变为mysql.slave_master_info表方式存储
relay-log-info-repository = TABLE
# 将relay-log.info文件存储的relay-log复制信息变为mysql.slave_relay_log_info表方式存储。
# 基于FILE的存储,修改为TABLE存储,操作后mysql会将FILE文件删除,并将该文件内容写入到table表中。
3.4 表结构、SQL语句、索引
(1)
sql及索引
(2)
分库
(3)
分表
(4)
分区
3.5 架构层
(1)
读写分离
(2)
增加缓存
(3) 分库
4 安全加固
4.1
数据库
1 禁止以root账户运行mysql实例
2 数据库账户分配最小权限
3 账户密码满足复杂性,并90天更换一次
4 根据需要只监听本地或内网地址
5 禁止root账户远程
6 权限申请流程设置规范,合理
4.2
操作系统
1 防火墙只允许可信任IP访问
2 关闭不必要的账户、服务和端口
3 ssh使用证书+密钥认证
4 及时给系统软件打补丁
5 系统、程序日志收集
4.3
数据库备份
1 定期备份
2 备份多份,存储在不同的位置
3 定期检查备份的可用性
5 数据库监控
请参考文档"源码搭建Zabbix4.0.23LTS监控系统.docx",这里就不赘述了。
6 数据库修复
数据库突然断电、异常关闭,导致表损坏,无法读取表数据库。
6.1
MYISAM表修复
(1)
修复MYISAM表(需要停止数据库)
myisamchk -r -q
/usr/local/mysql/data/mysql/func
说明:
/usr/local/mysql/data/mysql/func.MYI表不能加后缀".MYI",否则报如下错误。
(2)
修复包含MYISAM表的数据库(可在线修复)
mysqlcheck -r -q -uroot -p'mysql5.7@2021'
mysql
6.2
Innodb表修复
在/etc/my.cnf中添加如下参数
[mysqld]
innodb_force_recovery = 0
(1)
0默认值,正常启动,不强制修复。
(2) 1-6值越大,修复力度越高,数据损坏风险就越高。
(3)
4或更大的值可能会永久损坏数据文件。
6.3
主从复制数据不一致
(1)
利用percona-toolkit工具对MySQL数据库主从复制数据不一致检查及修复。
1) pt-table-checksum
验证MySQL复制完整性,在主服务器上在线执行复制一致性检查。
2) pt-table-sync
同步MySQL表数据
7 常见面试题解析
7.1
你们怎么对数据库备份的
(1)
数据库比较小的(3、4个G),用mysqldump进行全量的备份,虽然效率不是很高,但是数据的安全性会很高,出现问题的情况很少,是mysql官方的。
(2) 数据量比较大的情况下,几十个G,因为mysqldump是逻辑的备份,导出sql再导入效率会很慢,考虑使用物理备份,即对数据库文件进行备份,这样效率是最高的,主流的软件是xtarbackup,可以对mysql数据库进行完全或增量的备份。
(3) xtrabackup每周一次完整备份,以后是增量备份,解决空间的利用率。
7.2 怎么分析一台MySQL服务器查询慢的原因
(1) 操作系统资源利用率
cpu、内存,磁盘io。qps和cpu的使用率是否吻合,找出cpu占用率高的的进程。
(2) mysql数据库运行情况
mysql线程阻塞,show processlist查看当前mysql是否有长时间占用的相关进程,比如锁等待,查看锁等待的方法为,select
* from sys.innodb_lock_waits;,该表内容多说明锁等待严重。开启mysql慢查询日志,交给开发或dba进行分析优,化mysql语句。如果是业务量增加而导致的mysql查询慢,需要对现有mysql架构做调整。
7.3 常用存储引擎有哪些及特点
(1) myisam:不支持事物,不支持外键,只支持表级别的锁。
(2) innodb:支持事物,支持外键,支持行级锁,有mysql_buffer_pool缓存池。
7.4 遇到过死锁吗?怎么解决的
(1)
死锁是从锁等待演变过来的,不释放,需要人为释放。
(2)
解决死锁的方法
show processlist;查看有没有关于相关的单词,kill掉相关的id,
或select
* from sys.innodb_lock_waits;。
7.5 Sleep线程或者连接数异常过多的原因及解决办法
sleep线程是mysql中的休眠线程,它是mysql做完数据传输后所处的一种状态,为了减少这种状态,可以从以下角度出发。
(1) 应用初始的连接数不要过多,设置连接池,复用连接,使用短连接。
(2)
sys.processlist,kill占用时间最长和使用内存最高的线程。
(3) wait_timeout/interactive_timeout 建议设置20分钟。
7.6 主从复制原理
基于binglog复制和gtid的复制。
7.7 如何在线增加从库
(1) mysqldump
1) 传统备份
备份时加master-data=1参数,这样备份文件中会记录主库的binlog文件名和pos点(如下图),还原到从库上时会记录到master.info中,手动change master指定连接主库的ip、用户名、密码、端口号,开启从库即可。
2) 带有gitd的备份
备份时,主库备份的sql文件中包含了主库已经执行过的gtid事务,将备份还原到主库后,从库会记录主库执行过的gitid信息,手动change master指定连接主库的ip、用户名、密码、端口号,MASTER_AUTO_POSITION=1;,开启从库即可。
(2)
使用xtrabackup物理备份主数据库,再还原到从库上。
7.8
主从复制,从服务器宕机或者SQL线程错误如何恢复
(1) 基于gitd的复制错误,在从库上设置gtid_next跳过当前错误的SQL。
(2)
基于master binlog文件和pos点的主从复制,在从库上设置
set global
sql_slave_skip_counter=<数值>,直到跳过SQL错误即可。
(3)
重新建立主从复制。
7.9
主从复制延迟原因及解决办法
(1)
采用半同步复制
(2)
5.7版本的mysql,从节点开启SQL多线程实现SQL语句的并行回放。
(3)
把从库上存储主节点复制信息和中继日志复制信息的FILE存储,修改为TABLE方式存储。
7.10
怎么清理binlog日志
expire_logs_days自动删除和purge
binary logs to '<需要删除的binlog文件的截止点>'手动删除。
8 补充
8.1
主从复制(主节点binlog过期问题)
gtid配置的主从复制,主停止时间超过了binglog设置的过期时间,主开启后binlog日志过期,但不影响主从复制,如果使用传统pos点做的mysql主从复制则相反。
8.2
慢查询日志分析工具
1 mysql开启慢查询
# vim /etc/my.cnf
[mysqld]
slow_query_log = ON
long_query_time = 2
slow_query_log_file = /usr/local/mysql/data/mysql-slow.log
# systemctl restart mysqld
2 安装mysql慢查询分析软件
(1)
下载
网址:https://www.percona.com/downloads/percona-toolkit/3.2.1/binary/redhat/7/x86_64/percona-toolkit-3.2.1-1.el7.x86_64.rpm
(2)
安装
# yum install
percona-toolkit-3.2.1-1.el7.x86_64.rpm -y
# pt-query-digest --version
pt-query-digest 3.2.1
(3)
分析/usr/local/mysql/data/mysql-slow.log慢查询日志
1) 为了试验,可在线更改慢查询的超时时间
mysql> set global long_query_time = 0;
2) 分析慢查询日志
mysql自带的慢查询日志分析工具
# mysqldumpslow
-t 1
/usr/local/mysql/data/mysql-slow.log
# -t 1表示显示分析的条数
使用pt-query-digest分析
# pt-query-digest --since=24h /usr/local/mysql/data/mysql-slow.log
# --since=24h表示分析最近24小时内的查询
8.3
在线清理binlog日志
# 设置多少天以后清除binlog日志
mysql> set global expire_logs_days = 7;
# 查看设置的binlog自动清除天数
mysql> show global variables like
"%expire%";
# 查看binglog日志
mysql> show binary logs;
# 清空mysql-bin.000011之前的binlog日志
mysql> purge binary logs
to 'mysql-bin.000011';
# 查看binlog日志
mysql> show master logs;
补充:
# 将缓存的binlog日志刷新到binlog文件,并生成新的binlog日志
mysql>
flush logs;
8.4 分析数据库cpu、内存、磁盘IO信息
# yum install sysstat -y
1 cpu分析
# vmstat 1 3
说明:
1 3
表示每一秒输出一次,共输出三次。
wa(io wait
cpu time):cpu等待磁盘写入完成时间,IO等待所占用的CPU时间的百分比高过30%时IO压力高。
# uptime
说明:
主要观察"15分钟系统负荷",将它作为服务器正常运行的指标。标准:15分钟系统负荷/cpu核数 < 0.7
即为正常。
(2)
磁盘IO
# iostat -d 2 3 -x
说明:
-d
2 3 -x表示仅显示磁盘统计信息,每二秒输出一次,共输出三次,输出扩展信息。
%util:采用周期内用于IO操作的时间比率,即IO队列非空的时间比率,如果%util接近100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
8.5
show processlist命令与kill
线程
1 查看线程
mysql> show processlist;
2杀掉Id号为15的线程
mysql> kill 15;
3 查看线程
mysql> show full processlist;
说明:
可以看到mysql
slave端的sql线程都被杀掉了。