Schlagwort-Archive: mysql

phpmyadmin bei Ubuntu 18.04

Veröffentlicht am von

Seit einiger Zeit wird es immer schwieriger nach der Ubuntu-Installation phpmyadmin zu nutzen. Mir geht es darum vollen Zugriff auf die Datenbank zu bekommen.

Bei der aktuellen Version gibt es in der Datei /etc/mysql/debian.cnf einen Benutzeraccount:

 # Automatically generated for Debian scripts. DO NOT TOUCH!
 [client] 
 host = localhost
 user = debian-sys-maint
 password = CoitphsNFWH42dLg
 socket = /var/run/mysqld/mysqld.sock
 [mysql_upgrade]
 host = localhost
 user = debian-sys-maint
 password = CoitphsNFWH42dLg
 socket = /var/run/mysqld/mysqld.sock

Die hier angegebenen Zugangsdaten kann man von der Shell aus mittels:

mysql -u debian-sys-maint -p

nutzen. Man kann mit diesem Account auch phpmyadmin nutzen und von dort aus dann die gewünschten Änderungen vornehmen.

 

 

Veröffentlicht unter linux.

MySQL Logdatei

Veröffentlicht am von

Auf der Suche nach einem fremden Programmierfehler war für mich das bin-log von MySQL nützlich.  Im Verzeichnis /var/lib/mysql, wo auch die Datenbanken liegen, finden sich bei mir mehr als fünfzig Dateien mit fortlaufender Nummerierung der Art mysql-bin.000001 . Dies Dateien beinhalten alle auf dem System ausgeführten SQL-Befehle, also alle Inserts, Updates und dergleichen. Die Inhalte können mit dem Programm mysqlbinlog ausgelesen werden.

mysqlbinlog --database=DBX25631 mysql-bin.000049

Hier werden konkret alle Zugriffe auf die Datenbank DBX25631 ausgegeben, die sich in der Datei mysql-bin.000049 befinden. Datum und Uhrzeit finden sich auch in der Ausgabe:

# at 487195020
#120610 19:59:36 server id 1  end_log_pos 487195168     Query   thread_id=468274        exec_time=0     error_code=0
SET TIMESTAMP=1339351176/*!*/;
INSERT INTO `jos_acajoom_xonfig` VALUES ('date_update', '2011-08-15 14:54:54', 0)
/*!*/;

Mit diesen Informationen hat man eine Chance fehlerhafte Zugriffe zu erkennen.

Leider werden die Dateien sehr groß (je 1GB) und ihre Zahl scheint nicht beschränkt zu sein (die Stellenzahl lässt mich erschrecken).

Im Abschnitt [mysqld] der Konfigurationsdatei /etc/my.conf lässt sich die Lebensdauer der Logdateien beschränken, im Beispiel auf  90 Tage.

expire_logs_days = 90

Das sollte den Speicherplatzbedarf deutlich reduzieren.

 

MySQL Errorcode 24

Veröffentlicht am von

Beim Sichern einer Datenbank mittels mysqldump hatte ich das Problem, dass immer irgendeine Fehlermeldung auftauchte, die auf das Fehlern irgendeiner Datei hinwies. Bei genauerer Recherche stellte ich fest, dass es sich um ein Problem mit der Zahl der offenen Dateien handelt. Mysqldump versucht anscheinen alle Tabellen parallel zu öffnen und diese Datenbank besitzt sehr viele Tabellen.

Eine Einfache Lösung besteht darin statt (hier als root):

mysqldump datenbank -p > /tmp/datenbank.sql

zu schreiben:

mysqldump datenbank --single-transaction -p > /tmp/datenbank.sql

Damit funktioniert der Dump dann auch. Siehe dazu auch http://rackerhacker.com/2007/08/19/mysql-errcode-24-when-using-lock-tables/

MySQL und CSV

Veröffentlicht am von

Gelegentlich bekommt man Daten im CSV-Format.  MySQL kann auch damit umgehen.

Importieren kann man CSV-Dateien z.B. von phpMyAdmin aus mittels

LOAD DATA LOCAL
 INFILE '/tmp/land.csv'
 REPLACE
 INTO TABLE LAND
 FIELDS
 TERMINATED BY ';'
 OPTIONALLY ENCLOSED BY '"'

Anpasse muss man jeweils natürlich den Namen der Tabelle und den Namen der zu importierenden Datei.

Auch die Gegenrichtung ist möglich, also der Export in in CSV-Datei:

SELECT *
INTO OUTFILE '/tmp/land.csv'
FIELDS
TERMINATED BY ';'
OPTIONALLY ENCLOSED BY '"'
FROM LAND;