Eksport danych MySQL zmienia się w czasie

Mam kilka skryptów tworzenia kopii zapasowych i przywracania, których używam dla mojej bazy danych. Tabela ma pole znacznika czasu. Skrypt zapasowy wygląda tak:Eksport danych MySQL zmienia się w czasie

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

Tworzy dwa pliki: table.sql i table.txt. Skrypt przywracania wygląda następująco:

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

Jednak skrypt kopii zapasowej jest wyprowadzanie zły czas - jest to godzina za to, co jest w bazie danych - ale nie rozwiąże to podczas importowania.

Na przykład czas na jednym rzędzie było 15:10:25 ale gdy skrypt kopii zapasowej jest uruchamiany, 14:10:25 jest wymieniony w table.txt. Po uruchomieniu skryptu przywracania ten sam wiersz ma teraz 14:10:25 jako czas w bazie danych. Jeśli ponownie wykonam kopię zapasową, będzie to oznaczać 13:10:25! I tak dalej ...

Nie mogę zrozumieć, dlaczego tak jest. Strefa czasowa wydaje się być ustawiona na "SYSTEM" (jestem na GMT). Plik table.sql ma kilka linijek, w których wymieniono strefy czasowe, może coś jest nie tak? Oto pełny plik w pytaniu:

/*!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 */;

Źródło

2013-02-15 DisgruntledGoat

znalazł rozwiązanie w końcu: dodanie opcji do skryptu eksportowego --skip-tz-utc.

Dzięki temu po prostu wyeksportowana zostanie dokładna data importu do drugiej bazy danych. Działa to dla mnie, ponieważ bazy danych są w tej samej strefie czasowej, ale mogą nie być idealne dla innych, których bazy danych mają różne strefy czasowe.

Źródło

2013-02-24 17:11:20 DisgruntledGoat

Zakładam, że ponieważ muszę to zrobić, zrobiłem coś złego w aplikacji. Używanie tej opcji wydaje się dokładnie robić * przeciwieństwo * tego, co mówi na stronie podręcznika. Czy to możliwe, że powinienem ustawić strefę czasową MySQL w aplikacji na UTC zamiast przesunięcia? – Mike

Myślę, że powinieneś ustawić strefę czasową na UTC podczas importowania danych, a nie eksportować. Z dokumentacji opcji "--tz-utc": "mysqldump ustawia swoją strefę czasową połączenia na UTC i dodaje SET TIME_ZONE =" + 00:00 "do pliku zrzutu." Tak więc zrzut jest w UTC. Ale ponieważ używasz zrzutów tabulacji, instrukcja "SET TIME_ZONE =" + 00:00 "nie jest wykonywana, więc musisz ustawić strefę czasową połączenia ręcznie. – Yuri

Eksport danych MySQL zmienia się w czasie

Odpowiedz

Powiązane problemy