Autor: ports (Seite 14 von 82)

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Wir nutzen zwei Server um eine Vielfalt an Diensten zu nutzen und anzubieten. Die Dienste – Web, Mail, Subversion, WebDav, etc. – haben wir nicht zeitgleich auf beiden Servern laufen. So haben wir Mail beispielsweise auf foo und unsere „privaten“ Webseiten auf bar. Aber unsere Tracs haben wir wieder auf foo und so weiter.

Der Grund fuer zwei Server ist nicht in erster Linie die Verteilung von Last, sondern wir wollen sowas wie erhoete Verfuegbarkeit im Fehlerfall erreichen. Natuerlich muessen wir bei Ausfall einer Maschine noch etwas tun (Namensaufloesung, Dienste hochfahren), aber damit sind wir in der Regel schneller, als einen Server neu aufzusetzen. Denn dafuer muss man auch erst mal die Zeit haben.

Bei der Frage „Wo liegen welche Daten“ orientieren wir uns an dem sogenannten Filesystem Hierarchy Standard, den Dirk schon mal beschrieben hatte. So liegen also alle unsere, nicht fuer den Betrieb der Server benoetigten, Webseiten unterhalb von /srv/www, Mails haben wir in /var/vmail und so weiter. Die genutzte Struktur erlaubt es uns relativ unkompliziert und schnell eine Synchronisation der Daten zwischen beiden Systemen zu etablieren. So synchronisieren wir alle Webseiten alle Stunde von bar nach foo via /usr/bin/rsync -az –delete -b –backup-dir=/srv/bak/rsync/www -e „ssh -c arcfour“ /srv/www/ www-data@foo:/srv/www/. Mit –delete -b –backup-dir=/srv/bak/rsync/www stellen wir sicher, dass am Ursprungsort geloeschte Dateien auch im Ziel geloescht werden, aber auch eine Sicherung der Datei angelegt wird. Man weiss ja nie 🙂

Mail synchronisieren wir ebenfalls alle Stunde, mit im Grunde gleichem Aufruf wie fuer Webseiten. Etwas herausfordernder war die Synchronisation der MySQL-Datenbanken. Auf foo haben wir fuenf Datenbanken und auf bar sind es 21. Vorgabe fuer das zu erstellende Script war unter anderem, dass es ohne Anpassung, sowohl auf foo, als auch auf bar laueffaehig ist. Rausgekommen ist nachfolgendes.

#!/bin/bash
logger -t syncdbs.bash -i „Starting sync“
TIMESTAMP=$(date „+%Y%m%d“)
SOURCE_DIR=“/srv/bak/backup-md2″
DESTINATION_DIR=“/srv/bak/sync“
DB_PREFIX=“db.“
DB_USERNAME=$(awk ‚/user/ {print $3}‘ /etc/mysql/debian.cnf | uniq)
DB_PASSWORD=$(awk ‚/password/ {print $3}‘ /etc/mysql/debian.cnf | uniq)
if [ „`hostname`“ = „foo“ ];then
DB_TO_COPY=“dbbar_01 dbbar_02 dbbar_03 dbbar_04 dbbar_05 dbbar_06 dbbar_07 dbbar_08\
dbbar_09 dbbar_10 dbbar_11 dbbar_12 dbbar_13 dbbar_14 dbbar_15 dbbar_16 dbbar_17\
dbbar_18 dbbar_19 dbbar_20 dbbar_21″
REMOTE_SRV=“bar“
elif [ „`hostname`“ = „bar“ ];then
DB_TO_COPY=“dbfoo_01 dbfoo_02 dbfoo_03 dbfoo_04 dbfoo_05″
REMOTE_SRV=“foo“
else
logger -t syncdbs.bash -i „Aborting syncdbs. no proper hostname found. should be foo or bar.“
exit 9
fi
cd $DESTINATION_DIR
for i in $DB_TO_COPY
do
mysqlshow -u $DB_USERNAME -p$DB_PASSWORD | awk ‚{print $2}‘ | grep ^$i$
if [ $? -eq 0 ]
then
FILENAME=$DB_PREFIX$i-$TIMESTAMP*.sq*
# retrieve file from server
logger -t syncdbs.bash -i „retrieving $FILENAME“
scp -q filecopy@$REMOTE_SRV:$SOURCE_DIR/$FILENAME $DESTINATION_DIR/
# extract file
bzip2 -d $FILENAME
# import database
logger -t syncdbs.bash -i „importing $FILENAME“
mysql -u $DB_USERNAME -p$DB_PASSWORD $i < $FILENAME
rm $FILENAME
else
logger -t syncdbs.bash -i „error: no database $i. skipping $FILENAME“
fi
done
logger -t syncdbs.bash -i „Ending sync“

Basis fuer die Synchronisation ist ein entsprechendes Backup (mysqldump) auf der „gegenueberliegenden“ Seite. Das Script ist, wie man sehen kann, kein Voodoo. Aufwand entsteht, da die Variablen DB_TO_COPY gepflegt werden muessen. Die Anfangsidee „Les‘ doch einfach aus welche Datenbanken auf der anderen Seite sind“ war prima. Das haette man schnell mit einem ssh user@foo mysqlshow -u user -p hinbekommen. Das klappt aber nicht dauerhaft. Laueft der Job auf beiden Servern einmal, habe ich auf beiden Servern alle Datenbanken. Lasse ich den Job dann 12 Stunden spaeter auf foo noch mal laufen, wuerden alle Datenbanken von bar importiert und damit natuerlich auch die fuenf benoetigten Datenbanken auf foo mit einem alten Stand ueberschrieben.

Man koennte, um sich etwas mehr Automatismus zu erhalten, die Datenbanken als bak_* importieren und dann im Fehlerfall umbenennen. Die Idee hat fuer mich aber nicht so viel Charme, da ich beim Umschalten so wenig wie moeglich anfassen moechte.

Nicht zu vergessen ist natuerlich, dass es nur mit der Synchronisation von ein paar Daten und Datenbanken nicht getan ist. Im Ernstfall muss auch sichergestellt sein, dass die genutzten Anwendungen (Maildaemon, Webdaemon, etc.) auch auf der Backupseite verfuegbar sind. Und dann muss man natuerlich auch schauen, dass die Anwendung entsprechend konfiguriert ist. Einfach alle Webseiten kopieren und dann /etc/apache2/sites-enable zu vergessen ist ungeschickt.

Auch sollte nicht vergessen werden, dass die Rechte auf dem Backup gesetzt sind, bzw. noch zu setzen sind. So ist ein Import aller Datenbanken schon mal ein erster Schritt. Aber so lange die Anwendungen keine Rechte auf „ihre“ Datenbank haben bin ich noch nicht am Ziel.

Ja, machnmal waere es leichter einfach irgendwo einen „einfachen Server“ zu mieten. Aber wo bleibt da der Spass?

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Mir ist keine Migration bekannt, bei der es nicht irgendwelche Probleme gab. So auch ein Wechsel von einer Blogsoftware zu einer anderen. Da denkt man „Ach, einfach nur einen Import der Daten und gut“, aber so einfach ist es oft nicht. In vielen Faellen gibt es nicht mal einen gescheiten Importmechanismus. Da ist dann Handarbeit angesagt.

Beim Migrieren meines privaten Blogs von WordPress nach Serendipity (s9y) waren die Vorzeichen etwas besser, da s9y zumindest einen Importer mitbringt (~/include/admin/importers/wordcodess.inc.php). Aber wie oben geschrieben… Migration laueft nicht problemlos. Daher hier mal ein paar Punkte, die ich im Rahmen der Migration zu bewaeltigen hatte. Vorab der Hinweis, dass ein Backup auf jeden Fall Sinn macht. Einmal ein falscher Befehl in der falschen Tabelle und man faengt, im schlimmsten Falle, von vorne an. Ja, ich spreche aus Erfahrung 🙂

Um moeglichen Problemen mit Umlauten (ä, ö, ü) oder bestimmten Sonderzeichen (Halbgeviertstrich, Scharfes S) vorzubeugen macht es Sinn, diese vor dem Import anzupassen. Daher habe ich erst einmal ein Suchen/Ersetzen auf die Tabellen wp_comments und wp_posts gemacht. Hier einmal ein Beispiel fuer das Ersetzen von ä in den Beitraegen und Kommentaren.

UPDATE `wordcodess`.`wp_comments` SET `comment_content` = replace(`comment_content`,’ä‘,’ae‘);
UPDATE `wordcodess`.`wp_posts` SET `post_content` = replace(`post_content`,’ä‘,’ae‘);
…

Anschliessend habe ich noch, um keine unnoetigten Altlasten mitzunehmen, die Beitraege, die als post_type den Wert revision haben, geloescht. Das sind die Beitraege die sonst spaeter in s9y als Draft auftauchen.

DELETE FROM `wordcodess`.`wp_posts` WHERE `post_type`=’revision‘;

Bitte beachten, dass es auch Werte wie etwa attachment oder page gibt. Somit waere es nicht so prima alles was ungleich revision ist zu loeschen. Der s9y-Importer macht es so, dass er alle Eintraege die nicht den Wert publish haben, als isdraft == true importiert.

Nun habe ich mal – mutig, mutig – einen Import der Daten in sy9 gemacht und geschaut, was es noch zu bereinigen gibt. Zum einen waren das bei mir die Accounts. Diese werden im Rahmen des Imports mitgenommen und es werden auch die Spalten author sowie authorid mit den „alten“ Werten – bei mir ports und 4 – versehen. Ich wollte aber ramon mit der ID 1 haben.

UPDATE `sy9`.`s9y_entries` SET author=’ramon‘;
UPDATE `sy9`.`s9y_entries` SET authorid=1;

Ein weiterer Punkt auf meiner Liste war die Erstellung einer ordentlichen Kategorieliste. Dafuer habe ich erst einmal die entsprechenden Eintraege via TRUNCATE TABLE `s9y_entrycat`; (Welcher Beitrag ist wie kategorisiert) und TRUNCATE TABLE `s9y_category`; (Welche Kategorien gibt es) geleert und neue Kategorien eingepflegt.

INSERT INTO `kl_s9y_ramon`.`s9y_category` (`categoryid`, `category_name`, `category_icon`, \
`category_description`, `authorid`, `category_left`, `category_right`, `parentid`, \
`sort_order`, `hide_sub`) VALUES (NULL, ‚Adminstories‘, “, “, ‚0‘, ‚1‘, ‚2‘, ‚0‘, 0, 0), \
(NULL, ‚Alter Inhalt‘, “, “, ‚0‘, ‚3‘, ‚4‘, ‚0‘, 0, 0),
…

Das anschliessende kategorisieren musste dann, zumindest bei mir, von Hand erfolgen, da ich mir jeden Beitrag noch mal anschauen musste. Ansonsten koennte man auch etwas wie

INSERT INTO `s9y`.`s9y_entrycat` (`entryid`, `categoryid`) VALUES (‚2‘, ‚2‘);
INSERT INTO `s9y`.`s9y_entrycat` (`entryid`, `categoryid`) VALUES (‚3‘, ‚2‘);

verwenden. Damit wuerde dann der Beitrag mit der ID 2 und 3 der Kategorie mit der ID 2 zugewiesen.

Im Rahmen meiner Migration habe ich mehrfach einen Fehler gemacht, so dass ich den Datenimport auch jedesmal gemacht habe. Da ich nicht jedesmal eine neue Datenbank erstellen wollte habe ich mich darauf beschraenkt, vor jedem neuen Versuch, die fuer mich relevanten Tabellen zu leeren und meinen Benutzer anzulegen.

TRUNCATE TABLE `s9y_authors`;
INSERT INTO `lx_logbuch`.`serendipity_authors` (`realname`, `username`,`password`, \
`authorid`, `mail_comments`, `mail_trackbacks`, `email`,`userlevel`, `right_publish`, \
`hashtype`) VALUES (‚Ramon Kukla‘,’ramon‘, ‚abcdefghijklmnopqrstuvwxyz0123456789abcd‘, \
‚5‘, ‚1‘, ‚1‘, ‚ramon@kukla.info‘, ‚255‘, ‚1‘, ‚1‘);
TRUNCATE TABLE `s9y_category`;
TRUNCATE TABLE `s9y_comments`;
TRUNCATE TABLE `s9y_entries`;
TRUNCATE TABLE `s9y_entrycat`;
TRUNCATE TABLE `s9y_permalinks`;
TRUNCATE TABLE `s9y_references`;
TRUNCATE TABLE `s9y_refs`;

Alles in allem war die Migration, allerdings auch aus weiteren Gruenden, eine sehr zeitintensive Geschichte. Der Grund, warum ich nach einem Wechsel von s9y zu Wordcodess und nun wieder zu s9y zurueck bin, sind ueberschaubar. Ich fuehle mich bei s9y einfach wohler, der Support im Forum ist prima und es ist – nicht gemessen, aber mein subjektiver Eindruck – schneller als WordPress.