UBI2GO

Problem:

Fehlermeldung MySQL: 1030 Got error 28 from storage engine

Lösung:

df -h

Keinen freien Festplattenspeicher auf dem System.

Problem:

Erstellt man mit mysqldump einen Abzug der Datenbank kennt man das Problem die Sonderzeichen bzw. Umlaute in kryptischer Form vorliegen zu haben.

Lösung:

Beim einspielen mit mysql wird auch als Default Character Set LATIN1 benutzt, deshalb folgender Aufruf zum einspielen der Daten:

mysql -v -u<user> -p<password> <datenbank> < backup.sql –default-character-set=utf8

Problem:

mysql-server Version 5.1

Error    : Unknown table engine ‘InnoDB’

Lösung:

Habe lange gesucht bis ich diese Lösung für die Fehlermeldung gefunden habe:

Die beiden Dateien ib_logfile0 und ib_logfile1 im Verzeichnis /var/lib/mysql löschen bzw. irgendwo anders verschieben.

Und siehe da nach einem Neustart des MySQL Servers funktioniert der InnoDB Table wieder.

Aber der Version 5.1.44 des MySQL-Servers wird das InnoDB Plugin in der Version 1.0.6 mit ausgeliefert. Falls man also in den früheren Versionen das Plugin händisch eingespielt und konfiguriert hat. Muss man die Konfiguration in der my.cnf ändern.

Die Einstellung ignore_builtin_innodb sollte auskommentiert werden, ansonsten bekommt man folgende Fehlermeldung beim Zugriff auf den Tabelleninhalt einer InnoDB-Datenbank:

[ERROR] Can’t open shared library ‘ha_innodb.so’ (errno: 0 API version for STORAGE ENGINE plugin is too different)

Datenbanksysteme, die den neuen Anforderungen an nicht-rationale, verteilte und horizontal skalierbare Datenbanken nachkommt.

http://nosql-database.org/

SIDU ist ein Datenbank-Client, dessen Oberfläche im Web-Browser ausgeführt wird. Er eignet sich für MySQL,PostgreSQL und SQLite.

InnoDB bietet:

• Transaktionen
• Locking auf Zeilen Ebene
• Speicherung in Tablespaces
• Referenzielle Integrität
• Primärschlüssel
• Datensatz-Cache

InnoDB Plugin bietet zustätzlich:

• Erweiterungen zur Performance und Skalierbarkeit

  • Schnelleres Locking für bessere Skalierbarkeit auf Multi-Prozessor-Systemen
  • Nutzung von mehren skalierbaren Memory Alloziierern
  • dynamische Kontrolle von INSERT Buffering, adaptive Hash-Indexierung und Thread-Nebenläufigkeit

• Schnelle Index-Erstellung: Index erstellen oder löschen ohne Daten zu kopieren
• Datenkompremierung, Verkleinerung von Tabellen zur Reduzierung von I/O und Speicherverbrauch
• Neues Zeilenformat: fully off-page storage von long BLOB, TEXT und VARCHAR Spalten
• Dateiformatmanager: Zuständig für Auf- und Abwärtskompatibilität
• INFORMATION_SCHEMA Tabellen: Informationen über Kompression und Locking
• Weitere Änderungen für erhöhte Flexibilität, bessere Handhabung und  Ausfallsicherheit

  • Dynamische Kontrolle über viele Konfigurationsparameter
  • TRUNCATE TABLE Wiederherstellung der *.ibd Datei um Speicher zurückzugewinnen
  • “Strict mode” um Fehler zu vermeiden
  • Kontrolle über die statistischen Beurteilungen des Optimizers
  • Besseres Error Handling wenn Indexe verworfen werden

Und MyISAM bietet:

• Locking auf Tabellenebene
• Speicherung in getrennten Dateien (eine pro Tabelle)
• Volltextindizierung
• Daten-Komprimierung

Den Status der Tabelle kann man mit folgendem Befehl ermitteln:

SHOW TABLE STATUS LIKE ‘Tabellenname’

Zur Laufzeit ist es problemlos möglich den Typen der Datenbank-Tabelle zu ändern:

ALTER TABLE `tabellen_name` TYPE=MYISAM
ALTER TABLE `tabellen_name` TYPE=InnoDB

Fazit:

MyISAM dürfte noch einen Performancevorteil gegenüber dem InnoDB Plugin in haben. Für welchen Datenbanktyp man sich schließlich entscheidet liegt oft an der Art der Applikation, die darauf zugreift. Sollten Features wie z.B. Transaktionssicherheit keine Rolle spielen, dann kann die Entscheidung auf MYISAM fallen. Jedoch hat mich das neue InnoDB Plugin von den Features als auch von der Performance überzeugt, dass ich mich dafür entschieden habe.

Quellen:

http://www.innodb.com/products/innodb_plugin/features/

Am Ende Jahres 2009 stand ich vor der Problematik, dass meine Applikation mit mehr als 3000 Benutzern und mehreren Terra-Byte an Daten immer mehr an Performance verlor.

Besonders die Administratoren bedanken sich, bei Aufrufzeiten von über einer Minute für jeden Seitenwechsel, beim System.

So begann ich erstmal die  in Java geschriebenen objektorientierten, rekursiven Methoden Schritt für Schritt aufzulösen.

Der Ist-Wert vor dem Umbau lag bei bis zu 870 SQL-Anfragen pro Seitenaufbau, nach dem Umbau lang er konstant bei 5 Aufrufen und einer Performanceoptimierung von circa 700%.

Dabei kam mit besonders die Verwendung von rekursiven SQL-Abfragen auf der Datenbank entgegen, um die in Ordner gruppierten Objekte hierachisch auflösen zu können.

Voraussetzung:

DIRECTORY-Table: DIRECTORY_ID, PARENT_ID

LEVEL eine Integer oder Long Variable zur Beendigung des SQL im Fehlerfall infinite LOOP

Rekursive SQL-Abfrage:

[Quellen]

http://www.mayeruli.de/db2/rekursives-sql.html

http://www.thomas.teufl.eu/blog/2007/09/27/t-sql-rekursive-abfragen/

http://www.orafaq.com/node/1879

Ab der Version 5.1 der MySQL-Datenbank steht es Nutzern frei eine alternative Version der InnoDB zu benutzen.

Dazu stellt die Firma InnoDB ein Plugin für InnoDB unter MySQL zur Verfügung.

Diese Plugin beinhaltet  viele neue Features, die sich positiv auf  die Performance, Skalierbarkeit, Ausfallsicherheit, Handhabung und Flexibilität auswirkt.

Bei der  Performance verspricht man sich eine Steigerung um 20% bis 30%. Auch können InnoDB-Tabellen endlich vernünftig ohne SQLDump gesichert werden. Nähere Informationen finden sie in der Feature Liste der Firma InnoDB.

Installation InnoDB Plugin

Zuerst besorgen wir uns das Binary des Plugins und entpacken es auf dem Server:

wget http://www.innodb.com/download/innodb_plugin/innodb_plugin-1.0.6-linux-x86_64-glibc23.tar.gz

tar -xzf innodb_plugin-1.0.6-linux-x86_64-glibc23.tar.gz

Anschließend kopieren wir unter Debian das Plugin in das Lib-Verzeichnis von MySQL:

cd innodb_plugin-1.0.6-linux-x86_64-glibc23

cp ha_innodb.so /usr/lib/mysql/plugin/

Zum Schluß passen wir noch die Konfigurationsdatei (/etc/mysql/my.cnf)  vom MySQL an, damit beim Start der Datenbank die eingebaute Version von InnoDB ignoriert wird  und an dessen Stelle das neue Plugin und alle InnoDB Information Schema Tabellen geladen werden.

[mysqld]

ignore_builtin_innodb

plugin_load=innodb=ha_innodb.so;innodb_trx=ha_innodb.so;innodb_locks=ha_innodb.so;innodb_lock_waits=ha_innodb.so;innodb_cmp=ha_innodb.so;innodb_cmp_reset=ha_innodb.so;innodb_cmpmem=ha_innodb.so;innodb_cmpmem_reset=ha_innodb.so

Die Konfigurationsdatei speichern, den Server neustarten und viel Spass mit dem neuen Plugin haben.

[Quellen:]

http://www.innodb.com/products/innodb_plugin/

http://www.innodb.com/wp/products/innodb_plugin/download/v106/

http://www.dotdeb.org/

Eine kurze Anleitung, wie Apache2, PHP5 und MySQL5 auf UTF-8 unter Debian sicherstellt.

Apache2

Änderung in der Datei /etc/apache2/apache2.conf vornehmen:

AddDefaultCharset utf-8

bzw. kann man auch in Debian in der Datei /etc/apach2/conf.d/charset diese Änderung vornehmen

PHP

Änderung in der Datei /etc/php5/apache2/php.ini vornehmen:

[PHP]
default_charset = “utf-8?
[mbstring]
mbstring.language = utf-8
mbstring.internal_encoding = utf-8
mbstring.http_input = utf-8
mbstring.http_output = utf-8

MySQL

Änderungen in der Datei /etc/mysql/my.cnf vornehmen:

[client]
default-character-set = utf8
[mysqld]
default-character-set = utf8
character-set-server = utf8
collation-server= utf8_general_ci
init_connect = ‘SET collation_connection = utf8_general_ci’
init_connect = ‘SET NAMES utf8?
[mysqldump]
default-character-set = utf8
[mysqlimport]
default-character-set = utf8
[mysql]
default-character-set = utf8

Anmerkung:

Voraussetzung für die Umstellung ist die UTF8 Konvierung von Dateien und Datenbanken.

Linux Tool für die Konvertierung von Dateien ist z.B. iconv