Month: September 2013
wenn die mysql replikation mal klemmt (2)
neulich habe ich mal beschrieben, wie man einen einzelnen befehl bei der replikation auslaesst, wenn er denn zu problemen fuehrt.
ein anderes szenario ist, wenn mal stromausfall ist oder eine virtuelle maschine einfach ausgeschaltet bzw. “gekillt” wird. dann kann der master vielleicht nicht alles transaktionen in das replikations log schreiben oder sowas in der art. im logfile ist dann sowas zu finden:
MySQL Error: Client requested master to start replication from impossible position
zuerst den status auf dem master checken:
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.003615 | 4994240 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
dann den slave stoppen, seine position im aktuellen log mitteilen, bei der er weiter machen soll und wieder starten:
slave stop;
CHANGE MASTER TO MASTER_HOST='db.domain.tld', MASTER_USER='repl',MASTER_PASSWORD='geheim', MASTER_LOG_FILE='mysql-bin.003615', MASTER_LOG_POS=0;
slave start;
und dann kann man nur hoffen, dass nicht allzu viel kaputt geht. weil das ohne genauer nachzusehen erstmal quasi ein undefinierter zustand ist. wenns schief geht, empfihelt sich doch die standard methode, um eine mysql replikation einzurichten. also haupt datenbank stoppen, snapshot ziehen, auf slave kopieren, einrichten.. blablabla..
bluetooth ng
vielleicht auch doch nicht ng (next generation)… vielleicht war das auch die first generation oder ein super alpha prototyp?
Authentication service cannot retrieve authentication info
merke… einfach mal user und gruppen in die /etc/passwd und /etc/group eintragen und die /etc/shadow vergessen ist doof. ssh logins klappen dann nicht. und wenn man das passwort setzen will, kommt sowas:
~$ passwd username
passwd: Authentication service cannot retrieve authentication info.
bind: zone transfer deferred due to quota
neulich im logfile eines bind dns servers gefunden:
25-Sep-2013 09:40:45.611 zone domain.tld/IN/trusted: zone transfer deferred due to quota
keine panik! die anzahl gleichzeitiger zonen transfers ist beschraenkt. (ich bin noch auf der suche nach der einstellung und dem default wert.) der bind holt das aber ziemlich bald nach.
bueroschlaf aber richtig
immer schoen mit dem kopp auf der tastatur!
tausendstel millimeter genauigkeit in emails
lotus notes nimmts da ganz genau:
bind …but using default configuration file
auf debian systemen kommts beim upgrade auf neuere bind versionen (bzw. des ganzen systems) dazu, dass starten des bind diese warnung ausgespuck wird:
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
abhilfe schafft es, die datei /etc/bind/rndc.conf zu loeschen. vorher pruefen, ob in der /etc/bind/rndc.key der passende key drin steht. dann noch in der datei /etc/bind/named.conf pruefen, ob diese zeile vorhanden ist und ggf. einfuegen:
include "/etc/bind/rndc.key";
made my day: update to iOS7 and become waterproof
ein gut gemachter scherz im look einer original apple werbung. und angeblich soll es echt leute geben, die daran geglaubt haben!
welch nerdige ueberraschung
gerade noch irgendwo im tmp verzeichnis gefunden 😉