1.有問題
近日發現某庫錯誤日誌裡產生大量日誌輸出，經分析是資料庫的InnoDB監控被莫名開啟後未及時關閉引起的，影響日誌記錄和資料庫效能。查看innodb_status_output和innodb_status_output_locks狀態均為ON。
mysql> show variables like"innodb_status_output%"; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | innodb_status_output | ON | | innodb_status_output_locks| ON | +----------------------------+-------+ 2 rows in set (0.00 sec)
2. InnoDB監控相關的兩個參數
InnoDB有四種監控類型，包括StandardMonitor、LockMonitor、TablespaceMonitor、TableMonitor，其中後面兩類監控在5.7版本中移除，LockMonitor、TablespaceMonitor、TableMonitor，其中後面兩類監控在5.7版本中移除，獲取。 Standard Monitor監視活動事務持有的表鎖、行鎖，事務鎖等待，線程信號量等待，文件IO請求，buffer pool統計信息，InnoDB主線程purge和change buffer merge活動；Lock Monitor提供額外的鎖定信息。
InnoDB的monitor只在需要的時候開啟，它會造成效能開銷，觀察結束後切記關閉監控。
StandardMonitor開啟關閉方法如下，innodb_status_output參數就是用來控制InnoDB的monitor開啟或關閉的。這種開啟方法會將監控結果輸出到資料目錄下的MySQL錯誤日誌中，每隔15秒產生一次輸出，也就是發現錯誤日誌下產生大量輸出的原因。
set GLOBAL innodb_status_output=ON/OFF;
Lock Monitor開啟關閉方法如下，注意開啟前必須先開啟innodb_status_output，而關閉時只需要直接關閉innodb_status_output_locks，如果關閉了innodb_status_output，那麼Standard Monitor也會被關閉。
set GLOBALinnodb_status_output=ON;
set GLOBAL innodb_status_output_locks=ON;3.安全審計日誌追溯分析
上述莫名開啟作業考慮透過安全審計日誌來追溯，安全審計日誌範例欄位分析如下：
<AUDIT_RECORD> <NAME>Query</NAME> <RECORD>12050XXXXX_2016-08-08T08:07:52</RECORD> <TIMESTAMP>2016-09-17T06:10:40 UTC</TIMESTAMP> <COMMAND_CLASS>select</COMMAND_CLASS> <CONNECTION_ID>1618XXX</CONNECTION_ID> <STATUS>0</STATUS> <SQLTEXT>select 1</SQLTEXT> <USER>XX[XX]@ [172.XX.XX.XXX]</USER> <HOST></HOST> <OS_USER></OS_USER> <IP>172.XX.XX.XXX </IP> </AUDIT_RECORD>
上述日誌
<NAME>A string representing the typeof instruction that generated the audit event, such as a command that theserver received from a client.操作类型； <RECORD_ID>A unique identifier forthe audit record. The value is composed from a sequence number and timestamp,in the format SEQ_TIMESTAMP. The sequence number is initialized to the size ofthe audit log file at the time the audit log plugin opens it and increments by1 for each record logged. The timestamp is a UTC value in yyyy-mm-ddThh:mm:ss formatindicating the time when the audit log plugin opened the file.记录ID； <TIMESTAMP>The date and time that theaudit event was generated. For example, the event corresponding to execution ofan SQL statement received from a client has a <TIMESTAMP> value occurringafter the statement finishes, not when it is received. The value has the formatyyyy-mm-ddThh:mm:ss UTC (with T, no decimals). The format includes a time zonespecifier at the end. The time zone is always UTC.语句执行完成的时间； <COMMAND_CLASS>A string thatindicates the type of action performed.操作指令类型； <CONNECTION_ID>An unsigned integerrepresenting the client connection identifier. This is the same as theCONNECTION_ID()function value within the session;会话连接ID； <STATUS>An unsigned integerrepresenting the command status: 0 for success, nonzero if an error occurred.This is the same as the value of the mysql_errno()C API function.0代表成功，非0代表对应错误码； <SQLTEXT>A string representing thetext of an SQL statement. The value can be empty. Long values may be truncated.This element appears only if the <NAME> value is Query or Execute.执行的SQL语句； 等等
rrreee
上述日誌 參數意義後，便可從安全審計日誌中grep對應的關鍵字「innodb_status_output」及其上下文日誌內容，格式內容同上，再根據上述解析分析可以審計出做這個莫名操作的帳號，操作時間，操作來源IP地址等訊息，實現異常問題的可追溯。 4.小結 （1） InnoDB的monitor只在需要的時候開啟，觀察結束後及時關閉，因為它會影響資料庫效能和日誌輸出；（2）類似異常操作可透過安全審計日誌追溯，安全審計日誌的記錄時效需要在有效範圍內，須平衡儲存空間和記錄時效；（3）更重要的事，需要注意Audit Log Logging Control以及帳戶權限管理控制。 以上就是InnoDB monitor被莫名開啟的問題分析的內容，更多相關內容請關注PHP中文網（www.php.cn）！
