MySQL基线指标的采集:关键指标qps
tps
connections
slave_lag
cpu_load
disk load
memory usage系统指标 采集方式df
node_exporter
ps
uptime
vmstat / netstat / dstat / iostatMySQL指标 采集方式SHOW [TABLE] STATUS
SHOW FULL PROCESSLIST
SHOW OPEN TABLES WHERE In_use> 0
INFORMATION_SCHEMA 库
PERFORMANCE_SCHEMA 库
sys 库
slow query log
mytop/innotop/pt-toolkit
mysqld_exporter
MySQL容量管理:
1、数据库大小估计
一种可靠的方式是 使用解压后的备份文件(必须是Xtrabackup的物理备份)来估算当前数据库的体积。 mysqldump这种逻辑备份的方式,不便于直观的比对数据库体积的增长。
或者我们可以使用如下SQL 估算data文件体积:
2、二进制日志大小估计
统计一天内二进制日志大小,并将其与expire_logs_days值相乘。设置expire_logs_days非常重要,这样您就可以正确估算大小。
3、其它文件大小估计
3.1 MySQL在大的查询过程中,可能会产生巨量临时表。 【size of largest table * 2 (for tmp/sort files)】
3.2 在做表DDL的时候,操作过程中,需要产生的一个大的临时表,需要占据较大的体积。
3.3 ibdata1 、redolog 、slowlog 、general_log 等文件
3.4 注意tmpdir的路径及占据的体积
3.5 本地备份文件(如果有在本地存放备份文件的话)
3.6 至少预留百分之五的空闲磁盘空间留给操作系统使用
4、relaylog的大小估算
某些场景下(例如数据库体积超过1T),我们可能不再做每周的全量备份,而增加一个延迟复制slave的方式。 这种情况下,需要关注下延迟复制slave所在机器的relay-log的体积(延迟的N小时 * N小时内主库产生的binlog的体积)。
容量预测
根据数据库的历史监控数据(zabbix 或 prometheus) ,我们可以大致预测数据文件的周增长量、binlog的周增长量 以及系统负载波动的趋势。
容量解决之道
1、历史数据归档
根据业务场景,按照时间归档,迁移历史数据到大容量廉价低速的磁盘。降低生产环境数据库体积和负载,较小的表体积,便于数据库备份和DDL操作。
2、数据分片
2.1 客户端分片
sharding-jdbc
2.2 中间件分片
dble、mycat、cetus