Die wunderbare Welt von Isotopp

Dude, where is my memory?

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - November 12, 2012

“Kris, bitte schau Dir mal unsere Datenbank an. Wir haben hier einen Generator für unsere Materialized Views, und auf einer Datenbank von 6 GB Größe werden 40 GB Speicher gefüllt und wir kommen sogar ins Swappen.”

Na, das ist mal interessant. The fragliche Kiste hat 48 GB RAM, und in der Tat kaum 6 GB Daten.

mysql> select 
 -> sum(data_length+index_length)/1024/1024/1024 as gb 
 -> from tables 
 -> where table_schema not in ('information_schema', 'performance_schema', 'mysql');
+----------------+
| gb             |
+----------------+
| 5.832778930664 |
+----------------+
1 row in set (0.00 sec)

Aber in “top” sieht das so aus, und wächst:

Enemy Action

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - October 31, 2012

“Kris, guck mal, connection surge auf $WICHTIGER_MASTER, davor kurzer Activity drop. Alle anderen Graphen sehen normal aus.”

![Graph: Connection Surge]({{ site.baseurl }}/uploads/screenshot-kris-20121031-1.png)

und

![Graph: QPS Drop]({{ site.baseurl }}/uploads/screenshot-kris-20121031-2.png)

Ich gucke.

Alle anderen Graphen sehen in der Tat normal aus. Aber um 13:20 kommt für kurze Zeit alles Processing zum Stillstand.

Wir haben ja log_processlist.pl. Falls es sich also um irgendein wildgewordenes Lock handeln sollte, würde ich das also in den 13_20 und 13_21 Dateien sehen. Beide sind in der Tat größer: Statt 250 Connections zeichnen wir deutlich über 400 Connections in diesen beiden Minuten auf.

.mylogin.cnf Passworte wiederherstellen

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - October 3, 2012

Wie Todd Farmer in Understanding mysql_config_editor’s security aspects richtig beobachtet, speichert die neue .mylogin.cnf, die von mysql_config_editor erzeugt wird, Paßworte nicht sicher ab. Sie verschleiert sie nur.

Das Format der Datei ist wie folgt (am Beispiel von MySQL 5.6.7-RC):

  • 4 Bytes Zero (Version Information)
  • 20 Bytes Key Generation Matter
  • Wiederholend:
    • 4 Bytes Länge
    • Länge Bytes Ciphertext. Die Verschlüsselung erfolgt mit AES Encrypt , und diese Funktion ist selbst auch nicht sicher: Es handelt sich um einen aes-128-ecb mit einem NULL IV.

Der Schlüssel, der in AES 128 rein geht, muß BINARY(16) sein, aber die Funktion nimmt Strings beliebiger Länge. Sie erzeugt den tatsächlich verwendeten Key, indem sie den mitgegebenen String zyklisch in einen BINARY(16) Puffer rein XOR’t, der mit Nullbytes initialisiert worden ist.

MySQL 5.6.7-RC: GTID vs. MyISAM

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - October 2, 2012

So we tested the 5.6.7-RC. And ran into a strange problem:

Because of a test, a preexisting configuration with GTID enabled existed, and suddenly we did not have properly initialized grants in mysql.* created for a new installation. Turns out: GTID and non-transactional tables are no friends, and that is even documented .

When using GTIDs, updates to tables using nontransactional storage engines such as MyISAM are not supported. This is because updates to such tables mixed with updates to tables that use a transactional storage engine such as InnoDB can result in multiple GTIDs being assigned to the same transaction.

MySQL Replication Load Monitor

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 28, 2012

Mein Kollege Dennis Kaarsemaker hat jetzt einen Artikel zu dem Replication Load Monitor von Booking.com gebloggt. Der Monitor basiert auf Arbeiten von Mark Leith .

Möge er Euch allen nützen.

House und Heisenberg revisited

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 25, 2012

Ich habe heute an dem Problem weiter geforscht und wir haben etabliert, dass die Ursache nicht der Quelltext des betreffenden Diamond-Collectors sein kann.

Auf allen betroffenen Kisten habe ich dann gesehen, das die entsprechenden Queries gegen Performance-Schema ein

mysql> select * from performance_schema.threads;
Empty set (0.01 sec)

zurück liefern.

Weitere Untersuchung stellt heraus: P_S ist aber an. Jedoch:

mysql> select * from performance_schema.setup_instruments;
Empty set (0.03 sec)
 
mysql> select * from performance_schema.setup_timers;
Empty set (0.01 sec)
 
mysql> select * from performance_schema.setup_consumers;
Empty set (0.02 sec)

und das bleibt auch so, sogar über Server-Restarts hinweg.
Warum ist das so?

Der Herr House und der Herr Heisenberg haben Replication Delay

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 24, 2012

Heute erreicht mich eine Mail, in der ein DBA sich über steigende Replication Delay in einer bestimmten Replikationshierarchie beschwert.

Das ist schlecht, denn die betreffende Hierarchie ist wichtig. Also die ‘Wenn die nicht geht schlafen Leute unter Brücken’-Art von wichtig.

Die Theorie war, dass die Änderungsrate in dieser Hierarchie so hoch ist, dass die Schreiblast von MySQL Replikation, die ja Single Threaded ist, nicht mehr bewältigt werden kann. Für diese Theorie sprach nach dem ersten Augenschein, dass alle betroffenen Kisten keine lokalen Platten hatten, sondern auf einem Filer lagen, und Filer sterben wegen der hohen Kommunikationslatenz im SAN bei uns in der Regel weit vor lokalen Platten, wenn es um Replikation geht: Filer sind mehr so beim parallelen Schreiben mit mehreren Threads gut.

Zu Besuch bei Redis

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 23, 2012

Hier ist eine wichtige Zahl: Ein Coredump von einem MySQL auf einer Maschine mit knapp unter 200 GB Speicher dauert 15 Minuten. Auf SSD. Auf eine Festplatte dauert der gleiche Coredump dann knapp über 30 Minuten.

Warum ist das eine wichtige Zahl?

SSD sind schnell. Linear schreiben sie mehr als 200 MB pro Sekunde weg - ein ziemlich beeindruckendes Tempo, und noch dazu in einer Disziplin, wo sie nicht einmal optimal nutzbar sind. Auch moderne Serverfestplatten sind schnell - beim linearen Schreiben immerhin knapp halb so schnell wie eine SSD, oder 100 MB pro Spindel linear.

Fertig gelesen: Alex Benedict

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 4, 2012

A Talent for War , Jack McDevitt, USD 7.99 (Audiobook von Audible verfügbar)

McDevitt: A Talent for War

Jack McDevitt’s Alex Benedict lebt von uns aus gesehen etwa 10.000 Jahre in der Zukunft, auf irgendeiner Welt, die von den Menschen besiedelt worden ist. Aber da sich die Zivilisation in McDevitts Universum in Kreisen bewegt, sind seine Denkweisen und seine Profession uns wesentlich näher: Er handelt mit Antiquitäten, Artefakten aus Kriegen, die Menschen irgendwann einmal zwischen den Sternen geführt haben, Plaketten und Bordbücher bekannter Entdeckerschiffe und andere Dinge, die durch Mut, Neugier oder Entdeckergeist und die mit ihnen verknüpften Geschichten zu Symbolen mit Bedeutung für andere geworden sind.

Fertig gelesen: Ancient Shores

Avatar of @isotopp@infosec.exchange Kristian Köhntopp - September 3, 2012

Ancient Shores , Jack McDevitt, USD 7.99

McDevitt: Ancient Shores

Irgendwo in North Dakota, mitten in der Prärie, gräbt ein Farmer ein Schiff aus, das aus einem Material ist, das unmöglich auf der Erde hergestellt worden sein kann. Es stellt sich heraus, daß vor 10.000 Jahren, kurz nach der Eiszeit, die Prärie der Boden eines großen Süßwasser-Sees war, und bei der Suche nach einem logischen Hafen findet man ein Roundhouse mit einem Stargate - auf altem Indianerland.