-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, Operation erfolgreich! 01:10 Systeme abgeschaltet und MySQL-Dump angestossen 01:45 mit dem Import der Daten auf dem neuen System angefangen 05:55 Import durch 06:00 DB01 produktiv genommen 06:10 Systeme wieder angestellt ... Todes-MTU gesetzt 07:00 Mitteilung von Omid das alles schick ist Danke Sören! Tilo - -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIbBAEBAgAGBQJS4LGgAAoJEFfjOJdKpi1EQBUP9iTAMik00tDX4s0IeywoWCVz xbSmAk7/GfUWUp+mmthyGubUGJ/PnFaZXF3V0rGwHyim7oJeVPHpPHZJn1xaiJC4 H1Dc82fgXvBvJ5Mkp5RSIhqhOJB4wERDT31ckHGe8aiwqU0tt1jxvluFBXJlFJTa Ho+ph8XrSG15RsZzR6OcVf3LdqLqDY+NG7klhYo+2MfehQmIWyq1/19g8ggefPsk ZJUXCgEBARkAeb/+20m2rGB9x/lyZltEEYgq5oterP3UVNty1rj14wmJnzRFumR0 IIW8oX44oh22pBPRP+QjynakfibFH8ZlVR2FmbERUh7o/RK4VAH1UogWzPNlyqX9 d78WGiGUK9+h3oseKpKjYQWCX/vDYJL84gmSUGRwwngSdbL41IRuwnIwNiRffkuV mHK4+WgwrcXFTYsUNKtDnsMS+d86PLVnD2ZjnrvP3S/AIRyM3yE17wjZ2anzZozj FvA6cBZisJQLs+jMFh2D31G4t1sR1hXcQRqKhuVJDFwe4z2fTmQW4PhEexZYbcHG rY/ATC6yJlafuvG+yWZAnNZptSdNtbZAXB1KZn3rPuwlo58YnvC1UhTntUZrwAG/ yJRKzV9XLa4oaOaJVT46wEpDcNwWlq5zc3eNzV4BHiwzWNNUFddomoCMqcuaf7no kveGYgKIfSglpzGdkVE= =ph87 -----END PGP SIGNATURE-----
Hallo Tilo und Sören, danke. An alle, jetzt haben wir das geplante Setup. - Aufrüstung des Data01 vor allem um CPU und RAM - Aufrüstung des DB01 um RAM, schnellere Festplatte (SSD) und Percona Wir hatten in den letzten beiden Wochen die Kapazität des Data01 noch nicht stärker ausgelastet, um die DB01 nicht zu stark zu belasten. Der Zeitraum So. bis Di hat gezeigt, dass der alte DB01 nicht ausgereicht hat. Jetzt sollten wir bis zum Wochenende mal abwarten. Ab Montag können wir dann den Data01 schrittweise stärker auslasten und dabei den DB01 beobachten. Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----Ursprüngliche Nachricht----- Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Tilo Werner Gesendet: Donnerstag, 23. Januar 2014 07:07 An: team@lists.traso.de Betreff: [Team] DB-Umstellung JT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, Operation erfolgreich! 01:10 Systeme abgeschaltet und MySQL-Dump angestossen 01:45 mit dem Import der Daten auf dem neuen System angefangen 05:55 Import durch 06:00 DB01 produktiv genommen 06:10 Systeme wieder angestellt ... Todes-MTU gesetzt 07:00 Mitteilung von Omid das alles schick ist Danke Sören! Tilo - -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIbBAEBAgAGBQJS4LGgAAoJEFfjOJdKpi1EQBUP9iTAMik00tDX4s0IeywoWCVz xbSmAk7/GfUWUp+mmthyGubUGJ/PnFaZXF3V0rGwHyim7oJeVPHpPHZJn1xaiJC4 H1Dc82fgXvBvJ5Mkp5RSIhqhOJB4wERDT31ckHGe8aiwqU0tt1jxvluFBXJlFJTa Ho+ph8XrSG15RsZzR6OcVf3LdqLqDY+NG7klhYo+2MfehQmIWyq1/19g8ggefPsk ZJUXCgEBARkAeb/+20m2rGB9x/lyZltEEYgq5oterP3UVNty1rj14wmJnzRFumR0 IIW8oX44oh22pBPRP+QjynakfibFH8ZlVR2FmbERUh7o/RK4VAH1UogWzPNlyqX9 d78WGiGUK9+h3oseKpKjYQWCX/vDYJL84gmSUGRwwngSdbL41IRuwnIwNiRffkuV mHK4+WgwrcXFTYsUNKtDnsMS+d86PLVnD2ZjnrvP3S/AIRyM3yE17wjZ2anzZozj FvA6cBZisJQLs+jMFh2D31G4t1sR1hXcQRqKhuVJDFwe4z2fTmQW4PhEexZYbcHG rY/ATC6yJlafuvG+yWZAnNZptSdNtbZAXB1KZn3rPuwlo58YnvC1UhTntUZrwAG/ yJRKzV9XLa4oaOaJVT46wEpDcNwWlq5zc3eNzV4BHiwzWNNUFddomoCMqcuaf7no kveGYgKIfSglpzGdkVE= =ph87 -----END PGP SIGNATURE----- _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
Hallo, ich sollte das doch noch einmal reporten: Auf allen Systemen ausser HOCL befindet sich ein altes UNIQ_Constraint, welches die Verwendung von Multi-Source-Market verhindern kann. Dieses sollte lt Marcel beim Deployment evtl entfernt werden. UNIQUE INDEX `provider_hotel_code_externaö_code` (`provider`, `hotel_code`, `external_code`), UNIQUE INDEX `provider_2` (`provider`, `hotel_code`, `external_code`, `source_market_id`), Auswirkungen: neue Hotels können nicht in die Stammdaten eingetragen werden (zB import_MTS_HotelPortfolio.php) PROOF OF CONCEPT: INSERT INTO hotel_matching(hotel_code,provider,source_market_id) VALUES('BELIEBIGESHOTEL','MTS',1); INSERT INTO hotel_matching(hotel_code,provider,source_market_id) VALUES('BELIEBIGESHOTEL','MTS',2); INSERT INTO hotel_matching(hotel_code,provider,source_market_id) VALUES('BELIEBIGESHOTEL','MTS',3); MFG Martin -- Mit freundlichen Grüßen Martin Althuizes - Entwickler - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 513 / Fax: +49 341 909 87 49 E-Mail: m.althuizes@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Kollegen, so ganz rund ist es nun nicht gelaufen... Insgesamt hatten wir drei grundsätzliche Probleme, die mir bekannt sind. 1. MTU Im RZ unterhalten sich alle Server mit der Standard MTU von 1500, einige sogar mit 9000 (Jumbo-Frames - u.a. HBD-Import). Um eine stabile Verbindung in die Firma (u.a. für die Chef-Orchestrierung) herzustellen benutzte ich eine Größe von 1408 (ist im übrigen auch die, die alle Clients in der Firma bekommen). Hintergrund ist das OpenBSD-VPN zwischen gs und rz1, welches Pakete mit einer MTU von 1500 fragmentiert. Die MTU 1408 führte nun aber dazu, dass Pakete von Rechnern welche sich mit dem DB-Server unterhalten wollen stark fragmentiert und somit verworfen wurden. Das habe ich gegen 07:00 Uhr korrigiert. Kurz: Entweder funktioniert das Eine oder das Andere. 2. innodb_thread_concurrency (/etc/mysql/my.cnf) Begrenzt die Anzahl an konkurrierenden Threads der Inno-DB-Engine. Ich hatte hier im Zuge der Optimierung des Imports u.a. einen empfohlenen Wert [0] von 12 eingestellt. Wie sich später herausstellte (gegen 16:00 Uhr) ist das wohl das Problem gewesen weshalb Anfragen warten mussten. Der Wert ist so zu klein. Das Auflaufen von Threads hat denke ich damit zu tun, dass die "neuen" warten mussten um nicht zu Konkurrenten zu werden. Ich habe nun den default (0) eingestellt, welcher eine unbegrenzte Anzahl von konkurrierenden Threads zulässt. Wie ich durch späteres Untersuchen herausfand, ist diese Option nicht unumstritten. [1]-[3] 3. binlog_format (/etc/myslq/my.cnf) Seit MySQL 5.1 ist der default STATEMENT den ich im neuen Server nicht veränderte. Das MySQL Error Log war aber voll mit Warnings [4] (Sören kann dazu mehr sagen). So dass wir kurzerhand den MIXED-Mode auf dem Master als auch auf dem Slave eingestellt haben. Bis morgen, Tilo [0] https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb... [1] http://peter-zaitsev.livejournal.com/9138.html [2] http://stackoverflow.com/questions/13195129/mysql-thread-concurrency-innodb-... [3] http://mysqlha.blogspot.de/2010/03/do-we-still-need-innodbthreadconcurrenc.h... [4] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it invokes a trigger or a stored function that inserts into an AUTO_INCREMENT column. Inserted values cannot be logged correctly. Am 23.01.2014 07:07, schrieb Tilo Werner:
Hallo,
Operation erfolgreich!
01:10 Systeme abgeschaltet und MySQL-Dump angestossen 01:45 mit dem Import der Daten auf dem neuen System angefangen 05:55 Import durch 06:00 DB01 produktiv genommen 06:10 Systeme wieder angestellt ... Todes-MTU gesetzt 07:00 Mitteilung von Omid das alles schick ist
Danke Sören!
Tilo
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
- -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJS4UrQAAoJEFfjOJdKpi1ETLkQAIhSBYThfzlAVnElJnY3WfY6 fxLNjjyFKp6tR0mamglocnrVKBWLMTUh2wfAFiCcP9IxjFJfIVQmdST5goDq1Y7u d4D5Am/eDNAJQlMUHjt+qMs0E98IFRa3MIbYkkZ7g5vD4ZxpXi6YpqNLc4k6p/Ag zMdDL1SQhILbMLvwvomgLeI0Y8N3GCaxH5AFYb3GgDjPh9IjG4IxvDs+n70aC3CI DYUGXg6ocVe1jr/bMaVINCYvUwY1CreUOMMw06WjC47xh74n7ceqNsaznucT5Q0n 12A98AZobrJx5BCnr3r1VLmu1mF3GeMIfdoS0tq+HMf8+OI/MUK7jlP7uApf+qKz c5OEtjA+IS93Ch+LluXvyRWqEuqZ/VbmH40PR6l6pTfQG13xia/lcS/xTHVID09P A/vnCOM/UCc40zTvu1TI9tMkorBNaLxgTTEl3ppazGi+a/FVlOTwiktEbh8V1aBd 8+zky3huuoyAEpxCxQOD0rim/KrkLI7u896miR9y6E0hVnvi/PlX/wRSWlmANcUM vlEdPCmga1SIfehWEgjxA6+HBbYl0QwZUtxcC5THLMAO5BpYe8QpVAxhNgtdDcOQ H4eIP2Dwi7EOQgWMZ8yJ/78k7Fp/bkW2iK+rZuzyBe0W/6ZjoT81v2U1iGhtIw2E 20hzF/auGufDvcV1ujvn =yYdm -----END PGP SIGNATURE-----
Hallöchen, und es läuft weiter nicht rund. Der db01. von JT hat einen Load von 6 oder mehr (bei 6 Kernen), ist zu 50 % mit sich selbst beschäftigt, läuft zumindest nicht schneller als die olle db und swappt zur Zeit 2 Giga (von 8). Der Mem ist auch voll. Prozesse sind ok und das mytop sagt nix ungewöhnliches, aber load und swap sind bedenklich. Die Kiste sieht nicht so aus, als ob sie das Wochenende überlebt. Vermutlich nicht mal heute. René Am 23.01.2014 18:01, schrieb Tilo Werner:
Hallo Kollegen,
so ganz rund ist es nun nicht gelaufen...
Insgesamt hatten wir drei grundsätzliche Probleme, die mir bekannt sind.
1. MTU
Im RZ unterhalten sich alle Server mit der Standard MTU von 1500, einige sogar mit 9000 (Jumbo-Frames - u.a. HBD-Import). Um eine stabile Verbindung in die Firma (u.a. für die Chef-Orchestrierung) herzustellen benutzte ich eine Größe von 1408 (ist im übrigen auch die, die alle Clients in der Firma bekommen). Hintergrund ist das OpenBSD-VPN zwischen gs und rz1, welches Pakete mit einer MTU von 1500 fragmentiert. Die MTU 1408 führte nun aber dazu, dass Pakete von Rechnern welche sich mit dem DB-Server unterhalten wollen stark fragmentiert und somit verworfen wurden. Das habe ich gegen 07:00 Uhr korrigiert. Kurz: Entweder funktioniert das Eine oder das Andere.
2. innodb_thread_concurrency (/etc/mysql/my.cnf)
Begrenzt die Anzahl an konkurrierenden Threads der Inno-DB-Engine. Ich hatte hier im Zuge der Optimierung des Imports u.a. einen empfohlenen Wert [0] von 12 eingestellt. Wie sich später herausstellte (gegen 16:00 Uhr) ist das wohl das Problem gewesen weshalb Anfragen warten mussten. Der Wert ist so zu klein. Das Auflaufen von Threads hat denke ich damit zu tun, dass die "neuen" warten mussten um nicht zu Konkurrenten zu werden. Ich habe nun den default (0) eingestellt, welcher eine unbegrenzte Anzahl von konkurrierenden Threads zulässt.
Wie ich durch späteres Untersuchen herausfand, ist diese Option nicht unumstritten. [1]-[3]
3. binlog_format (/etc/myslq/my.cnf)
Seit MySQL 5.1 ist der default STATEMENT den ich im neuen Server nicht veränderte. Das MySQL Error Log war aber voll mit Warnings [4] (Sören kann dazu mehr sagen). So dass wir kurzerhand den MIXED-Mode auf dem Master als auch auf dem Slave eingestellt haben.
Bis morgen, Tilo
[0] https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb...
[1] http://peter-zaitsev.livejournal.com/9138.html [2] http://stackoverflow.com/questions/13195129/mysql-thread-concurrency-innodb-... [3] http://mysqlha.blogspot.de/2010/03/do-we-still-need-innodbthreadconcurrenc.h...
[4] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it invokes a trigger or a stored function that inserts into an AUTO_INCREMENT column. Inserted values cannot be logged correctly.
Am 23.01.2014 07:07, schrieb Tilo Werner:
Hallo,
Operation erfolgreich!
01:10 Systeme abgeschaltet und MySQL-Dump angestossen 01:45 mit dem Import der Daten auf dem neuen System angefangen 05:55 Import durch 06:00 DB01 produktiv genommen 06:10 Systeme wieder angestellt ... Todes-MTU gesetzt 07:00 Mitteilung von Omid das alles schick ist
Danke Sören!
Tilo
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-- René Lange - Entwicklung - TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 90 98 7 507 // Fax: +49 341 90 98 749 Internet: http://traso.de E-Mail: r.lange@traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850
Hallo Zusammen, bei den Flugimporten habe ich weiterhin Abbrüche mit der Meldung 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away'. Die Performance ist leider auch nicht besser als vor dem Umzug, wenn nicht sogar etwas langsamer. Also vom Gefühl her läuft das System noch nicht optimal. -- Viele liebe Grüße Stefan Wieden - Development ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 745 // Fax: +49 341 90 98 749 Internet: http://traso.de E-Mail: s.wieden@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 Am 24.01.2014 10:15, schrieb Rene Lange:
Hallöchen,
und es läuft weiter nicht rund. Der db01. von JT hat einen Load von 6 oder mehr (bei 6 Kernen), ist zu 50 % mit sich selbst beschäftigt, läuft zumindest nicht schneller als die olle db und swappt zur Zeit 2 Giga (von 8). Der Mem ist auch voll. Prozesse sind ok und das mytop sagt nix ungewöhnliches, aber load und swap sind bedenklich.
Die Kiste sieht nicht so aus, als ob sie das Wochenende überlebt. Vermutlich nicht mal heute.
René
Am 23.01.2014 18:01, schrieb Tilo Werner:
Hallo Kollegen,
so ganz rund ist es nun nicht gelaufen...
Insgesamt hatten wir drei grundsätzliche Probleme, die mir bekannt sind.
1. MTU
Im RZ unterhalten sich alle Server mit der Standard MTU von 1500, einige sogar mit 9000 (Jumbo-Frames - u.a. HBD-Import). Um eine stabile Verbindung in die Firma (u.a. für die Chef-Orchestrierung) herzustellen benutzte ich eine Größe von 1408 (ist im übrigen auch die, die alle Clients in der Firma bekommen). Hintergrund ist das OpenBSD-VPN zwischen gs und rz1, welches Pakete mit einer MTU von 1500 fragmentiert. Die MTU 1408 führte nun aber dazu, dass Pakete von Rechnern welche sich mit dem DB-Server unterhalten wollen stark fragmentiert und somit verworfen wurden. Das habe ich gegen 07:00 Uhr korrigiert. Kurz: Entweder funktioniert das Eine oder das Andere.
2. innodb_thread_concurrency (/etc/mysql/my.cnf)
Begrenzt die Anzahl an konkurrierenden Threads der Inno-DB-Engine. Ich hatte hier im Zuge der Optimierung des Imports u.a. einen empfohlenen Wert [0] von 12 eingestellt. Wie sich später herausstellte (gegen 16:00 Uhr) ist das wohl das Problem gewesen weshalb Anfragen warten mussten. Der Wert ist so zu klein. Das Auflaufen von Threads hat denke ich damit zu tun, dass die "neuen" warten mussten um nicht zu Konkurrenten zu werden. Ich habe nun den default (0) eingestellt, welcher eine unbegrenzte Anzahl von konkurrierenden Threads zulässt.
Wie ich durch späteres Untersuchen herausfand, ist diese Option nicht unumstritten. [1]-[3]
3. binlog_format (/etc/myslq/my.cnf)
Seit MySQL 5.1 ist der default STATEMENT den ich im neuen Server nicht veränderte. Das MySQL Error Log war aber voll mit Warnings [4] (Sören kann dazu mehr sagen). So dass wir kurzerhand den MIXED-Mode auf dem Master als auch auf dem Slave eingestellt haben.
Bis morgen, Tilo
[0] https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb...
[1] http://peter-zaitsev.livejournal.com/9138.html [2] http://stackoverflow.com/questions/13195129/mysql-thread-concurrency-innodb-... [3] http://mysqlha.blogspot.de/2010/03/do-we-still-need-innodbthreadconcurrenc.h...
[4] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it invokes a trigger or a stored function that inserts into an AUTO_INCREMENT column. Inserted values cannot be logged correctly.
Am 23.01.2014 07:07, schrieb Tilo Werner:
Hallo,
Operation erfolgreich!
01:10 Systeme abgeschaltet und MySQL-Dump angestossen 01:45 mit dem Import der Daten auf dem neuen System angefangen 05:55 Import durch 06:00 DB01 produktiv genommen 06:10 Systeme wieder angestellt ... Todes-MTU gesetzt 07:00 Mitteilung von Omid das alles schick ist
Danke Sören!
Tilo
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-- René Lange - Entwicklung -
TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig
Tel.: +49 341 90 98 7 507 // Fax: +49 341 90 98 749
Internet: http://traso.de E-Mail: r.lange@traso.de
Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
participants (5)
-
Haiko Gerdes -
Martin Althuizes -
Rene Lange -
Stefan Wieden -
Tilo Werner