MySQL时间慢了八个小时

koflover

　　由于我公司另外一个运维小伙伴装系统的时候，勾选了UTC这个东东。（会导致慢八个小时的时间误差）结果才有了这一次逗比的经历。
　　1、系统时间慢八个小时，我发现不对劲后，就改回来了，可参考我的另外一篇博客。
　　2、数据库慢了八个小时，当时并没有意识到这个问题。
　　突然在做实验，老大喊我，说MySQL时间不对劲，让我帮忙解决一下。啥？不会吧，当时首先是这个反正，去看看后，果然时间不对，和本地时间比较一下，相差八个小时。我顿时反应就是，又是那UTC惹的祸。好吧，排查吧，毕竟先解决问题才是硬道理啊。
　　了解：
　　5.10.8. MySQL服务器时区支持
　　MySQL服务器有几个时区设置：
　　· 系统时区。服务器启动时便试图确定主机的时区，用它来设置system_time_zone系统变量。
　　· 服务器当前的时区。全局系统变量time_zone表示服务器当前使用的时区。初使值为'SYSTEM'，说明服务器时区与系统时区相同。可以用--default-time-zone=timezone选项显式指定初使值。如果你有SUPER 权限，可以用下面的语句在运行时设置全局变量值：
　　·mysql> SET GLOBAL time_zone = timezone;
　　·   每个连接的时区。每个客户端连接有自己的时区设置，用会话time_zone变量给出。其初使值与全局变量time_zone相同，但可以用下面的语句重设：
　　·mysql> SET time_zone = timezone;
　　可以用下面的方法查询当前的全局变量值和每个连接的时区
mysql> SELECT @@global.time_zone, @@session.time_zone;　　
+--------------------+---------------------+
　　
| @@global.time_zone | @@session.time_zone |
　　
+--------------------+---------------------+
　　
| SYSTEM             | SYSTEM              |
　　
+--------------------+---------------------+
　　
1 row in set (0.00 sec)
　　
mysql>
　　解决方案；
　　1、临时解决方案
　　查看当前数据库时间
mysql> select CURTIME();　　
+-----------+
　　
| CURTIME() |
　　
+-----------+
　　
| 08:53:05  |
　　
+-----------+
　　
1 row in set (0.00 sec)
　　
mysql> select now();
　　
+---------------------+
　　
| now()               |
　　
+---------------------+
　　
| 2016-01-31 08:53:08 |
　　
+---------------------+
　　
1 row in set (0.00 sec)
　　
mysql>
　　
修改时区：
　　
mysql> SET time_zone = '+8:00';  # 此为北京时，我们所在东8区
　　
Query OK, 0 rows affected (0.00 sec)
　　
mysql> flush privileges;
　　
Query OK, 0 rows affected (0.00 sec)
　　
mysql>
　　2、永久解决方案
vim /etc/my.cnf　　
[mysqld]
　　
default-time_zone = '+8:00'
　　
重启mysql服务。
　　
/etc/init.d/mysqld restart
　　
　　3、其他问题：
　　数据库如果有主从结构，重启数据库会导致主从不同步。
　　个人建议的方法：
　　1、先停止slave （stop slave；）然后先修改slave的时区（很不幸，系统不是自己装的），等到服务器重启后，查看slave同步binlog的位置，然后修改Master的时区，重启后查看当前master的位置，重新授权，salve重新学习（可从slave重启后查看的位置学习），最后再start slave；不出意外，这样是可行的，毕竟我是这样操作。
　　2、如果不行失败，那就等master和slave时区都改好后，查看master当前位置，然后slave导入最新数据库，然后重新学习。
　　3、我尝试过slave不导入最新数据，从一开始从master的binglog位置学习，但是实验报错了。后来有从新导入最新数据，然后学习的。（具体为什么失败，并不清楚，网上关于重启数据库，主从不同步的原因有很多。）
　　个人总结：
　　1、涉及到数据库的问题，最好先在实验环境模拟真实环境，操作无误再在生产环境执行，避免不必要的错误。如果问题比较大，记得先做好备份，备份才是王道。
　　2、遇到问题，先冷静，仔细排查。不要抱怨，先解决问题，再建议。
　　3、不要忽略一些不必要的问题。一个小小的UTC，居然带来了这么多的小弯路。