我最新的慢日志去哪了？-阿里云开发者社区

我最新的慢日志去哪了？

2017-07-06 2938

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云数据库 RDS MySQL，集群系列 2核4GB

RDS MySQL Serverless 基础系列，0.5-2RCU 50GB

RDS MySQL Serverless 高可用系列，价值2615元额度，1个月

简介： 最近接到一个客户说，我在easydb中为什么看不到实时的慢sql，只能看到过气的慢日志的？慢日志对于MySQL来说确实，是非常重要的，无论是问题排查还是性能优化，都能从其中捕获一些问题的来源，如果慢日志失去了实时性那还了得？然后即刻登到easydb中去看，发现最新的慢日志定格在了7月5号晚22：00左右。

最近接到一个客户说，我在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 2017

MySQL的时间

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有什么区别呢？这两个参数是干什么的呢？

看一下官方文档的解释：

也就是说这个参数才是真正的控制服务器的区时，且在MySQL一旦运行，这个区时就是写死了的，不会变。那么也就是很有可能是由于这两个参数的问题导致我的慢日志的时间变慢了。来测试一下

启动MySQL的时候指定timezone为CST

发现这个时候的MySQL系统时间慢了8个小时，而且慢日志的时间跟这个时间是一致的，也是慢了8个小时。

./bin/mysqld_safe --defaults-file=/home/my3301/my.cnf --timezone=CST-8 &

启动MySQL的时候指定timezone为CST-8

发现这个时候的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小时“前”的原因了~