mysql Replikation wiederherstellen

Zum Glück kommt das ganz selten vor … Aus dem Grund muss ich das leider immer wieder nachlesen. Kurz die Schritte:

  1. Auf dem Master
    SHOW master STATUS;  
     +------------------+-----------+---------------------+------------------+  
     | File             | POSITION  | Binlog_Do_DB        | Binlog_Ignore_DB |  
     +------------------+-----------+---------------------+------------------+  
     | mysql-bin.000123 | 010235031 |                     |                  |  
     +------------------+-----------+---------------------+------------------+
  2. Auf dem Slave
    stop slave;  
    CHANGE master TO master_log_file='mysql-bin.000123', master_log_pos=010235031;  
    START slave;

Gibt’s auf dem Slave Fehler, die einfach übersprungen werden sollen dann geht das mit dem folgenden

 stop slave;  
 SET global sql_slave_skip_counter = N;  
 START slave;

Damit hab ich aber nur schlechte Erfahrungen gemacht. Besser alles richtig machen 🙂

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

mysql Tabllen kopieren

Ich meide phpmysqladmin wie die Pest. Das Teil überrascht einen immer wieder mit Sicherheitslücken, die sofort ausgenützt werden. Erinnere mich gerade an diverse XSS Angriffe, bei denen es nicht mal nötig war sich bei phpmyadmin anzumelden. Aus dem Grund mache ich immer viel zu Fuß direkt auf der Datenbank. Manche Queries brauche ich aber nur sehr selten und muss sie daher nachlesen. Hier meine Notiz für das Kopieren von Tabellen.

  1. Tabellen ohne Daten
    CREATE TABLE ziel LIKE quelle
  2. Tabellen mit Daten
    CREATE TABLE ziel SELECT * FROM quelle
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Update: Optimize Table fällig?

Ich kann mir einfach nicht merken, wie man bei MySQL checkt ob Tabellen optimiert werden müssen. Jetzt wird’s aufgeschrieben:

show table status from test where data_free > 0;

Update:
Der Query ermittelt natürlich nur den verschwendeten Platz. Ein Optimize Tabelle kann aber auch schon früher sinnvoll sein. Etwa wenn Werte innerhalb der Tabellen sehr oft geändert wurden.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

SQL: Truncate vs. Delete

Args, eben bin ich fast ausgeflippt, weil ein Truncate auf eine Tabelle immer an Foreignkey Constraints gescheidert ist. Für die Daten existierten aber nicht solche Bedingungen, die ein nicht Löschen rechtfertigten. Erst nach einer Ewigkeit habe ich mal ein „delete from …“ versucht und zu meinem Erstaunen festgestellt, dass er funktioniert hat.

Oha, Warum denn das?

Des Rätsels Lösung wissen wahrscheinlich alle außer mir. Aber damit ich mir es auch merke schreibe ich mir auf, dass bei einem Truncate alleine die theoretische Möglichkeit von Beziehungen auf der ganzen Tabelle prüft und nicht wie bei einem Delete pro Datensatz das tatsächliche Vorhandensein einer dedizierten Beziehung.

Merke: Truncate bei Tabellen mit Constraints gehen schief, wenn die Constraints nicht vorher deaktiviert sind.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

MySQL – HA

Eben bin ich in Alex Williams Blog auf 2 interessante Artikel gestoßen. Einer beschreibt „Scripted MySQL Replication Consistency Checks„, beim anderen geht es um „Using HAProxy for MySQL failover and redundancy„. Die Links gehören auf meine Leseliste. Den HAProxy-MySQL Cluster muss ich mal nachbauen. Da wird meine VMWare kochen 🙂

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

MySQL-Server: Platte voll …

Wenn auf einem MySQL-Server die Platte voll läuft, so liegt es in 80% der Fälle nicht an den Database-Files selbst, sondern eher an den Binlog-Files. Obwohl die meisten MySQL-Installation die ich kenne, ohne Binlog-Files laufen, bin ich eher ein Fan von ihnen und schalte sie eigentlich per default immer an. Binlog-Files sind einfach fantastisch, wenn es um Datensicherheit geht. Mit Hilfe der Binlogs lassen sich wunderbar inkrementelle Backups der Datenbank herstellen. Sie sind einfach zu mehr zu gebrauchen als nur fürs Replizieren. Daher hier ein paar Notizen für mich zum Thema Binlogs:

  1. Vermeide Reset Master
    Ist die Platte durch Binlogs vollgelaufen, so kann man die Binlogs einfach per

    RESET Master;

    entsorgen. Schlau ist das allerdings nicht. Besser ist es alle Binlogs vor der letzten Vollsicherung zu löschen:

    PURGE {MASTER | BINARY} LOGS BEFORE 'date';
  2. Binlogs und Database gehören nicht auf die gleiche Platte/Partition
    Stichworte: Performance und Datensicherheit. Logisch, oder?
  3. Point-In-Time-Recovery
    Ab einem bestimmten Zeitpunkt (z.B. nach der letzten Vollsicherung) zurücksichern:

    mysqlbinlog --start-datetime="2005-04-20 10:01:00"  /var/log/mysql/bin.123456 | mysql -u root -p

    Oder bis zu einem bestimmten Zeitpunkt (z.B. an dem sich ein Logikfehler eingeschlichen hat)

    mysqlbinlog --stop-datetime="2005-04-20 9:59:59" /var/log/mysql/bin.123456 | mysql -u root -p
  4. expire_logs_days nicht vergessen
  5. Mit expire_logs_days legt man fest wie lange alte Binlogs aufgehoben werden sollen. Hier muss mindestens die maximale Anzahl der Tage seit dem letzten Vollbackup rein. Am besten noch mehr. Damit lassen sich dann Logikfehler wieder gerade ziehen. Also sowas wie:

    expire_logs_days = 30
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Mehr Speicher

Ich hab meinen Server endlich mehr Speicher gegeben. Mit den bisherigen 512MB war er doch oft sehr am Limit. Jetzt hat er stolze 4GB. Natürlich habe ich gleich den Speicher gerecht unter den Hauptdaemons (MySQL und Apache) auf dem Server aufgeteilt.

Mysql war einfach. Dort hab ich einfach die Standard my.cnf von Debian durch die my-large.cnf ausgetauscht. Fertig. Mal sehen ob das was bringt.

Nachdem alle meine Anwendungen auf dem Server unter PHP laufen haben ich mich beim Apache primär auf den APC gestürzt. Da habe ich den stolzen 32MB Cache eben vervierfacht. Für den 128MB Cache sind folgende Einträge notwendig:

/etc/sysctl.conf:

kernel.shmall = 134217728
kernel.shmmax = 134217728

Danach Aktivieren mit:

sysctl -p

Und noch APC konfigurieren:
/etc/php5/apache2/conf.d/apc.ini

apc.shm_size=128

Noch Apache neustarten. Fertig.

Mal sehen ob ich mir jetzt das Swappen nicht mehr so oft anhören muss Mein Server steht im Arbeitszimmer neben mir und da kann ich tatsächlich hören, wenn er swapt. 🙂

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

MySQL Fehler HY000

Gestern am Flughafen habe ich mir fast einen Wolf gesucht. Ich war nach einem langen Tag sau müde und hab ewig gebraucht bis ich es gemerkt hatte. Beim Import eines Files via

LOAD DATA INFILE 'FILENAME' INTO TABLE DBTABLE

hat mir MySQL immer folgenden Fehler gebracht:

ERROR 13 (HY000) at line 1: Can't get stat of '/tmp/0815.csv' (Errcode: 2)

Im Netz habe ich immer Hinweise gefunden, dass das File vom MySQL Prozesse lesbar sein muss. Also habe ich 100mal die Rechte der Verzeichnis auf 0755 und die des Files auf 0644 gecheckt. Trotzdem hat es nicht funktioniert.
Das Problem war eigentlich nur, dass ich mich von einem Server auf den anderen mittels folgenden Befehl verbunden hatte:

mysql -ufoo -pbar -h172.16.1.2 test

Bei dem Aufruf oben erwartet Mysql allerdings das File auf dem Server und nicht auf dem Client. Richtig wäre folgendes gewesen:

LOAD DATA LOCAL INFILE 'FILENAME' INTO TABLE DBTABLE

Das entscheidende Wörtchen ist LOCAL

Ich schreibe das mal auf. Vielleicht hat noch jemand das Problem und ich suche hoffentlich das nächste mal nicht wieder ewig.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

Global privileges mit MySQL

Ich weiß RTFM… aber ich suche eben jedes mal in der Doku wie ich Global priviliges unter MySQL anlege. Im Speziellen geht es immer und immer wieder um das File Privileg. Load from file ist einfach um Welten schneller als jede Zeile per Hand in SQL zu kodieren. Also auf dass ich es mir merken kann, so geht’s:

GRANT FILE ON *.* TO 'my_user'@'my_host' IDENTIFIED BY 'my_password';
FLUSH privileges;
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Regexp mit SQL

Ich hasse den [[SQL]] Kauderwelsch. Das Standard SQL ist einfach zu wenig umfangreich. Deswegen entwickelt jeder seine eigenen Extensions. Alle sind irgendwie ähnlich aber dennoch unterschiedlich. Daher muss ich mir das hier immer notieren. Ich kann es mir nicht merken und will nicht immer Googlen.

Aktueller Fall Regexp mit SQL. Hier die Links

Ich finde die Oracle Lösung die bessere. Aber wahrscheinlich ist das Geschmacksache.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)