Есть ли ошибка во всех файлах экспорта mysql с отметкой времени на серверах, отличных от UTC?

Просто пришлось переместить базу данных sql с одного сервера на другой.

Я понимаю, что поле метки времени в MYSQL хранится как 4-байтовое целое число (независимо от часового пояса) и представляется пользователю в нем текущую настройку часового пояса сервера (сервера mysql) Я прав?

Сейчас Когда в октябре в Европе время меняется с летнего на зимнее время (UTC+2 на UTC+1), время накладывается на один час.

Это имеет смысл и не является проблемой, потому что мы «знаем», что сервер знает разницу, потому что он хранит их в отметке времени unix utc.

Я все еще прав?

Теперь, когда я переместил экспорт моей базы данных из одной базы данных в другую, поле метки времени перемещается не как целое число, а как удобочитаемая строка времени:

просто образец:

(1,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 17:38:16',0,NULL,NULL,NULL,NULL,0,NULL),
(2,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 20:00:00',1,NULL,NULL,NULL,NULL,0,NULL),
(3,'AAAA01',6.00,NULL,NULL,NULL,'2017-07-28 21:39:07',0,NULL,NULL,NULL,NULL,0,NULL),
(4,'AAAA01',5.50,NULL,NULL,NULL,'2017-07-28 21:42:15',0,NULL,NULL,NULL,NULL,0,NULL),
(5,'AAAA01',5.00,NULL,NULL,NULL,'2017-07-29 12:55:48',0,NULL,NULL,NULL,NULL,0,NULL),

Вы можете увидеть это поле:

`received` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

но хранится как удобочитаемое поле.

Как принимающий сервер узнает, находится ли это поле до или после изменения времени (в октябре)

Перевод времени происходит 2 раза в год. Весной он идет вперед на один час, так что путаницы нет, так как разница всего в один час, а осенью он идет назад и «перезаписывает» тот же час.

Преобразование часового пояса

Как сервер Mysql вообще может дать ответ на этот раз, поскольку он представляет собой 2 разных времени:

SELECT CONVERT_TZ('2018-10-28 02:40', 'Европа/Париж', 'UTC')


mysql javascript amazon-aurora timezone
person Vincent Duprez    schedule 12.01.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Часовой пояс сервера MySQL — это только часовой пояс по умолчанию, используемый для этих преобразований. Его можно переопределить для каждого соединения. Вот что происходит здесь, чтобы заставить эту работу работать.

Когда mysqldump запрашивает у сервера данные для записи в файл резервной копии, он начинает с отправки этого:

SET TIME_ZONE='+00:00';

Это устанавливает часовой пояс сеанса (соединения) для соединения mysqldump в формате UTC, что приводит к тому, что эти столбцы TIMESTAMP отправляются сервером в формате UTC и записываются таким образом в файл резервной копии.

В верхней части файла дампа он также добавляет следующее:

/*!40103 SET TIME_ZONE='+00:00' */;

/*! ... */ на самом деле не является комментарием, хотя и выглядит как один. !40103 сигнализирует любому серверу MySQL версии 4.01.03 или более поздней версии о выполнении встроенного оператора в обычном режиме - таким образом, устанавливая часовой пояс сеанса в соединении, где восстанавливается дамп, также в формате UTC, чтобы эти метки времени как строки сохранялись. правильно.

Столбцы DATETIME не выполняют эти преобразования -- только TIMESTAMP... но для столбцов TIMESTAMP на новом сервере не должно быть неправильных значений. Значения в файле дампа - это UTC, который также является часовым поясом собственного формата внутреннего хранилища (вообще технически не агностичен).

Также обратите внимание, что больше не считается лучшей практикой устанавливать для сервера часовой пояс, отличный от UTC. Местное время — это проблема представления, с которой лучше всего справляется приложение, а не база данных. В UTC нет двусмысленностей, как в местных часовых поясах, таких как отсутствующий час весной и повторяющийся час осенью, встречающиеся во многих местных часовых поясах.

person Michael - sqlbot    schedule 13.01.2019