27
我最新的慢日誌去哪了？
最近接到一個客戶說，我在easydb中為什麼看不到實時的慢sql，隻能看到過氣的慢日誌的？
慢日誌對於MySQL來說確實，是非常重要的，無論是問題排查還是性能優化，都能從其中捕獲一些問題的來源，如果慢日誌失去了實時性那還了得？
然後即刻登到easydb中去看，發現最新的慢日誌定格在了7月5號晚22：00左右。難道真的是easydb捕獲不到最新的慢日誌了嗎？
但是發現MySQL日誌文件中的slowlog最後一條確實是跟easydb中的最新的一條相一致，那麼easydb依舊是實時抓取slow log。那問題出現在哪裏了呢？
Linux主機？還是MySQL服務器的時間？
Linux所在主機的時間
[root@msyql ]# date
Thu Jul 6 10:35:12 CST 2017MySQL的時間
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2017-07-06 10:36:10 |
+---------------------+
1 row in set (0.00 sec)比較悲傷並沒有看到我們想看到的時間，時間都跟我屏幕右下方的時間相一致。
那問題出在哪裏了呢？到底是哪裏控製了MySQL slow日誌裏麵的時間？
看一下關於MySQL 時間的參數
mysql> show variables like '%time%';
+---------------------------------+-------------------+
| Variable_name | Value |
+---------------------------------+-------------------+
| binlog_max_flush_queue_time | 0 |
| connect_timeout | 8 |
| datetime_format | %Y-%m-%d %H:%i:%s |
| delayed_insert_timeout | 300 |
| explicit_defaults_for_timestamp | ON |
| flush_time | 0 |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 5 |
| innodb_old_blocks_time | 1000 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lc_time_names | en_US |
| lock_wait_timeout | 31536000 |
| long_query_time | 1.000000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| rpl_stop_slave_timeout | 300 |
| slave_net_timeout | 30 |
| slow_launch_time | 2 |
| time_format | %H:%i:%s |
| timed_mutexes | OFF |
| timestamp | 1499328877.100398 |
| wait_timeout | 28800 |
+---------------------------------+-------------------+
25 rows in set (0.00 sec)然後我看了一下我自己的MySQL 關於時間的參數
mysql> show variables like '%time%';
+---------------------------------------+-------------------+
| Variable_name | Value |
+---------------------------------------+-------------------+
| connect_timeout | 10 |
| datetime_format | %Y-%m-%d %H:%i:%s |
| delayed_insert_timeout | 302 |
| flush_time | 0 |
| have_response_time_distribution | YES |
| innodb_lock_wait_timeout | 50 |
| innodb_old_blocks_time | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_thread_concurrency_timer_based | OFF |
| interactive_timeout | 7200 |
| lc_time_names | en_US |
| lock_wait_timeout | 31536000 |
| long_query_time | 1.000000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| query_response_time_range_base | 10 |
| query_response_time_stats | OFF |
| rpl_semi_sync_master_timeout | 1000 |
| slave_net_timeout | 60 |
| slow_launch_time | 2 |
| slow_query_log_timestamp_always | OFF |
| slow_query_log_timestamp_precision | second |
| time_format | %H:%i:%s |
| timed_mutexes | OFF |
| timestamp | 1499329112 |
| trx_changes_idle_timeout | 0 |
| trx_idle_timeout | 0 |
| trx_readonly_idle_timeout | 0 |
| wait_timeout | 86400 |
+---------------------------------------+-------------------+
注：北美東部夏令時間英文名: Eastern Daylight Time 也就是上麵的EDT
北美中部夏令時間英文名: Central Daylight Time 也就是上麵的CST
這個system_time_zone跟time_zone有什麼區別呢？這兩個參數是幹什麼的呢？
看一下官方文檔的解釋：
The server system time zone. When the server begins executing, it inherits a time zone setting from the machine defaults, possibly modified by the environment of the account used for running the server or the startup script. The value is used to set system_time_zone.
./bin/mysqld_safe --defaults-file=/home/my3301/my.cnf --timezone=CST &發現這個時候的MySQL係統時間慢了8個小時，而且慢日誌的時間跟這個時間是一致的，也是慢了8個小時。
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2017-07-06 02:36:10 |
+---------------------+
1 row in set (0.00 sec)./bin/mysqld_safe --defaults-file=/home/my3301/my.cnf --timezone=CST-8 &啟動MySQL的時候指定timezone為CST
發現這個時候的MySQL係統時間跟我左下角的時間就正好吻合了，並且慢日誌的時間跟我左下角的時間一致了。
這其實就驗證了timezone這個參數影響了慢日誌寫入到日誌裏麵的時間了。
那system_time_zone根time_zone又有什麼區別呢？
The system_time_zone variable differs from time_zone. Although they might have the same value, the latter variable is used to initialize the time zone for each client that connects.
也就是一個是服務器係統時區，一個是連接的客戶端的時區。
如果這兩個參數設置不當，就會導致Linux主機係統的時間、MySQL select now()的時間，還有慢日誌等日誌產生的時間不一致。
這也就是為什麼客戶的慢日誌為啥隻能收集到12小時“前”的原因了~
最後更新：2017-07-06 17:32:19