Im vorherigen Artikel wurde erwähnt, dass die in der mysqldump-Sicherungsdatei aufgezeichneten Zeitstempeldaten auf der UTC-Zeitzone basieren. Achten Sie beim Auswählen und Wiederherstellen einer einzelnen Datenbank oder Tabelle auf den Zeitzonenunterschied. Später habe ich das Dokument noch einmal überprüft und festgestellt, dass die Parameter tz-utc und skip-tz-utc damit zusammenhängen. Schauen wir uns in diesem Artikel die Rolle dieser Parameter an. 1. Einführung in die Parameter tz-utc und skip-tz-utc Diese beiden Parameter können im mysqldump-Sicherungsprozess verwendet werden und sind einander entgegengesetzt. Wie die Namen andeuten, dient ein Parameter dazu, den Zeitstempel in die UTC-Zeitzone zu ändern, und der andere dazu, die Zeitzonenänderung zu überspringen. Führen Sie den Befehl mysqldump --help auf dem MySQL-Server aus und Sie sehen den folgenden Absatz. [root@host ~]# mysqldump --help mysqldump Ver 10.13 Distrib 5.7.23, für Linux (x86_64) Copyright (c) 2000, 2018, Oracle und/oder seine Tochtergesellschaften. Alle Rechte vorbehalten. ...viel Inhalt weglassen --tz-utc SET TIME_ZONE='+00:00' am Anfang des Dumps, um das Dumping von TIMESTAMP-Daten, wenn ein Server Daten in unterschiedlichen Zeitzonen hat Zonen oder Daten werden zwischen Servern verschoben mit verschiedene Zeitzonen. (Standardmäßig aktiviert; zum Deaktivieren verwenden Sie --skip-tz-utc.) Der Parameter --tz-utc ist der Standardparameter von mysqldump. Er fügt die Anweisung SET TIME_ZONE='+00:00' hinzu, um die Zeitzone oben in der mysqldump-Exportdatei festzulegen. Diese Zeitzone ist die Greenwich Mean Time, also die Zeitzone 0. Auf diese Weise wird beim Exportieren des Zeitstempelfelds der in der vom Server eingestellten aktuellen Zeitzone angezeigte Zeitstempelwert in die in Greenwich Mean Time angezeigte Zeit umgerechnet. Beispielsweise verwendet unsere Datenbank die Pekinger Zeitzone 8 und der in der von mysqldump exportierten Datei angezeigte Zeitstempelwert liegt 8 Stunden zurück im Vergleich zu der von der Datenbankabfrage angezeigten Zeit. Wenn Sie --tz-utc kennen, bedeutet --skip-tz-utc, dass mysqldump beim Exportieren von Daten nicht die Greenwich Mean Time verwendet, sondern die Zeitzone des aktuellen MySQL-Servers für den Export. Auf diese Weise entspricht der in den exportierten Daten angezeigte Zeitstempelzeitwert dem in der Tabelle abgefragten Zeitwert. 2. Spezifische Effekte experimenteller Parameter Um die Wirkung dieses Parameters besser zu verstehen, führen wir einen spezifischen Test durch. Wir wissen, dass mysqldump mit einer Where-Bedingung verwendet werden kann, um einige Daten zu sichern. Wenn wir einige Daten basierend auf dem Zeitstempelfeld sichern, hat dies Auswirkungen auf die Parameter? Lassen Sie es uns gemeinsam überprüfen: Schauen wir uns zunächst meine Umgebungseinstellungen und Testdaten an: mysql> Version auswählen(); +------------+ | version() | +------------+ | 5.7.23-Protokoll | +------------+ 1 Zeile im Satz (0,00 Sek.) # Die Zeitzone ist Peking-Zeitzone 8 mysql> Variablen wie „time_zone“ anzeigen; +---------------+--------+ | Variablenname | Wert | +---------------+--------+ | Zeitzone | +08:00 | +---------------+--------+ 1 Zeile im Satz (0,00 Sek.) # Die Testtabelle enthält 10 Daten im Datums-/Uhrzeitfeld und im Zeitstempelfeld. Die beiden Zeiten werden gleich angezeigt. mysql> show create table test_tb\G *************************** 1. Reihe *************************** Tabelle: test_tb Tabelle erstellen: CREATE TABLE `test_tb` ( `increment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Primärschlüssel automatisch inkrementieren', `stu_id` int(11) NOT NULL KOMMENTAR 'Studenten-ID', `stu_name` varchar(20) DEFAULT NULL COMMENT 'Studentenname', `dt_time` datetime NICHT NULL, `create_time` Zeitstempel NICHT NULL STANDARD CURRENT_TIMESTAMP KOMMENTAR 'Erstellungszeit', PRIMÄRSCHLÜSSEL (`increment_id`) ) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 COMMENT='Testtabelle' 1 Zeile im Satz (0,00 Sek.) mysql> wähle * aus test_tb; +--------------+--------+----------+---------------------+---------------------+ | increment_id | stu_id | stu_name | dt_time | Erstellungszeit | +--------------+--------+----------+---------------------+---------------------+ | 1 | 1001 | fgds | 10.07.2020 09:43:28 | 10.07.2020 09:43:28 | | 2 | 1002 | fgsw | 10.10.2020 09:43:28 | 10.10.2020 09:43:28 | | 3 | 1003 | vffg | 10.10.2020 02:00:00 | 10.10.2020 02:00:00 | | 4 | 1004 | wdsd | 31.10.2020 23:43:28 | 31.10.2020 23:43:28 | | 5 | 1005 | grdb | 01.11.2020 00:00:00 | 01.11.2020 00:00:00 | | 6 | 1006 | sdfv | 01.11.2020 02:00:00 | 01.11.2020 02:00:00 | | 7 | 1007 | fgfg | 06.11.2020 02:00:00 | 06.11.2020 02:00:00 | | 8 | 1008 | 10. | 10.11.2020 09:43:28 | 10.11.2020 09:43:28 | | 9 | 1009 | ewer | 10.11.2020 09:43:28 | 10.11.2020 09:43:28 | | 10 | 1010 | erre | 11.11.2020 15:17:03 | 11.11.2020 15:17:03 | +--------------+--------+----------+---------------------+---------------------+ Standardmäßig aktiviert mysqldump tz-utc. Schauen wir uns zunächst die standardmäßigen Backup-Ergebnisse an: # Um die Ergebnisse deutlicher zu machen, verwenden wir „skip-extended-insert“, um die Daten zeilenweise anzuzeigen. # Vollständige Datenbanksicherung [root@host ~]# mysqldump -uroot -pxxxx --skip-extended-insert --databases testdb > utc_testdb.sql mysqldump: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein. [root@host ~]# mehr utc_testdb.sql -- MySQL Dump 10.13 Distrib 5.7.23, für Linux (x86_64) -- -- Host: localhost Datenbank: testdb -- ------------------------------------------------------ --Serverversion 5.7.23-log … /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */ auslassen; /*!40103 SETZE ZEITZONE='+00:00' */; # Speichern Sie zuerst die alte Zeitzone und ändern Sie dann die Zeitzone dieser Sitzung auf die Zeitzone 0 ... ausgelassen-- -- Daten für Tabelle „test_tb“ ausgeben -- SPERRT TABELLEN `test_tb` SCHREIBEN; /*!40000 ALTER TABLE `test_tb` SCHLÜSSEL DEAKTIVIEREN */; INSERT INTO `test_tb` VALUES (1,1001,'fgds','2020-07-10 09:43:28','2020-07-10 01:43:28'); INSERT INTO `test_tb` VALUES (2,1002,'fgsw','2020-10-10 09:43:28','2020-10-10 01:43:28'); INSERT INTO `test_tb` VALUES (3,1003,'vffg','2020-10-10 02:00:00','2020-10-09 18:00:00'); INSERT INTO `test_tb` VALUES (4,1004,'wdsd','2020-10-31 23:43:28','2020-10-31 15:43:28'); INSERT INTO `test_tb` VALUES (5,1005,'grdb','2020-11-01 00:00:00','2020-10-31 16:00:00'); INSERT INTO `test_tb` VALUES (6,1006,'sdfv','2020-11-01 02:00:00','2020-10-31 18:00:00'); INSERT INTO `test_tb` VALUES (7,1007,'fgfg','2020-11-06 02:00:00','2020-11-05 18:00:00'); INSERT INTO `test_tb` VALUES (8,1008,'zigster','2020-11-10 09:43:28','2020-11-10 01:43:28'); INSERT INTO `test_tb` VALUES (9,1009,'ewer','2020-11-10 09:43:28','2020-11-10 01:43:28'); INSERT INTO `test_tb` VALUES (10,1010,'erre','2020-11-11 15:17:03','2020-11-11 07:17:03'); # Es ist ersichtlich, dass vom Zeitstempel-Zeitwert 8 Stunden abgezogen werden, während der Datums-/Uhrzeit-Zeitwert unverändert bleibt. UNLOCK TABLES; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; # Ändern Sie die Zeitzone in die ursprüngliche Zeitzone /*!40101 SET SQL_MODE=@OLD_SQL_MODE */; -- Dump abgeschlossen am 11.11.2020 15:34:21 # Verwenden Sie die Where-Bedingung, um Teildaten in einer einzelnen Tabelle zu sichern und Daten seit November zu sichern.# Abfrage in der Datenbankmysql> select * from test_tb where create_time >= '2020-11-01 00:00:00'; +--------------+--------+----------+---------------------+---------------------+ | increment_id | stu_id | stu_name | dt_time | Erstellungszeit | +--------------+--------+----------+---------------------+---------------------+ | 5 | 1005 | grdb | 01.11.2020 00:00:00 | 01.11.2020 00:00:00 | | 6 | 1006 | sdfv | 01.11.2020 02:00:00 | 01.11.2020 02:00:00 | | 7 | 1007 | fgfg | 06.11.2020 02:00:00 | 06.11.2020 02:00:00 | | 8 | 1008 | 10. | 10.11.2020 09:43:28 | 10.11.2020 09:43:28 | | 9 | 1009 | ewer | 10.11.2020 09:43:28 | 10.11.2020 09:43:28 | | 10 | 1010 | erre | 11.11.2020 15:17:03 | 11.11.2020 15:17:03 | +--------------+--------+----------+---------------------+---------------------+ 6 Zeilen im Satz (0,00 Sek.) # mysqldump export [root@host ~]# mysqldump -uroot -pxxxx --skip-extended-insert testdb test_tb --where "create_time >= '2020-11-01 00:00:00' " > utc_testdb2.sql mysqldump: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein. [root@host ~]# mehr utc_testdb2.sql -- MySQL Dump 10.13 Distrib 5.7.23, für Linux (x86_64) -- -- Host: localhost Datenbank: testdb -- ------------------------------------------------------ --Serverversion 5.7.23-log ... /*!40103 SETZEN @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SETZE ZEITZONE='+00:00' */; ...ausgelassen-- -- Daten für Tabelle „test_tb“ ausgeben -- -- WO: create_time >= '2020-11-01 00:00:00' SPERRT TABELLEN `test_tb` SCHREIBEN; /*!40000 ALTER TABLE `test_tb` SCHLÜSSEL DEAKTIVIEREN */; INSERT INTO `test_tb` VALUES (7,1007,'fgfg','2020-11-06 02:00:00','2020-11-05 18:00:00'); INSERT INTO `test_tb` VALUES (8,1008,'zigster','2020-11-10 09:43:28','2020-11-10 01:43:28'); INSERT INTO `test_tb` VALUES (9,1009,'ewer','2020-11-10 09:43:28','2020-11-10 01:43:28'); INSERT INTO `test_tb` VALUES (10,1010,'erre','2020-11-11 15:17:03','2020-11-11 07:17:03'); # Es wurden nur 4 UNLOCK TABLES zum Exportieren gefunden; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; -- Dump abgeschlossen am 11.11.2020 15:58:56 Ich schlage vor, dass Sie sich die oben exportierten Ergebnisse genauer ansehen. Ehrlich gesagt habe ich vorher noch keine detaillierten Tests durchgeführt und bin ein wenig überrascht, die Ergebnisse jetzt zu sehen. Standardmäßig sind die Daten in Ordnung. Obwohl der Zeitstempelwert in die Zeitzone 0 konvertiert wird, wird er beim Importieren der Datenbank weiterhin in der Zeitzone Ihrer Datenbank angezeigt. Beim Exportieren eines Teils der Daten unter Verwendung der Where-Bedingung unterschieden sich jedoch die Ergebnisse der Datenbankabfrage von den Ergebnissen, die durch Dump exportiert wurden. Zu diesem Zeitpunkt exportierte mysqldump nur die Daten, deren Zeitwerte nach der Konvertierung in die Zeitzone 0 die Where-Bedingung erfüllten, was sich von den Ergebnissen unterschied, die durch die direkte Abfrage erhalten wurden. Das war etwas, was mir vorher nicht aufgefallen war. Werfen wir einen Blick auf den Parameter --skip-tz-utc, um zu sehen, ob er unseren Erwartungen entspricht: # Verwenden Sie ein vollständiges Skip-TZ-UTC-Backup [root@host ~]# mysqldump -uroot -pxxxx --skip-extended-insert --skip-tz-utc --databases testdb > skiputc_testdb.sql mysqldump: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein. [root@host ~]# mehr skiputc_testdb.sql -- MySQL Dump 10.13 Distrib 5.7.23, für Linux (x86_64) -- -- Host: localhost Datenbank: testdb -- ------------------------------------------------------ --Serverversion 5.7.23-log ..Ungesehene Aussagen zur Zeitzonenänderung ausgelassen-- -- Daten für Tabelle „test_tb“ ausgeben -- SPERRT TABELLEN `test_tb` SCHREIBEN; /*!40000 ALTER TABLE `test_tb` SCHLÜSSEL DEAKTIVIEREN */; INSERT INTO `test_tb` VALUES (1,1001,'fgds','2020-07-10 09:43:28','2020-07-10 09:43:28'); INSERT INTO `test_tb` VALUES (2,1002,'fgsw','2020-10-10 09:43:28','2020-10-10 09:43:28'); INSERT INTO `test_tb` VALUES (3,1003,'vffg','2020-10-10 02:00:00','2020-10-10 02:00:00'); INSERT INTO `test_tb` VALUES (4,1004,'wdsd','2020-10-31 23:43:28','2020-10-31 23:43:28'); INSERT INTO `test_tb` VALUES (5,1005,'grdb','2020-11-01 00:00:00','2020-11-01 00:00:00'); INSERT INTO `test_tb` VALUES (6,1006,'sdfv','2020-11-01 02:00:00','2020-11-01 02:00:00'); INSERT INTO `test_tb` VALUES (7,1007,'fgfg','2020-11-06 02:00:00','2020-11-06 02:00:00'); INSERT INTO `test_tb` VALUES (8,1008,'zigster','2020-11-10 09:43:28','2020-11-10 09:43:28'); INSERT INTO `test_tb` VALUES (9,1009,'ewer','2020-11-10 09:43:28','2020-11-10 09:43:28'); INSERT INTO `test_tb` VALUES (10,1010,'erre','2020-11-11 15:17:03','2020-11-11 15:17:03'); # Der Zeitstempelwert wird ohne Konvertierung genauso angezeigt wie der Datums-/Uhrzeitwert. UNLOCK TABLES; -- Dump abgeschlossen am 11.11.2020 16:23:32 # Verwenden Sie skip-tz-utc, um einige Daten zu sichern [root@host ~]# mysqldump -uroot -pxxxx --skip-extended-insert --skip-tz-utc testdb test_tb --where "create_time >= '2020-11-01 00:00:00' " > skiputc_testdb2.sql mysqldump: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein. [root@host ~]# mehr skiputc_testdb2.sql -- MySQL Dump 10.13 Distrib 5.7.23, für Linux (x86_64) -- -- Host: localhost Datenbank: testdb -- ------------------------------------------------------ --Serverversion 5.7.23-log .. ausgelassen-- -- Daten für Tabelle „test_tb“ ausgeben -- -- WO: create_time >= '2020-11-01 00:00:00' SPERRT TABELLEN `test_tb` SCHREIBEN; /*!40000 ALTER TABLE `test_tb` SCHLÜSSEL DEAKTIVIEREN */; INSERT INTO `test_tb` VALUES (5,1005,'grdb','2020-11-01 00:00:00','2020-11-01 00:00:00'); INSERT INTO `test_tb` VALUES (6,1006,'sdfv','2020-11-01 02:00:00','2020-11-01 02:00:00'); INSERT INTO `test_tb` VALUES (7,1007,'fgfg','2020-11-06 02:00:00','2020-11-06 02:00:00'); INSERT INTO `test_tb` VALUES (8,1008,'zigster','2020-11-10 09:43:28','2020-11-10 09:43:28'); INSERT INTO `test_tb` VALUES (9,1009,'ewer','2020-11-10 09:43:28','2020-11-10 09:43:28'); INSERT INTO `test_tb` VALUES (10,1010,'erre','2020-11-11 15:17:03','2020-11-11 15:17:03'); # Die 6 Daten stimmen mit der Abfrage in der Datenbank UNLOCK TABLES überein; -- Dump abgeschlossen am 11.11.2020 16:28:39 Aus den obigen Ergebnissen können wir ersehen, dass nach der Verwendung des Parameters --skip-tz-utc der Wert des Zeitstempelfelds nicht konvertiert wird und die exportierten Daten auch den Erwartungen entsprechen. 3. Einige kleine Vorschläge Welche Bedeutung hat dieser Parameter? Wenn sich Ihr Datenbankserver in einer anderen Zeitzone befindet. Angenommen, ein Server steht in Peking (Ostbezirk 8) und der andere in Tokio (Ostbezirk 9). Nun müssen Sie die Daten vom Peking-Server auf den Tokio-Server importieren. Beim Importieren der Dump-Datei ohne den Standardparameter --skip-tz-utc sind die abgefragten Zeitstempel-Zeitdaten eine Stunde länger als der vorherige Zeitwert auf dem East Zone 8-Server. Da jedoch 13:00 auf dem East Zone 8-Server und 14:00 auf dem East Zone 9-Server dieselbe Zeit darstellen, ist die auf dem East Zone 9-Server angezeigte zusätzliche Stunde korrekt. Wenn Sie den Parameter --skip-tz-utc hinzufügen, ist nach dem Importieren der Dump-Datei in den East 9-Server zwar der angezeigte Zeitwert mit dem zuvor vom East 8-Server angezeigten Zeitwert identisch, die dargestellten Zeiten sind jedoch unterschiedlich. In Bezug auf die Verwendung dieses Parameters sollten wir zunächst verstehen, dass das Hinzufügen des Parameters --skip-tz-utc nur den Import und Export des Zeitstempelfelds beeinflusst und nicht das Datums-/Uhrzeitfeld. Hier empfiehlt der Autor, zunächst die Verwendung des Zeitstempelfeldes zu standardisieren. Beispielsweise wird das Zeitstempelfeld nur für die Anforderungen an Erstellungszeit und Aktualisierungszeit verwendet und stellt nur die Erstellungs- und Aktualisierungszeit der Datenzeile dar, sodass es nur schwach mit dem Geschäft in Zusammenhang steht. Versuchen Sie, für andere Zeitfelder datetime zu verwenden. Auch wenn mysqldump andere Parameter verwendet, sind die tatsächlichen Auswirkungen nicht signifikant. Wenn sich Ihr Server in einer anderen Zeitzone befindet, wird empfohlen, die Standardeinstellung beizubehalten, damit die importierten und exportierten Daten korrekt sind. Wenn sich Ihre Server alle in derselben Zeitzone befinden, macht die Verwendung des Parameters --skip-tz-utc kaum einen Unterschied. Wir müssen nur wissen, dass mysqldump Zeitstempelwerte standardmäßig zur Speicherung in die Zeitzone 0 konvertiert. Beim Sichern teilweiser Daten und Filtern nach dem Zeitstempelfeld wird empfohlen, den Parameter --skip-tz-utc hinzuzufügen. Noch ein Hinweis: Achten Sie bei der Auswahl der Sicherungen einer einzelnen Datenbank oder einer einzelnen Tabelle aus der Vollsicherung auch auf die Angaben im Zeitstempelfeld. Oben sind die Details der mysqldump-Parameter aufgeführt, die Sie möglicherweise nicht kennen. Weitere Informationen zu mysqldump-Parametern finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM! Das könnte Sie auch interessieren:
|
<<: So verwenden Sie Portainer zum Erstellen einer visuellen Schnittstelle für Docker
>>: SSM VUE Axios Detaillierte Erklärung
Vor ein paar Tagen habe ich auf Codepen ein Beisp...
Vorwort Standardmäßig initialisiert MySQL einen g...
MySQL ist ein kleines relationales Open-Source-Da...
1. Umwelt VS 2019 16.9.0 Vorschau 1.0 .NET SDK 5....
Dieser Artikel erläutert anhand von Beispielen da...
Inhaltsverzeichnis 1. Initialisierungsstruktur 2....
Einführung Memcached ist ein verteiltes Caching-S...
Sehen Sie sich die 100 höchsten Punktzahlen der S...
In diesem Artikelbeispiel wird der spezifische Ja...
Hallo zusammen, ich bin Tony, ein Lehrer, der nur...
Die Paginierungskomponente ist eine häufige Kompo...
Um Jenkins auf CentOS 8 zu installieren, müssen S...
Inhaltsverzeichnis Vorbereitung Installieren Sie ...
Durch das Umschreiben der URL lässt sich die bevo...
Nginx unterstützt drei Möglichkeiten zum Konfigur...