MySQL数据库性能优化与监控实战(阶段四)
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
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线程都被杀掉了。
