-----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-----