MySQL基線指標的採集：
關鍵指標 |
|---|
| qps |
| tps |
| connections |
| slave_lag |
| cpu_load |
disk load |
| memory usage |
系統指標 採集方式 |
|---|
| df |
| node_exporter |
| ps |
| uptime |
| vmstat / netstat / dstat / iostat |
MySQL指標 採集方式 |
|---|
| 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文件體積：
SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "DB Size in MB" FROM information_schema.tables; |
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
參考文章：
https://severalnines.com/blog/capacity-planning-mysql-and-mariadb-dimensioning-storage-size
http://www.jebriggs.com/blog/2010/07/mysql-storage-capacity-planning/