概述

本文主要介紹使用阿里云ECS實例搭建MySQL時，基礎(chǔ)問題排查相關(guān)的思路以及方法。

詳細信息

請根據(jù)現(xiàn)場實際情況，參考以下對應(yīng)的解決方案。

無法啟動

具體問題可參考鏈接：Linux實例中MySQL服務(wù)常見的無法啟動或啟動異常處理。

無法連接

客戶端連接MySQL時的各種錯誤判斷，包括如下多種，需要根據(jù)報錯進一步判斷。

• ERROR 1045 (28000): Access denied for user 'testcon'@'10.24.236.231' (using password: YES).

• ERROR 2005 (HY000): Unknown MySQL server host 'rm-XXXXXXXXXXXX.mysql.rds.aliyuncs.com' (110).

• ERROR 1449 (HY000): The user specified as a definer ('testcon'@'10.24.236.231') does not exist.

• ERROR 2003 (HY000): Can't connect to MySQL server on 'test.mysql.rds.aliyuncs.com' (110).

• ERROR 1135 (HY000): Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug.

• ERROR 1130 (HY000): Host '192.168.1.3' is not allowed to connect to this MySQL server.

• ERROR 1045 (HY000): #28000ip not in whitelist.

• ERROR 5 (HY000): Out of memory (Needed 260400 bytes).

• ERROR 1129 (HY000): Host '10.24.236.231' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'.

• ERROR 1226 (42000): User 'testcon' has exceeded the 'max_user_connections' resource (current value: 2).

• ERROR 1040 (HY000): Too many connections.

• ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

• The MYSQL server is running with the -rds-deny-access option so it cannot execute this statement.

• Failed For Connect Mysql Server with high priv, please try again later or check the health of db #RDS00Connect Failed For Mysql Server No Response.

• ERROR 1045 (28000): Access denied for user 'testcon'@'10.24.236.231' (using password: NO).

• Client does not support authentication protocol requestedby server; consider upgrading MySQL client.

空間問題

產(chǎn)生問題的原因

• Binlog 日志文件占用高。

• 數(shù)據(jù)文件占用高。

• 臨時文件占用高。

• 系統(tǒng)文件占用高。

實例空間使用情況可以通過 du -h進行查看。

解決方法

ECS實例支持擴容磁盤空間，升級磁盤空間是解決空間問題的有效方式之一。下面說明不升級空間的情況下解決空間問題的方法。

清理Binlog日志文件

Binlog 文件記錄實例的事務(wù)信息，一般是開啟的。如果短時間內(nèi)實例 DML 操作生成了大量 Binlog 數(shù)據(jù)，有可能會導(dǎo)致超過實例磁盤空間打滿。或者長時間沒有清理binlog，binlog大量堆積，也會導(dǎo)致空間打滿。 解決方法：

• 自動清理binlog，通過參數(shù)expire_logs_days=30來配置binlog保留時長，定時清理。

• 手動清理，手動刪除前需要先確認主從庫當前在用的binlog文件。

  • 主庫：show master status;

  • 從庫：show slave status\G

  • PURGE MASTER LOGS TO 'binlog.xxx';

清理數(shù)據(jù)文件

對于數(shù)據(jù)文件占用空間高的情況，可以通過清理數(shù)據(jù)的方式來減少空間占用情況，比如通過 drop table 和 truncate table 來清理不再需要的數(shù)據(jù)。

1. information_schema.tables 查詢的數(shù)據(jù)容量。

   information_schema.tables 提供的是根據(jù)采樣獲取的表的部分統(tǒng)計信息，因此通過下面的查詢獲取的表、庫數(shù)據(jù)尺寸和實際數(shù)據(jù)文件占用尺寸間會有出入（通常要小于實際數(shù)據(jù)文件占用空間）。

   從下圖中可以看到，在收集表的統(tǒng)計信息前后反饋出的表數(shù)據(jù)量大小存在差異。

   

   注：即使通過 analyze table 命令，重新收集統(tǒng)計信息，得到的數(shù)值通常也小于實際數(shù)據(jù)文件占用空間；比如本例的 16143 MB 也小于該表的數(shù)據(jù)文件實際占用空間。 由于數(shù)據(jù)文件在頻繁的 DML 后會出現(xiàn)數(shù)據(jù)空洞的現(xiàn)象，比較接近實際數(shù)據(jù)文件占用空間的計算方法請參考：

   select      sum(data_length + index_length + data_free) / 1024 / 1024 from     information_schema.tables;

   注：因為 information_schema.tables 中提供的是采樣統(tǒng)計數(shù)據(jù)，因此該計算方式在統(tǒng)計數(shù)據(jù)比較接近實際的情況下，才會比較接近真實空間占用情況。

2. delete 刪除數(shù)據(jù)。

   delete 操作不能夠直接回收被刪除數(shù)據(jù)占用的數(shù)據(jù)文件空間，這就好比排空泳池中水但泳池的占地面積不會發(fā)生改變一樣。而且 delete 操作會生成相應(yīng)的 Binlog 文件，會進一步惡化空間使用情況。 在 delete 操作刪除數(shù)據(jù)后，需要通過 optimize table table_name; 操作來回收空間。

3. 刪除備份。

   定時清理備份。

釋放臨時文件

臨時文件會隨查詢的結(jié)束或者會話的終止而自動釋放，因此如果是臨時文件導(dǎo)致實例空間滿而鎖定，可以通過終止會話來釋放空間。

系統(tǒng)文件處理

系統(tǒng)文件涉及到 ibdata1 系統(tǒng)表空間文件和 ib_logfile0、ib_logfile1 日志文件。

• ibdata1文件：

  InnoDB 引擎表由于支持多版本并發(fā)控制（MVCC），因此會將查詢所需的Undo信息保存在系統(tǒng)文件 ibdata1 中。如果存在對一個 InnoDB 表長時間不結(jié)束的查詢，而且在查詢過程中表有大量的數(shù)據(jù)變化，則會生成大量的 Undo 信息，導(dǎo)致 ibdata1文件尺寸增加。由于 MySQL 內(nèi)部機制的限制，ibdata1 文件目前是不支持收縮的。因此出現(xiàn)這樣的情況，在不升級磁盤空間的前提下，比較好的解決方法是起個新的實例，通過 DTS 工具將數(shù)據(jù)遷移到新實例中。

• ib_logfile 日志文件：

  ib_logfile0 和 ib_logfile1 日志文件保存 InnoDB 引擎表的事務(wù)日志信息，其文件大小尺寸固定，不可以改變。較大的尺寸在高并發(fā)事務(wù)的場景下有利于減少事務(wù)日志文件切換的次數(shù)，提高實例性能。