MySQL · 特性分析 · 5.7 error log 时区和系统时区不同

问题描述

现象

5.6 和 5.7 时区设置相同,select now()也显示当前时间

5.7 error log 中时间和当前时间差8小时

问题分析

5.6 写 error log 函数如下

取时间的函数是localtime_r(&skr, &tm_tmp)

日志中时间和系统时区相同

    static void print_buffer_to_file(enum loglevel level, const char *buffer,
                                     size_t length)
    {
      time_t skr;
      struct tm tm_tmp;
      struct tm *start;
      DBUG_ENTER("print_buffer_to_file");
      DBUG_PRINT("enter",("buffer: %s", buffer));

      mysql_mutex_lock(&LOCK_error_log);

      skr= my_time(0);
      localtime_r(&skr, &tm_tmp);
      start=&tm_tmp;

      fprintf(stderr, "%d-%02d-%02d %02d:%02d:%02d %lu [%s] %.*s\n",
              start->tm_year + 1900,
              start->tm_mon + 1,
              start->tm_mday,
              start->tm_hour,
              start->tm_min,
              start->tm_sec,
              current_pid,
              (level == ERROR_LEVEL ? "ERROR" : level == WARNING_LEVEL ?
               "Warning" : "Note"),
              (int) length, buffer);

      fflush(stderr);

      mysql_mutex_unlock(&LOCK_error_log);
      DBUG_VOID_RETURN;
    }

5.7 写 error log 函数如下

取时间的函数是 make_iso8601_timestamp(my_timestamp)

    static void print_buffer_to_file(enum loglevel level, const char *buffer,
                                     size_t length)
    {
      DBUG_ENTER("print_buffer_to_file");
      DBUG_PRINT("enter",("buffer: %s", buffer));

      char my_timestamp[iso8601_size];

      my_thread_id thread_id= 0;

      /*
        If the thread system is up and running and we're in a connection,
        add the connection ID to the log-line, otherwise 0.
      */
      if (THR_THD_initialized && (current_thd != NULL))
        thread_id= current_thd->thread_id();

      make_iso8601_timestamp(my_timestamp);

      /*
        This must work even if the mutex has not been initialized yet.
        At that point we should still be single threaded so that it is
        safe to write without mutex.
      */
      if (error_log_initialized)
        mysql_mutex_lock(&LOCK_error_log);

      if (error_log_buffering)
      {
        // Logfile not open yet, buffer messages for now.
        if (buffered_messages == NULL)
          buffered_messages= new (std::nothrow) std::string();
        std::ostringstream s;
        s << my_timestamp << " " << thread_id;
        if (level == ERROR_LEVEL)
          s << " [ERROR] ";
        else if (level == WARNING_LEVEL)
          s << " [Warning] ";
        else
          s << " [Note] ";
        s << buffer << std::endl;
        buffered_messages->append(s.str());
      }
      else
      {
        fprintf(stderr, "%s %u [%s] %.*s\n",
                my_timestamp,
                thread_id,
                (level == ERROR_LEVEL ? "ERROR" : level == WARNING_LEVEL ?
                 "Warning" : "Note"),
                (int) length, buffer);

        fflush(stderr);
      }

      if (error_log_initialized)
        mysql_mutex_unlock(&LOCK_error_log);
      DBUG_VOID_RETURN;
    }

make_iso8601_timestamp 中有代码段如下

参数 opt_log_timestamps 控制时间

 if (opt_log_timestamps == 0)
    gmtime_r(&seconds, &my_tm);
  else
  {
    localtime_r(&seconds, &my_tm);

opt_log_timestamps 对应 sys_vars.cc 中的 log_timestamps

取值 const char *timestamp_type_names[]= {“UTC”, “SYSTEM”, NullS};

log_timestamps = 0 时,日志中是 UTC 时区

log_timestamps = 1 时,日志中是 SYSTEM 时区

5.7 默认 log_timestamps = 0

5.7 error log 使用系统时区

set global log_timestamps = 1;

时间: 2024-11-16 16:47:15

MySQL · 特性分析 · 5.7 error log 时区和系统时区不同的相关文章

MySQL · 特性分析 · innodb buffer pool相关特性

背景 innodb buffer pool做为innodb最重要的缓存,其缓存命中率的高低会直接影响数据库的性能.因此在数据库发生变更,比如重启.主备切换实例迁移等等,innodb buffer poll 需要一段时间预热,期间数据库的性能会受到明显影响. 另外mysql 5.7以前innodb buffer pool缓存大小修改不是动态的,重启才能生效.因此innodb buffer pool的预热和innodb buffer pool大小的动态修改,对性能要求较高的应用来说是不错的特性,下面

MySQL · 特性分析 · MySQL 5.7新特性系列一

1. 背景 MySQL 5.7在2015-10-21发布了GA版本,即5.7.9,目前小版本已经到了5.7.12.5.7新增了许多新的feature和优化,接下来一个系列,我们就一起来尝尝鲜.首先这次主要是预览feature的变化以及兼容性问题.后面的系列,会针对重要的feature展开来学习. 2 安全相关的特性 2.1 认证插件 mysql.user表中的plugin更改成not null,5.7开始不再支持mysql_old_password的认证插件,推荐全部使用mysql_native

MySQL · 特性分析 ·MySQL 5.7新特性系列三

继上两期月报,MySQL5.7新特性之一介绍了一些新特性及兼容性问题,MySQL 5.7新特性之二介绍了临时表的优化和实现. 这期我们一起来学习下undo空间管理,重点介绍truncate功能. 1. 背景 InnoDB存储引擎中,undo在完成事务回滚和MVCC之后,就可以purge掉了,但undo在事务执行过程中,进行的空间分配如何回收,就变成了一个问题. 我们亲历用户的小实例,因为一个大事务,导致ibdata file到800G大小. 我们先大致看下InnoDB的undo在不同的版本上的一

MySQL · 特性分析 · InnoDB transaction history

1. 背景 在写压力负载比较重的MySQL实例上, InnoDB可能积累了较长的没有被purge掉的transaction history,导致实例性能的衰减,或者空闲空间被耗尽,下面就来看看它是怎么产生的,或者有没有什么方法来减轻,避免这样的问题出现. 2. InnoDB purge概要 InnoDB是一个事务引擎,实现了MVCC特性,也就是在存储引擎里对行数据保存了多个版本.在对行数据进行delete或者update更改时,行数据的前映像会保留一段时间,直到可以被删除的时候. 在大部分OLT

MySQL · 特性分析 · MySQL 5.7 外部XA Replication实现及缺陷分析

MySQL 5.7 外部XA Replication实现及缺陷分析 MySQL 5.7增强了分布式事务的支持,解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况. 为了解决之前的问题,MySQL5.7将外部XA在binlog中的记录分成了两部分,使用两个GTID来记录.执行prepare的时候就记录一次binlog,执行commit/rollback再记录一次.由于XA是分成两部分记录,那么XA事务在binlog中就可能是交叉出现的.Slave端的

MySQL · 特性分析 · 浅谈 MySQL 5.7 XA 事务改进

关于MySQL XA 事务 MySQL XA 事务通常用于分布式事务处理当中.比如在分库分表的场景下,当遇到一个用户事务跨了多个分区,需要使用XA事务 来完成整个事务的正确的提交和回滚,即保证全局事务的一致性. XA 事务在分库分表场景的使用 下图是个典型的分库分表场景,前端是一个Proxy后面带若干个MySQL实例,每个实例是一个分区. 假设一个表test定义如下,Proxy根据主键"a"算Hash决定一条记录应该分布在哪个节点上: create table test(a int p

MySQL · 特性分析 ·MySQL 5.7新特性系列四

继上三期月报:MySQL 5.7新特性之一介绍了一些新特性及兼容性问题MySQL 5.7新特性之二介绍了临时表的优化和实现MySQL 5.7新特性之三介绍了undo表空间的truncate功能 这期我们一起来学习下MySQL 5.7的并行复制. 1. 背景 MySQL的master<->slave的部署结构,使用binlog日志保持数据的同步,全局有序的binlog在备库按照提交顺序进行回放. 由于新硬件的发展,SSD的引入和多core的CPU,master节点的并发处理能力持续提升,slav

MySQL · 特性分析 · MDL 实现分析

前言 在MySQL中,DDL是不属于事务范畴的,如果事务和DDL并行执行,操作相关联的表的话,会出现各种意想不到问题,如事务特性被破坏.binlog顺序错乱等,为了解决类似这些问题,MySQL在5.5.3引入了MDL锁(Metadata Locking),关于其设计思路可以参考这两个worklog:WL#3726 和 WL#4284.本篇从代码实现角度对MDL进行分析. 重要数据结构 MDL 是在 MySQL server 层实现的一个模块,通过对外接口和server层其它模块进行交互,在sql

MySQL · 特性分析 · LOGICAL_CLOCK 并行复制原理及实现分析

在MySQL5.7 引入基于Logical clock的并行复制方案前,MySQL使用基于Schema的并行复制,使不同db下的DML操作可以在备库并发回放.在优化后,可以做到不同表table下并发.但是如果业务在Master端高并发写入一个库(或者优化后的表),那么slave端就会出现较大的延迟.基于schema的并行复制,Slave作为只读实例提供读取功能时候可以保证同schema下事务的因果序(Causal Consistency,本文讨论Consistency的时候均假设Slave端为只