MySQL 5.7 时间显示修改(log_timestamps UTC)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

在MySQL 5.7版本中,日志记录时间发生了变化,使用了UTC方式来记录日志时间,也就是说这是个世界统一时间,与我们常用的本地时间不协调,因此,初始化MySQL 5.7之后,需要对此做出调整,如下本文的描述。

一、错误日志的时间格式

当前环境
[robin@ydq-mnt ~]$ more /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[robin@ydq-mnt ~]$ mysql -V
mysql Ver 14.14 Distrib 5.7.19-17, for Linux (x86_64) using 6.2

[root@ydq-mnt ~]#  date  ###系统时间
Mon Dec 18 14:23:16 CST 2018

[root@ydq-mnt ~]# more /var/log/mysqld.log   ###mysql 日志输出信息
2017-12-18T07:50:40.575098Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. 
Please use --explicit_defaults_for_timestamp server option (see do
cumentation for more details).
2017-12-18T07:50:40.576375Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.19-17-57-log) starting as process 9268 ...
2017-12-18T07:50:40.578287Z 0 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; 
so replication may break when this MySQL serve
r acts as a master and has his hostname changed!! Please use '--log-bin=ydq-mnt-bin' to avoid this problem.
2017-12-18T07:50:40.578320Z 0 [Note] WSREP: Setting wsrep_ready to false
2017-12-18T07:50:40.578330Z 0 [Note] WSREP: No pre-stored wsrep-start position found. Skipping position initialization.
2017-12-18T07:50:40.578335Z 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera3/libgalera_smm.so'
2017-12-18T07:50:40.582014Z 0 [Note] WSREP: wsrep_load(): Galera 3.22(r8678538) by Codership Oy 
<info@codership.com> loaded successfully.
从上所示,当前的系统时间为mysql日志记录的时间不一致。
AI 代码解读

二、系统变量log_timestamps

This variable controls the timestamp time zone of error log messages, and of general query log
and slow query log messages written to files. It does not affect the time zone of general query log
and slow query log messages written to tables (mysql.general_log, mysql.slow_log). Rows
retrieved from those tables can be converted from the local system time zone to any desired time
zone with CONVERT_TZ() or by setting the session time_zone system variable.
Permitted log_timestamps values are UTC (the default) and SYSTEM (local system time zone).
Timestamps are written using ISO 8601 / RFC 3339 format: YYYY-MM-DDThh:mm:ss.uuuuuu plus
a tail value of Z signifying Zulu time (UTC) or  hh:mm (an offset from UTC).
This variable was added in MySQL 5.7.2. Before 5.7.2, timestamps in log messages were written
using the local system time zone by default, not UTC. If you want the previous log message time
zone default, set log_timestamps=SYSTEM.
从上描述可知,这个变量是在MySQL 5.7.2中添加的。缺省值为UTC。
如果如要使用缺省时区的时间,修改该参数的值为SYSTEM
AI 代码解读

三、修改及验证

mysql> set global log_timestamps='SYSTEM';
Query OK, 0 rows affected (0.00 sec)

[root@ydq-mnt mysql]# vim /etc/percona-xtradb-cluster.conf.d/mysqld.cnf
log_timestamps=SYSTEM

[root@ydq-mnt ~]# systemctl restart mysql
2017-12-18T07:52:41.543983Z 0 [Note] Beginning of list of non-natively partitioned tables
2017-12-18T07:52:41.544128Z 0 [Note] WSREP: Member 0.0 (ydq-mnt) synced with group.
2017-12-18T07:52:41.544138Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 4163)
2017-12-18T07:52:41.550738Z 8 [Note] WSREP: Synchronized with group, ready for connections
2017-12-18T07:52:41.550755Z 8 [Note] WSREP: This node is synced, setting wsrep_ready to true
2017-12-18T07:52:41.550761Z 8 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2017-12-18T07:52:41.582207Z 0 [Note] End of list of non-natively partitioned tables
2017-12-18T07:52:43.178826Z 0 [Note] InnoDB: Buffer pool(s) load completed at 171218 15:52:43
2017-12-18T16:24:23.588881+08:00 0 [Note] WSREP: Received shutdown signal. Will sleep for 10 secs before initiating shutdown.
pxc_maint_mode switched to SHUTDOWN
2017-12-18T16:24:33.591354+08:00 0 [Note] WSREP: Stop replication
2017-12-18T16:24:33.591408+08:00 0 [Note] WSREP: Closing send monitor...
2017-12-18T16:24:33.591429+08:00 0 [Note] WSREP: Closed send monitor.
2017-12-18T16:24:33.591453+08:00 0 [Note] WSREP: gcomm: terminating thread
2017-12-18T16:24:33.591477+08:00 0 [Note] WSREP: gcomm: joining thread
2017-12-18T16:24:33.591700+08:00 0 [Note] WSREP: gcomm: closing backend
再次启动及验证,时间显示与系统时间一致。
AI 代码解读
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
42
分享
相关文章
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
26 5
图解MySQL【日志】——Redo Log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
101 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
25 4
图解MySQL【日志】——两阶段提交
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
107 22
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
23 3
图解MySQL【日志】——Buffer Pool
Buffer Pool 是数据库管理系统(DBMS)中用于缓存磁盘数据页的内存区域,主要包含数据页、索引页、undo 页等。它通过减少磁盘 I/O 提升性能,特别是在处理大型数据库时效果显著。查询时,整个数据页而非单条记录会被加载到 Buffer Pool 中,以提高访问效率。
17 0
图解MySQL【日志】——Buffer Pool
Mysql、Oracle审计日志的开启
通过上述步骤,可以在 MySQL 和 Oracle 数据库中启用和配置审计日志。这些日志对于监控数据库操作、提高安全性和满足合规性要求非常重要。确保正确配置审计参数和策略,定期查看和分析审计日志,有助于及时发现并处理潜在的安全问题。
72 11
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
106 7
MySQL事务日志-Undo Log工作原理分析
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
25 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等