Изменение данных экспорта данных MySQL

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

mysqldump -u user -ppass database --tab="../" --fields-terminated-by="|" --skip-comments table

Он создает два файла table.sql и table.txt. Восстановить сценарий выглядит следующим образом:

mysql -u user -ppass database < "../table.sql" 
mysqlimport -u user -ppass --local --fields-terminated-by="|" database "../table.txt"

Однако скрипт резервного копирования выводит неправильное время - это час за то, что в базе данных - но не исправляет его при импорте.

Например, время на одной строке был 15:10:25, но когда сценарий резервного копирования запускается, 14:10:25 указана в table.txt. Когда я запускаю сценарий восстановления, в этой же строке теперь есть 14:10:25 как время в базе данных. Если я снова сделаю резервную копию, то будет сказано: 13:10:25! И так далее ...

Я не могу понять, почему это так. Часовой пояс, кажется, установлен на «SYSTEM» (я нахожусь в GMT). В файле table.sql есть несколько строк, указывающих часовые пояса, может быть, что-то там не так? Вот полный файл в вопрос:

/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */; 
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */; 
/*!40101 SET @[email protected]@COLLATION_CONNECTION */; 
/*!40101 SET NAMES utf8 */; 
/*!40103 SET @[email protected]@TIME_ZONE */; 
/*!40103 SET TIME_ZONE='+00:00' */; 
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE='' */; 
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */; 
DROP TABLE IF EXISTS `news_article`; 
/*!40101 SET @saved_cs_client  = @@character_set_client */; 
/*!40101 SET character_set_client = utf8 */; 
CREATE TABLE `news_article` (
    `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT, 
    `title` varchar(100) NOT NULL, 
    `alias` varchar(65) NOT NULL, 
    `author` tinyint(3) unsigned NOT NULL, 
    `category` tinyint(3) unsigned NOT NULL, 
    `posted` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    `opening` text NOT NULL, 
    `content` text NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `alias` (`alias`) 
) ENGINE=MyISAM AUTO_INCREMENT=93 DEFAULT CHARSET=utf8; 
/*!40101 SET character_set_client = @saved_cs_client */; 

/*!40103 SET [email protected]_TIME_ZONE */; 

/*!40101 SET [email protected]_SQL_MODE */; 
/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */; 
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */; 
/*!40101 SET [email protected]_COLLATION_CONNECTION */; 
/*!40111 SET [email protected]_SQL_NOTES */;

источник

2013-02-15 DisgruntledGoat

Найдено решение в конце: добавление --skip-tz-utc опцию экспорта сценария.

Это просто гарантирует, что точная дата, которую вы экспортируете, импортируется во вторую базу данных. Он работает для меня, поскольку базы данных являются одним и тем же часовым поясом, но не могут быть идеальными для других, чьи базы данных являются разными часовыми поясами.

источник

2013-02-24 17:11:20 DisgruntledGoat

Я предполагаю, что, поскольку мне нужно это сделать, я сделал что-то еще неправильно в приложении. Использование этого параметра, похоже, делает именно * противоположное * того, что он говорит на странице руководства. Может быть, я должен был установить часовой пояс MySQL в приложении как UTC вместо смещения? – Mike

Я думаю, вы должны установить часовой пояс для UTC при импорте данных, а не для экспорта. Из документации опции «-tz-utc»: «mysqldump устанавливает часовой пояс своего соединения в UTC и добавляет SET TIME_ZONE = '+ 00:00» в файл дампа ». Итак, дамп находится в UTC. Но так как вы используете дампы табуляции, команда «SET TIME_ZONE = '+ 00:00» не выполняется, поэтому вам нужно установить часовой пояс в соединении вручную. – Yuri

Изменение данных экспорта данных MySQL

ответ

Смежные вопросы