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_thread_concurrency

[1] http://peter-zaitsev.livejournal.com/9138.html
[2]
http://stackoverflow.com/questions/13195129/mysql-thread-concurrency-innodb-thread-concurrency-should-i-use-or-not
[3]
http://mysqlha.blogspot.de/2010/03/do-we-still-need-innodbthreadconcurrenc.html

[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