Category Archives: Operations

MySQL DBA Tools

Als MySQL Datenbankadministrator ist man täglich damit beschäftigt, unzählige Datenbank-Server am Laufen zu halten. Hier eine Auswahl an Werkzeugen, die man unbedingt in der täglichen Arbeit braucht:

Aus Maatkit eignet sich mk-query-digest besonders gut, um ein System nach einem Neustart der Datenbank “aufzuwärmen”.

mk-query-digest --processlist h=d-mm-05-1-svz --execute h=d-mm-05-2-svz \
   --filter '$event->{fingerprint} =~ m/^select/

Außerdem kann man damit sehr elegant an einem Zweitsystem verschiedene Dinge testen und die Auswirkungen direkt beobachten.
Es bietet sich dazu an, dass man sein System damit immer genau im Blick hat:

  • Ganglia (Distributiertes Grid Monitoring)

ganglia-view

Ganglia ist eine Allzweckwaffe, um ein Gefühl dafür zu bekommen, wie eine Datenbank “lebt”. Es visualisiert quasi den Herzschlag des Systems. Durch gmetric bekommt man zudem die Möglichkeit mit wenig Aufwand alle möglichen Parameter vom System oder der Datenbank an Ganglia zu übergeben und damit zu visualisieren. Basics dabei sind die Queries per Second, Slave Lag und Slow Queries per Second.

  • iostat -x

Was ist auf meinen Platten los? Wie verteilt sich das await auf die einzelnen Devices? Viel sieht man damit leider nicht, aber es gibt deswegen Erweiterungen für MySQL, die das IO bis auf Tabellen und Indizes runterbrechen können.

  • Nagios – damit man den Fehler auch mitbekommt

Kristian Köhntopp hat dafür was Nettes gebaut. Man braucht an der Stelle also nicht mehr ganz so viel tun.

Nicht zu vergessen der Kommandozeilenclient mysql mit einem ordentlichen Prompt, damit man nicht bei mehreren Maschinen durcheinander kommt:

[mysql]
prompt = \u@hostname[\d]>\_

MySQL und INNODB_IO_PATTERN

logo_mysql_sun_aPercona ist ein Consultingunternehmen für MySQL und hilft als remote DBA, bei Architekturplanungen, Trouble Shooting und Database Recovery. Percona wurde 2006 von Peter Zaitsev und Vadim Tkachenko gegründet.

Seit einiger Zeit nutzen wir auf unserer Plattform die MySQL-Version von Percona, weil es unheimlich praktische Patches gibt, die uns als DBA das Leben erleichtern.

  • Session status to check fragmentation of the last InnoDB scan
  • SHOW USER/TABLE/INDEX statistics
  • SHOW PATCHES
  • Adds additional information of InnoDB internal hash table memories in SHOW INNODB STATUS
  • Information schema table of InnoDB IO counts for each datafile pages
  • Adds INFOMATION_SCHEMA.PROCESSLIST with TIME_MS column
  • Add locks held, remove locked records in SHOW INNODB STATUS
  • Extended statistics in slow.log
  • Patch allows redirect output of error.log to syslog-ng
  • Information of fsync callers in InnoDB
  • Show innodb buffer pool content

Mit show index_statistics sieht man z.B. sehr gut, wieviele Rows durch welchen Index gelesen wurden. Ideal, um nicht benutzte Indizes aufzuspüren.
Natürlich will man auch wissen, wie sich die IO auf einzelne Tabellen und Indizes verteilt. Dafür gibt es dann im Information-Schema die Tabelle INNODB_IO_PATTERN:

$ describe INNODB_IO_PATTERN;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| SPACE      | bigint(11)  | NO   |     | 0       |       |
| OFFSET     | bigint(11)  | NO   |     | 0       |       |
| INDEX_ID   | bigint(11)  | NO   |     | 0       |       |
| TABLE_NAME | varchar(32) | NO   |     | NULL    |       |
| INDEX_NAME | varchar(32) | NO   |     | NULL    |       |
| N_READ     | bigint(11)  | NO   |     | 0       |       |
| N_WRITE    | bigint(11)  | NO   |     | 0       |       |
+------------+-------------+------+-----+---------+-------+
7 rows in set (0.01 sec)
 

Bevor man Auswertungen starten kann, muss MySQL erstmal Daten sammeln:

$ set global innodb_io_pattern_trace = 1;
$ set global innodb_io_pattern_trace_running = 1;
$ set global innodb_io_pattern_trace_size_limit = 1;
-- Anzahl der Pages die gesammelt werden sollen

Man muss auch unbedingt darauf achten, dass man genug freien Hauptspeicher hat, bevor man das Tracing startet.
Auswertung des IO für jeden Index, getrennt nach Read und Write:

$ select sum(i.n_read) n_read, sum(i.n_write) n_write, index_name, table_name from information_schema.innodb_io_pattern i group by index_id

Dokumenation, Sourcen und Binaries finden sich im Wiki von Percona. Großes Lob also an die verschiedenen Entwickler, die dafür sorgen, dass auch die Datenbanken bei studiVZ unheimlich gut performen. Hier aus unserem Grid Monitoring die aggregierte Datenbanklast in Queries pro Sekunden:

qps1

Auf der Suche nach den verschwundenen Fotos

hotlinkingAm Dienstag, den 17.02., haben wir bei unserem Content Delivery/Distribution Network (CDN) ein sogenanntes “Referrer Checking” aktiviert. Wird also versucht ein Foto, das bei uns liegt, auf einer anderen Internetseite einzubinden (Stichwort Hotlinking), kommt nicht das gewünschte Foto sondern die nebenstehende Grafik.

Übrigens… In Spitzen laden VZ Nutzer mal locker über 1.000.000 neue Fotos am Tag bei uns hoch und es werden um die/über 70.000 Anfragen pro Sekunde an unser CDN gestellt. Das CDN schützt unsere Image Server (die Server, die die ganzen Fotos und anderen statischen Inhalte ausliefern) davor, sich dieser enormen Last selber stellen zu müssen.

Ich weiß nicht, was ich verbrochen habe, aber ich sehe seit einigen Tagen keine Fotos mehr im meinVZ, studiVZ oder schülerVZ. Hilfeee!

Dafür kann es verschiedene Gründe geben. Letztlich reduziert sich das darauf, dass euer Browser (Firefox, Internet Explorer, Safari, Opera usw.) keinen korrekten “Referrer” übermittelt. Daran muss nicht direkt der Browser schuld sein. Antiviren-, Firewall- oder Proxy-Software zum Beispiel beeinflussen die Übermittlung des Referrers bzw. verändern diesen dahingehend, dass anstelle des korrekten Referrers ein “Blocked by Firewall XYZ” übermittelt wird, sofern man dies nicht deaktiviert. Manche haben sich vielleicht das Firefox Add-on “RefControl” installiert. Dort und bei der anderen Software sollte zumindest das Senden eines leeren Referrers eingestellt sein. Dann müsste alles wieder funktionieren.

[UPDATE]
Wir haben uns unterdessen dazu entschieden, auch leere Referrer zu akzeptieren. Deshalb wurde der Artikel entsprechend angepasst und ist jetzt etwas übersichtlicher geworden.

[UPDATE]
Unterdessen sind leere Referrer wieder von der Whitelist gestrichen worden. Wer jetzt noch mit den Fotos ein Problem hat, schaue bitte in die entsprechenden Hilfegruppen:

http://www.meinvz.net/Groups/Overview/fbd443e298aee375
http://www.studivz.net/Groups/Overview/193b82ce5c44d2ba
http://www.schuelervz.net/Groups/Overview/f2d4f75f70701b0f

[UPDATE]
Leere Referer sind wieder erlaubt.

[UPDATE 16.11.2010]
Aufgrund der unsteten Ergebnisse des Referrer-Checks und massiven Nutzerbeschwerden haben wir uns entschieden, den Check auf allen drei Plattformen schülerVZ, studiVZ und meinVZ wieder abzuschalten.

Sobald wir zusätzliche geeignete Maßnahmen zum Schutz von Bildern im VZ kennen, werden wir deren Einsatz umgehend prüfen.

Wartungsarbeiten/Offline

Morgen früh (Dienstag, den 10.02.09) gehen wir mit meinVZ, studiVZ und schülerVZ von 01.00 bis ca. 08.00 Uhr offline aufgrund von Wartungsarbeiten an den Datenbanken.

Wartung

Unter anderem sind wir dabei die Datensätze der Gruppenmitgliedschaften zu partitionieren, die vorher zusammen gespeichert waren. Es gibt von Flickr eine Präsentation über das Data Sharding die ziemlich gut beschreibt, was wir machen werden. Außerdem geht nach tagelanger Arbeit unser neuer LVS/ Heartbeat 2-Cluster mit einer neuen Version online. Mit dem LVS läuft im Backend die komplette Lastverteilung auf die Systeme, dank Direct Server Routing hält sich der Durchsatz auch in Grenzen, da nur die eingehenden Frames durch das System müssen.

Mehr dazu demnächst in einem anderem Blog-Post.

P.S. Der/das Blog bleibt online.