MySQL数据库性能优化与监控实战(阶段四)

MySQL数据库性能优化与监控实战(阶段四)

作者	刘畅
时间	2020-10-20

目录

1 sys数据库 1

2 系统变量 1

3 性能优化 1

3.1
硬件层 1

3.2
系统层 1

3.3 软件层 3

3.4 表结构、SQL语句、索引 4

3.5 架构层 4

4 安全加固 4

4.1
数据库 4

4.2
操作系统 4

4.3
数据库备份 5

5 数据库监控 5

6 数据库修复 5

6.1
MYISAM表修复 5

6.2
Innodb表修复 5

6.3
主从复制数据不一致 6

7 常见面试题解析 6

7.1
你们怎么对数据库备份的 6

7.2
怎么分析一台MySQL服务器查询慢的原因 6

7.3
常用存储引擎有哪些及特点 6

7.4
遇到过死锁吗？怎么解决的 6

7.5
Sleep线程或者连接数异常过多的原因及解决办法 7

7.6
主从复制原理 7

7.7
如何在线增加从库 7

7.8
主从复制，从服务器宕机或者SQL线程错误如何恢复 7

7.9
主从复制延迟原因及解决办法 7

7.10
怎么清理binlog日志 8

8 补充 8

8.1
主从复制(主节点binlog过期问题) 8

8.2
慢查询日志分析工具 8

8.3
在线清理binlog日志 9

8.4 分析数据库cpu、内存、磁盘IO信息 10

8.5
show
processlist命令与kill 线程 11

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线程都被杀掉了。