Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
dbcopy - inkrementelle Datenbankkopie
Möchte man die Datenbank sichern oder auf einem zweiten System zur Verfügung haben stößt man bei Verwendung von mysqldump auf Schwierigkeiten (Systemlast, Zeitprobleme des vzlogger) die mit dbcopy umgangen werden können.
Dbcopy ist Teil einer VZ-Standardinstallation und unter /var/www/volkszaehler.org/vendor/bin/ zu finden. Es hat sein eigenes Repository auf github. Die Kopie ist in der Standardinstallation unter /var/www/volkszaehler.org/vendor/andig/dbcopy/ abgelegt.
Für das kopieren der Daten ist eine zweite, verfügbare Datenbankapplikation Grundvoraussetzung. Sie muss SQL-Kompatibel sein. Am zuverlässigsten ist daher eine weitere MySQL-Installation die über Netzwerkwerk erreichbar ist, z.B. bei einem Webhoster.
Alternativ bieten sich aber auch die DB eines NAS (z.B. Maria-DB auf Synology) oder SQLite an. SQLite ist als Backuplösung besonders interessant weil die Datenbank in einer einzelnen Datei abgelegt wird die einfach kopiert (Voll-Backup) werden kann.
Installation
In der Standardinstallation ist dbcopy über php direkt nutzbar.
php /var/www/volkszaehler.org/vendor/bin/dbcopy backup
backup
durch copy
ersetzt.
Möchte man dbcopy von der Kommandozeile aus starten muss erst die Berechtigung gesetzt werden:
sudo chmod +x /var/www/volkszaehler.org/vendor/bin/dbcopy
Sollte dbcopy doch nicht auf dem System verfügbar sein kann das mit
git clone git://github.com/andig/dbcopy
nachgeholt werden. Um Einsatzbereitschaft herzustellen müssen die Abhängigkeiten aufgelöst werden
cd dbcopy sudo composer install
MySQL
Bei der MYSQL-Datenbankapplikaion muss eine Datenbank und ein Nutzer mit ausreichenden Rechten angelegt werden. Insbesondere ist darauf zu achten das der User Schreibrechte hat und auch von außerhalb zugreifen darf. Manche Webhoster lassen allerdings nur localhost-Zugriffe auf MySQL zu.
SQLite
Kann auch als zweite Datenbankapplikation auf dem selben System installiert werden.
sudo apt-get install sqlite3 php5-sqlite
Konfiguration
dbcopy.json
sondern dbcopy.yml
. Die Syntax ist anders, der Inhalt aber identisch.
Es empfiehlt sich nicht die Konfigurationsdatei /var/www/volkszaehler.org/misc/tool/dbcopy.json direkt zu ändern. Das kann bei späteren Updates der Middleware zu Problemen führen. Daher:
sudo cp /var/www/volkszaehler.org/etc/dbcopy.json /etc/dbcopy.json
Und
sudo nano /etc/dbcopy.json
Deshalb dbcopy mit dem Parameter -c aufrufen.
- dbcopy.json
{ "source": { "driver": "pdo_mysql", "host": "localhost", "user": "vz", "password": "demo", "dbname": "volkszaehler" }, "target": { "driver": "pdo_sqlite", "host": "localhost", "user": "root", "password": "raspberry", "dbname": "volkszaehler_backup", "path": "sqlite.db3" }, "tables": [ { "name": "entities", "mode": "copy" }, { "name": "properties", "mode": "copy" }, { "name": "entities_in_aggregator", "mode": "copy" }, { "name": "data", "mode": "pk" }, { "name": "aggregate", "mode": "skip" } ] }
In der Datei werden Quelle („source“) und kurz darunter Ziel („target“) festgelegt. Im folgenden sind die einzelnen Parameter erklärt:
„driver“: „pdo_mysql“,
Die Schnittstelle zwischen PHP und der Datenbank. Standardmäßig läuft der Volkszähler mit einer MySQL-Datenbank (pdo_mysql), in der Beispielkonfiguration ist eine SQLite-Datenbank als Ziel vorgesehen, dementsprechend ist eine andere Schnittstelle nötig (pdo_sqlite).
„host“: „localhost“,
Die Host- oder IP-Adresse des Rechners auf dem die Datenbank läuft. Standardmäßig ist es das selbes System, daher localhost.
„user“: „vz“
Benutzername der Datenbank, für SQLite nicht nötig.
„password“: „demo“
Passwort des Benutzers der Datenbank, für SQLite nicht nötig.
„dbname“: „volkszaehler“
Name der Datenbank, für SQLite nicht nötig.
„path“: „sqlite.db3“,
Name der Datei bei SQLite, für MySQL nicht nötig.
Unter „table“ wird definiert welche und wie die Tabellen der Datenbank gehandhabt werden.
„name“: „entities“
Die Bezeichnung der einzelnen Tabellen. In der Beispielkonfiguration sind bereits alle Tabellen einer Volkszähler-Datenbank aufgeführt.
„mode“: „copy“
Bedeutet die Tabelle in der Ziel-Datenbank wird geleert und aus der Quelle neu beschrieben. Ein derart kopierte Tabelle ist keine „echtes“ Backup!
„mode“: „pk“
Die Tabelle im Ziel wird mit neuen Datensätzen aus der Quelle ergänzt. Datensätze die in der Quelle gelöscht wurden bleiben im Ziel erhalten. Heißt aber auch das Änderungen an den Datensätzen nicht übernommen werden! Ist auf dem primären System vzcompress im Einsatz und auf dem sekundären System ebenfalls gewünscht, müsste das lokal wiederholt werden.
„mode“: „skip“
Datensätze der Tabelle werden nicht kopiert. Für Aggregationswerte ist es sinnvoller sie aus data neu zu generieren als die redundaten Daten nochmal zu speichern. Möchte man die Tabelle aggregate ebenfalls sichern „skip“ in „pk“ ändern.
Zieldatenbank erstellen
/var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.json
Daten kopieren
/var/www/volkszaehler.org/vendor/bin/dbcopy backup -c /etc/dbcopy.json
/var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.json
Erfolgreiche Kopie:
entities: copying 9 rows (overwrite) [============================] 100% 1 sec/1 sec 9 rows properties: copying 66 rows (overwrite) [============================] 100% 1 sec/1 sec 66 rows entities_in_aggregator: copying 7 rows (overwrite) [============================] 100% 1 sec/1 sec 7 rows data: copying 2258 rows (partial copy) [============================] 100% 40 secs/40 secs 2261 rows aggregate: skipping
Cronjob
Wenn die manuelle Kopie erfolgreich war kann ein cronjob eingerichtet werden. Z.B. täglich:
0 2 * * * /usr/bin/php /var/www/volkszaehler.org/vendor/bin/dbcopy backup -c /etc/dbcopy.json > /dev/null
0 2 * * * /usr/bin/php /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.json > /dev/null
Restore
Um eine Sicherung wiederherzustellen einfach eine Konfiguration anlegen bei der Ziel und Quelle vertauscht sind. Das übrige Vorgehen ist identisch.