• Mai
  • 18
  • 2010

MySQL – Recovery

Posted by okami In Datenbanken, Featured | 3 Comments »
MySQL - Recovery

Letztens bekam ich kurzzeitig einen Herzaussetzer, weil ich beim Restore des Datenbankbackups (LVM) bemerkte, dass doch die ib_logfiles nicht mit zurückgesichert wurden. Nachdem ich kurz nachgeschaut und fetsgestellt habe, dass die im Standardverzeichnis unter /var/lib/mysql herumdümpelten und nicht auf dem Logical Volume wo sie gesichert werden, wurde es erstmal finster ums Hirn. Hmm das passiert und zwar jeden Tag und wenn es solche Momente nicht gäbe, wäre ja alles irgendwie zu einfach …

Was tun, sprach Zeus?

Die Antwort findet sich in der MySQL Dokumentation. Allerdings für meine Begriffe völlig zu unrecht in “2 Nebensätzen” abgehandelt und wenn es brennt findet man das sowieso nie. Also aus diesen Anlass hier ein paar hilfreiche Tipps, Tricks und Anwendungsbeispiele um gecrashte, falsch gesicherte und sonstwie misshandelte Tabellen oder MySQL Instanzen wiederherzustellen, aber der Reihe nach.

  • Apr
  • 05
  • 2010

debian lenny gimp 2.6.8 und qtpfsgui 1.9.3

Posted by okami In Fotografie, Howtos | 3 Comments »

Gimp & Qtpfsgui sind wohl die wichtigsten Tools zur Grafikbearbeitung unter Linux, insofern will man ja auch von den neuen Features profitieren und ganz ehrlich … wenn es sich um eine Desktopumgebung handelt, die nicht produktiv ist, nerft Debians Releasepolitik mächtig. Also, hier die Quick & Dirty Variante um Gimp und Luminance HDR (Qtpfsgui) als Debianpaket aktuell auf einem Debian Lenny zu übersetzen:

apt-get build-dep gimp
apt-get install libgegl-0.0-dev
wget ftp://ftp.gimp.org/pub/gimp/v2.6/gimp-2.6.8.tar.bz2
tar -xjf gimp-2.6.8.tar.bz2
 cd gimp-2.6.8/
./configure --prefix=/usr
make
checkinstall
dpkg -i  gimp_2.6.8-1_i386.deb
apt-get build-dep qtpfsgui
wget http://downloads.sourceforge.net/qtpfsgui/qtpfsgui-1.9.3.tar.gz
tar xzvf qtpfsgui-1.9.3.tar.gz
cd qtpfsgui-1.9.3/
qmake PREFIX=/usr
checkinstall
dpkg -i qtpfsgui_1.9.3-1_i386.deb

Achtung gimp und qtpfsgui werden nach /usr installiert, wer hier Konflikte mit den Paketen aus dem “Lenny Standard Repository” vermeiden will, sollte die Prefixanweisungen weglassen. Dann werden die Pakete gegen /usr/local/ kompiliert und installiert und können Notfall parallel installiert werden.

  • Mrz
  • 20
  • 2010

Replikation mit MySQL 5.x

Posted by okami In Datenbanken, Featured | No Comments »
Replikation mit MySQL 5.x

Master – Slave Replikation:

Szenario:

Replikation aller Datenbanken eines Server zu Backupzwecken auf einen weiteren Server. Achtung: Dies kann auch erreicht werden, indem wir eine zusätzliche Instanz auf unseren vorhanden Server einrichten. Zunächst müssen wir sicherstellen, dass in der my.cnf folgende Einträge wie folgt vorhanden sind:

#bind-address           = 127.0.0.1
muss auskommentiert werden, damit die MySQL Instanz auf den externen Interfaces erreichbar ist

log-bin = /var/log/mysql/mysql-bin.log
hiermit schalten wir das binlog ein, welches zwingen notwendig für die Einrichtung einer Replikation ist, auf dem Slave können wir die Binlogs ebenfalls anschalten. (Backup)

server-id=1
diese IDs müssen auf den an der Replikation beteiligten Servern eingerichtet und unterschiedlich sein

expire_logs_days        = 10
gibt an, ab wieviel Tagen die Logs gelöscht werden

max_binlog_size         = 500M
die maximale Größe eines Binlogs

Danach starten wir MySQL auf dem Server neu:

/etc/init.d/mysql restart

Überprüfe dann mit

netstat -tanp | grep mysql

ob MySQL wirklich auf allen Interfaces hört:

okami:~# netstat -antp | grep mysql
tcp 0 0 *:mysql *:* LISTEN 2671/mysqld

Auf dem Master Server richten wir anschliessend den Benutzer für die Replikation ein:

mysql -u root -p

Führe in der MySQL Kommandozeile folgende Befehle aus:

GRANT REPLICATION SLAVE ON *.* TO ’replikation_user’@'IP_SLAVE’ IDENTIFIED BY ’replikation_passwort’;
FLUSH PRIVILEGES;
quit;

Das weitere Vorgehen ist davon abhängig ob wir schon Daten in der Datenbank haben, oder ob wir die Datenbank erst jungfräulich aufgesetzt haben.

Wenn Master und Slave sozusagen frisch aufgesetzt sind, noch keine Daten existieren, notieren wir auf dem Master Binlog und Binlogposition weg.

SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000009 |      112 |              |                  |
+------------------+----------+--------------+------------------+

Auf dem Slave passen wir die my.cnf wie folgt an:

#bind-address           = 127.0.0.1
server-id = 2

log-bin= /var/log/mysql/mysql-bin.log

relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index

expire_logs_days        = 10
max_binlog_size         = 500M

Danach starten wir MySQL auf dem Server neu:

/etc/init.d/mysql restart

und richten die Replikation ein hier werden die Werte von dem Masterserver verwendet

mysql -u root -p

CHANGE MASTER TO MASTER_HOST='IP_MASTER', MASTER_USER='replikation_user', MASTER_PASSWORD='replikation_password', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=113;
START SLAVE;

Den Status der Replikation überprüfen wir mit:

SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: IP_MASTER
                Master_User: replikation_user
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000009
        Read_Master_Log_Pos: 130
             Relay_Log_File: slave-relay-bin.000001
              Relay_Log_Pos: 00000004
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 2
            Relay_Log_Space: 690471192
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

Wichtig: Slave_IO_Running und Slave_SQL_Running müssen auf Yes stehen. Anderen Falles stimmen z.B. die Userberechtigungen des Replikationsusers nicht, das Passwort ist nicht oder nicht richtig eingetragen, oder  die MySQL Instanz kann sich nicht zum Master verbinden(Port, Ip usw.). Wie solche DInge repariert werden folgt an anderer Stelle.

Wenn der Master schon Daten enthält müssen wir anders vorgehen. Hierzu gibt es mehrere Varianten – die von mir vorgestellte benutze ich fast wöchentlich um Replikationen neu Aufzusetzen. Wenn wir den Master und den Slave vorbereitet haben, ziehen wir uns ein Backup mit mysqldump auf dem Masterserver.

Achtung je nachdem welche Engines ihr benutzt und wie diese verwendet werden, kann es zu Problemen führen. Die INNODB – Variante berücksichtigt, dass nur in Innodbtabellen geschrieben wird und somit können wir im Livebetrieb ein konsistentes Backup für eine Replikation ziehen. Wenn Ihr auch MyISAM Tabellen im Einsatz habt und in diese auch geschrieben wird, muss die Datenbank erst gelocked werden, siehe weiter unten.

INNODB

mysqldump -uroot -p --triggers --routines --verbose --master-data=2 --flush-logs --single-transaction --all-databases | gzip -1 -c > /pfad/dump.sql.gz

MyISAM

mysql -uroot -p

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000999 |      112 |              |                  |
+------------------+----------+--------------+------------------+

Damit haben wir den Master gelocked, sprich es können keine Daten in die Datenbank geschrieben werden.

mysqldump -u root -p --triggers --routines --verbose --all-databases | gzip -1 -c > /pfad/dump.sql.gz

Nachdem wir nun den Dump auf den Slave kopiert haben spielen wir ihn in die Datenbank ein:

gunzip -c /pfad/dump.sql.gz | mysql -uroot -p

INNODB

gunzip -c /pfad/dump.sql.gz | head -n22 | tail -n1
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.122978', MASTER_LOG_POS=98;

mysql -uroot -p

CHANGE MASTER TO MASTER_HOST='IP_MASTER', MASTER_USER='replikation_user', MASTER_PASSWORD='replikation_password', MASTER_LOG_FILE='mysql-bin.122978', MASTER_LOG_POS=98;
START SLAVE;

MyISAM

Hier benutzen wir die Angaben aus dem SHOW MASTER Befehl des gelockten Masters.

mysql -uroot -p

CHANGE MASTER TO MASTER_HOST='IP_MASTER', MASTER_USER='replikation_user', MASTER_PASSWORD='replikation_password', MASTER_LOG_FILE='mysql-bin..000999', MASTER_LOG_POS=112;
START SLAVE;

Wenn wir überprüft haben, dass die Replikation läuft (SHOW SLAVE STATUS;) müssen wir in der MyISAM – Variante nur noch die Datenbanken auf dem Master wieder freigeben:

 UNLOCK TABLES;
  • Feb
  • 02
  • 2010

mysql – sichern von Prozeduren, Funktionen und Triggern

Posted by okami In Datenbanken | No Comments »

MySQL 5 kommt mit vielen netten neuen Features, wie z.B. stored procedures oder triggers.
Kurz soll erläutert werden, wie man mittels mysqldump Prozeduren, Trigger etc. sichern kann.

mysqldump sichert via default alle trigger aber KEINE Prozeduren/Funktionen. Für das Verhalten von mysqldump sind 2 Optionen verantwortlich:

  • –routines – Defaultwert ist FALSE
  • –triggers – Defaultwert ist TRUE

Also wenn zusätzlich zu den Triggern, die Prozeduren mit gesichert werden sollen, muss die Option –routines dem Script etc. mit übergeben werden.

mysqldump <mysqldump optionen> --routines > outputfile.sql 

Nehmen wir an, wir wollen nur die gespeicherte Prozeduren und Trigger sichern und nicht die MySQL-Tabellen und Daten (dies kann nützlich sein, wenn diese z.B. geändert werden oder diese auf einer anderen Datenbank importiert werden soll, der bereits die Daten, nicht aber die gespeicherten Prozeduren und / oder Trigger enthält), dann sollten wir folgendes tun:

mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt <database> > outputfile.sql

Dies sichert allerdings nur die Prozeduren,Trigger und Funktionen der angegebenen datenbank <database>. Um diese zu importieren benutzen wir folgenden Befehl:

mysql <database> < outputfile.sql
  • Jan
  • 25
  • 2010

Metasploit auf Debian installieren

Posted by okami In Howtos | 2 Comments »

Da keine Pakete für Metasploit existieren und so die Abhängigkeiten nicht automatisch aufgelöst werden, hier die Quick & Dirty Variante:

aptitude install ruby libruby rdoc libyaml-ruby libzlib-ruby libopenssl-ruby libdl-ruby  libreadline-ruby libiconv-ruby libgtk2-ruby libglade2-ruby
cd /usr/src/
wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
tar -zxvf rubygems-1.3.5.tgz
cd rubygems-1.3.5
ruby setup.rb

okami:/usr/bin# ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

okami:/usr/bin# gem -v
1.3.5

okami:/usr/bin# gem update --system
Updating RubyGems
Nothing to update

okami:/usr/bin# gem install rails

okami:/usr/bin# rails -v
Rails 2.3.5

cd <Installationspfad für metasploit>
svn co https://www.metasploit.com/svn/framework3/trunk/
  • Jan
  • 23
  • 2010

Beispieldatensätze aus einer MySQL Datenbank ziehen

Posted by okami In Datenbanken | No Comments »

Hier eine Quick & Dirty Anleitung, die zeigt, wie man einen kleinen Probedatensatz aus einer MySQL-Datenbank mittels mysqldump zieht. Wir brauchen zum Beispiel öfters eine kleine Momentaufnahme aus sehr großen Produktionsdatenbanken, um sie in ein Entwicklungs- oder Test-Datenbank einzuspielen. Sagen wir mal, wir brauchen 1000000 Datensätze aus allen Tabellen in der Datenbank. Dazu benutzen wir einfach die Option – where = “true LIMIT X”, wobei X der Anzahl Datensätzen entspricht die wir benötigen.

mysqldump --opt --where="true LIMIT 1000000" mydb > mydb1M.sql

Kategorien