Schlagwort-Archiv: mysql

MySQL innodb_file_per_table Setting

MySQL Server speichern in der Default Einstellung den Content von InnoDB Datenbanken in einer einzigen Datei, dem sogenannten „System Tablespace“. Hat man also 5 Datenbanken mit je knapp 100 GB hat man schnell eine 600 GB große Datei vorliegen. o.O

In künftigen Versionen von MySQL (>5.6) soll die Defaulteinstellung geändert werden und entsprechend pro Tabelle eine Datei mit Index geführt werden. Für Administrative Dinge sicherlich von Vorteil. Aber Achtung: Bei vielen Tabellen ergibt das eine stattliche Anzahl File-Handles. Diese müssten unter Umständen erhöht werden (Thema „ulimit“).

Hier wird das kurz und knapp erklärt.
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_system_tablespace

Ich stelle jetzt auf multi-tablespaces um!
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

Wichtig auch der Hinweis, dass die Datei ibdata nicht im Verhältnis zu den gelöschten Datensätzen schrumpft.
http://www.schmut.com/howto/shrinking-ibdata
http://dba.stackexchange.com/questions/13614/ibdata-usage-and-recommendations

InnoDB: ERROR: the age of the last checkpoint

Problem:
Das Einspielen eines 90GB großen MySQL Dumps wurde beendet und im Syslog befinden sich folgende Fehler:

InnoDB: ERROR: the age of the last checkpoint is 9444120,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

Lösung:
Erweiterung der InnoDB Log Variablen um folgende Werte

innodb_buffer_pool_size = 2G
innodb_table_locks = OFF
innodb_log_buffer_size = 32M
innodb_log_file_size = 768M

Dann fahren wir die Datenbank herunter und löschen die vorhandenen Logfiles

rm -f /var/lib/mysql/ib_logfile*

Diese Dateien werden nach Neustart vom MySQL in der gewünschten Größe neu angelegt.

Mal schauen ob sich der 90 GB Dump nun einspielen lässt =)

MySQL Backupskript für Linux

Nichts geht über konsistente Backups. Vorallem im Datenbankbereich.
Zu diesem Zweck greife ich gerne auf das Script „automysqlbackup“ zurück.

Es handelt sich hierbei um ein Sourceforge Projekt, man findet es unter http://sourceforge.net/projects/automysqlbackup/.

Nach dem Download muss man das Paket entpacken, die install.sh ausführen und im Anschluss die Datei /etc/automysqlbackup/myserver.conf nach eigenem Belieben modifizieren.

Die README in /etc/automysqlbackup sollte man noch anschauen und entsprechend ein Script in /usr/local/sbin erstellen.

Einmal testweise ausführen und das Ergebnis prüfen. Schaut gut aus? Ok, nun noch ein Cronjob definieren, und fertig ist!

MySQL Tuning

Problem:
Ein MySQL Server könnte ein Flaschenhals sein. Das muss diagnostiziert werden… nur wie?

Lösung:
Es gibt verschiedene Scripte, um die Variablen der Datenbank in Verhältnis mit der Nutzung zu stellen.

1. tuning-primer.sh (Homepage)
http://www.day32.com/MySQL/tuning-primer.sh

2. MySQL Tuner (Homepage)
https://raw.github.com/rackerhacker/MySQLTuner-perl/master/mysqltuner.pl

Wichtig: Der MySQL Server sollte mindestens 2 Tage gelaufen sein!

Viel Spass bei der Recherche und Optimierung der Variablen!

Hier noch ein kleines Reportscript „mysqlreport“
http://hackmysql.com/mysqlreport

WordPress & phpass vs. Apache Auth

Problem:
Wordpress nutzt seit ca. Version 2.8 kein MD5 Hashing mehr. Es kommt zwischenzeitlich phpass zum Einsatz, um Passwörter einigermaßen sicher zu hashen. Weitere Infos erhält man auf der Projektseite. Ich möchte die WordPressdatenbank für weitere Authentifizierungen nutzen und daher per libapache2-mod-auth-mysql darauf zugreifen.

Lösung:
Man muss sich das Apache2 Modul selbst mit dem Code patchen wie es auf dieser Seite beschrieben ist.
http://stackoverflow.com/questions/12543883/apache-mod-auth-mysql-with-phpass-encrypted-password-wordpress
Ist nicht weiter schwer aber leider leicht unpraktisch. Ich überleg mir noch n anderes AuthKonzept bevor ich etwas realisiere.