Tag Archives: MySQL

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