RDS MySQL参数time_zone最佳实践-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

RDS MySQL参数time_zone最佳实践

简介: RDS MySQL中,参数time_zone是指实例的当前时区,初始值是'SYSTEM'。本文介绍了在阿里云RDS MySQL中该值的设置的最佳实践

关于time_zone

当前时区。此变量用于初始化连接的每个客户端的时区。默认情况下,它的初始值是'SYSTEM'(这意味着,"使用system_time_zone的值",即MySQL的时区和操作系统的时区相同)。例:

# date
Sat Sep 18 11:21:56 CST 2021
mysql> show global variables like "%time_zone%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2021-09-18 11:22:04 |
+---------------------+


阿里云RDS MySQL的time_zone

目前RDS MySQL的只读实例单独申请,规格和参数和主实例的可以不一样,如time_zone,也可以根据自己的需求改成对应的时区。

时区不同写入数据一致

对于写语句(DML&&DDL),阿里云RDS MySQL从主实例写入且binlog_format是row模式,所以写入的数据不会不一致。但如果是线下自建的MySQL binlog_format可以是statement或mix,可能会造成主从数据不一致。

例(以下操作在RDS MySQL上执行):

CREATE TABLE `test_t1` (
  `id` int DEFAULT NULL,
  `tt` DATETIME  DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
INSERT INTO test_t1 values(1,"2021-09-17 15:16:00");


主实例上:

Table

Checksum

ll_test00.test_t1

1279576785

只读实例上:

Table

Checksum

ll_test00.test_t1

1279576785

然后执行:

INSERT INTO test_t1 values(10000,now());

主实例上:

Table

Checksum

ll_test00.test_t1

4230977686

只读实例上:

Table

Checksum

ll_test00.test_t1

4230977686

checksum一致说明只读和主写入的数据是一致的。

时区不同查询结果可能不同

当主实例和只读实例的default_time_zone参数设置不一样时,如果有涉及到下列语句时会导致取到的结果不一致,所以最保险起见是把只读实例和主实例的参数设置一致,也有个别用户根据业务需要专门设置不一致,具体还需要根据实际业务需求决定

select now();
select from_unixtime(秒数);
select unix_timestamp();
select current_timestamp, current_timestamp();
select date_add(now(), interval n day); 
以下没问题:
select date_format('2018-08-12 02:13:01', '%Y%m%d%H%i%s');
select sec_to_time(1801);
select date_sub('2008-02-01 12:00:00', interval '2 3:3:4' day_second);
select timestampadd(hour, -6, '2018-12-08 23:03:00');

例1:

mysql>select now();

主实例:

now()

2021-09-17 15:55:56

只读实例和主实例2个小时的时差:

now()

2021-09-17 13:56:01

例2:

mysql>SELECT * FROM test_t1;

在主实例和只读实例上的结果一致:

id

tt

1

2021-09-17 15:16:00

10000

2021-09-17 15:22:57

再在主实例和只读实例分别执行:

mysql> SELECT * FROM test_t1 where tt >= date_add(now(), interval 1 hour);

主实例的结果:

image

只读实例的结果:

image

扩展

MySQL官网上提到“If set to SYSTEM, every MySQL function call that requires a time zone calculation makes a system library call to determine the current system time zone. This call may be protected by a global mutex, resulting in contention.” 这会导致CPU高。可以参考看具体的内核信息:MySQL数据库SYS CPU高的可能性分析 http://mysql.taobao.org/monthly/2015/05/02/

例:

mysql > CREATE TABLE `test_tz` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `cc` bigint(20) DEFAULT NULL,
  `kk` varchar(128) DEFAULT NULL,
  `pad` varchar(64) DEFAULT NULL,
  `at` timestamp NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

造数据
# mysqlslap --host=127.0.0.1 --password=3306 --user=*** --password=***  --query="insert into mysqlslap.test_tz(cc,kk,pad,at) values(connection_id(),'31451373586-15688153734-79729593694-96509299839-83724898275-86711833539-78981337422-35049690573-51724173961-87474696253','98996621624-36689827414-04092488557-09587706818-65008859162',now());" --concurrency=20 --no-drop --iterations=100000

压测
# mysqlslap --host=127.0.0.1 --password=3306 --user=*** --password=***  --query="select count(*) from mysqlslap.test_tz where at>='2021-09-17 17:48:00' and at<='2021-09-17 17:56:00'" --concurrency=32,64,128,256,512 --no-drop --iterations=100


image

image

经压测发现,当time_zone=SYSTEM时,sys_cpu占比10%左右;default_time_zone=+08:00时,sys_cpu基本不变。所以建议客户不要使用time_zone=SYSTEM。

参考

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_time_zone







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

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
最新文章
相关文章
链接