Dble连接mysql连接数_MySQL 基线与容量管理

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

参考文章：