运营那边说,后台获取的数据,时间都不准确了,立马找到运维这边,程序那边也给我这边提供了一个线索,就是在mysql里面执行了
SELECT from_unixtime(1476883657);
显示的时间并不是北京时间。因为最近刚把mysql搬到了香港,需要都按照北京时间来设置服务器时间。
先看了下服务器的系统时间
date Thu Oct 20 13:54:12 EDT 2016
时间确实不正确,设置下系统时间
date -s "2016-10-20 14:41:31"
写入cmos
clock -w
以为这就完事了,再到数据库里面查看一下,
>SELECT from_unixtime(1476883657);
显示的时间还是不对,
>select now();
查看数据库当前时间,也是不正确的,这是为啥了
后来定睛一看,原来时区有问题。那么要修改一下系统时区
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime cp: overwrite `/etc/localtime’? y
再在服务器上查看一下
date Thu Oct 20 13:54:12 CST 2016
ok了,时区变成了CST了,而不是之前的EDT;现在服务器的系统时间和时区都对了,再到mysql里面查看一下当前时间和时间戳显示正确与否。
查看当前时间:
>select now(); 或者>select sysdate()
>SELECT from_unixtime(1476883657);
还是有问题,那么分析下来,应该就是mysql的时区问题了
>show variables like "%time_zone%"; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | EDT | | time_zone | SYSTEM | +------------------+--------+ 2 rows in set (0.00 sec)
#time_zone说明mysql使用system的时区,system_time_zone说明system使用EDT时区
果然mysql的时区没有改过来,表明mysql使用的是之前的系统时区,需要重启一下才能解决这个问题,当时线上业务怎么能轻易重启,那么就要使用临时的方法。
> set global time_zone = ‘+8:00‘; ##修改mysql全局时区为北京时间,即我们所在的东8区 > set time_zone = ‘+8:00‘; ##修改当前会话时区 > flush privileges; #立即生效
好了,再来看看mysql的时区问题
>show variables like "%time_zone%"; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | EDT | | time_zone | +08:00 | +------------------+--------+ 2 rows in set (0.00 sec)
再来试试时间戳,ok,因为数据库里面都是以时间戳来存储的,所以修改了mysql的时区和系统的时间、时区后顺利地解决了问题。
这里值得考虑的是,因为系统的时区修改了,时间也修改了,并且写入了CMOS,那么即使服务器重启,时间和时区也都是正确的,而mysql也需要重启才能读取到系统的最新时区,既然系统时区和时间都是正确的,那么mysql即使重启时区和时间也是正确的。这也是永久性做法。
时间: 2024-11-04 05:11:14