Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nosql:administration_oracle_nosql_db_11gr2 [2013/06/16 21:55] – [Daten wieder einspielen] gpipperr
+++ nosql:administration_oracle_nosql_db_11gr2 [2014/06/21 19:35] – [Administration der Oracle NoSQL Database 11gR2 (1) - Backup und Recovery] gpipperr
@@ Zeile 1: / Zeile 1: @@
+====== Administration der Oracle NoSQL Database 11gR2 (1) - Backup und Recovery  ======
+Oft wird in der NoSQL Welt das Thema Backup sehr stiefmütterlich behandelt, mit der Begründung „bei genügend Server Knoten kann ja bei einem Ausfall nichts passieren“, das Problem mit logischen Fehlern wird kaum beachtet. Mit der Oracle NoSQL aber lassen sich Snapshots des gesamten Stores erzeugen. Auf Basis dieser über alle Knoten konsistenten Snapshots kann ein echtes Backup Konzept realisierbar wird. Die Daten in einem Snapshot können auch in einen anderen Store wieder importiert werden, zum Bespiel um eine Testumgebung aus den Produktionsdaten aufzusetzen.
+Die Verwaltung der Umgebung erfolgt über das Kommandozeilen Werkzeug.
+Aufruf mit:
+<code bash>
+java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host $HOSTNAME
+</code>
+==== Backup des Store ====
+Mit Hilfe des Snapshot Kommando (snapshot create -name <snapshot name>) wird über den gesamten Store (d.h. über alle Knoten und alle Master und Replikas) ein Snapshot der Daten erzeugt.
+Ablauf einer Sicherung:
+  * Snapshot erzeugen
+  * Daten von $KVROOT/<store_mame>/<SN>/<resource>/snapshots/<snapshot_name>/files sichern auf ALLEN Knoten sichern
+    * im Prinzip würden auch jeweilige Master auf den Knoten ausreichen.
+  * Snapshot löschen
+Beispiel:
+<code bash>
+# Anlegen
+kv-> snapshot create -name freitag_14_06_2013
+Created snapshot named 130614-123305-freitag_14_06_2013
+# Was für Snapshots existieren
+kv-> show snapshot
+#Löschen
+kv-> snapshot remove -name 130614-123305-freitag_14_06_2013
+Removed snapshot 130614-123305-freitag_14_06_2013
+</code>
+=== Konfiguration eines SN sichern ===
+Fällt die Hardware eines SN komplett aus, ist es hilfreich eine Sicherungskopie der SN Konfiguration des Nodes  zuvor erstellt zu haben.
+Befehl:
+<code bash>
+java -jar KVHOME/lib/kvstore.jar generateconfig -host $HOSTNAME -port 5000 -sn sn1 -target ~/sn1.config
+</code>
+Mit der erzeugen Datei, in unseren Beispiel "sn1.config.zip", kann eine neuer Node mit gleicher IP Adresse, gleichen Namen und gleicher Storage Konfiguration wieder neu initialisiert werden.
+Ablauf um einen kompletten Node wieder neu anzulegen:
+  * Neuen Host gleich wie alten Host konfigurieren (IP/Name/Storage/Gruppen/User/Recht etc.)
+  * Auf den neuen Host $KVROOT anlegen
+  * Zip File aus dem Config Backup auf den neuen host in $KVROOT auspacken
+  * SN neu starten
+===== Restore eines Stores =====
+Für den Restore stehen zwei Möglichkeiten zur Verfügung, den Snapshot direkt wieder einspielen oder die Daten erneut laden.
+====Snapshot direkt wieder einspielen====
+Die Topologie hat sich nicht verändert d.h. alle Knoten sind unverändert konfiguriert und online!
+Nur dann lassen die direkt die Snapshots wieder einspielen!
+Ablauf:
+  * Verzeichnis restore anlegen in $KVROOT/<store_name>/<sn node>/<replikat_nr>-<sn node>/recovery
+  * Snapshot in das Recovery Verzeichnis verschieben auf dem der passende Storage Node läuft
+  * Storage Node neu starten, beim Start erkennt der Node die Snapshot Dateien zum Recovery
+=== Test 1 - Restore eines Nodes ===
+Beispiel:
+<code bash>
+# Verzeichnis anlegen
+mkdir $KVROOT/GPIDB/sn1/rg1-rn1/recovery
+#snapshot daten dahin verschieben
+mv  $KVROOT/GPIDB/sn1/rg1-rn1/snapshost/130614-142350-freitag/ $KVROOT/GPIDB/sn1/rg1-rn1/recovery
+# Service stoppen
+java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT
+# Starten
+nohup java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &
+</code>
+Ein erster Test war allerdings nicht so recht erfolgreich, der Store ließ sich so nicht wirklich wieder zurücksetzen, evtl. nützlich bei größeren Datenmengen um einen Master Teil wieder herzustellen?
+=== Test 2 - gesamten Store zurücksetzen ===
+Ablauf:
+  * Snapshot angelegt
+  * Daten im Store "ausversehen .-)" gelöscht
+  * Store komplett gestoppt
+  * alle Recovery Verzeichnisse auf allen Knoten auf Snapshot verlinkt
+  * Store wieder gestartet
+Im zweiten Test wird auf allen Knoten in den SN Verzeichnissen recovery auf das snapshot Verzeichnis gelinkt um  beim Neustart der Knoten die alten Daten wieder einzulesen.
+<code bash>
+# Admin Konsole starten
+java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host $HOSTNAME
+# Snapshot anlegen
+kv-> snapshot create -name sonntag
+Created snapshot named 130616-183718-sonntag on all 10 nodes
+# Sequence Nummer aus Ping merken:
+java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldb01
+#wie
+        Rep Node [rg1-rn3]      Status: RUNNING,REPLICA at sequence number: 1,612,835 haPort: 5010
+        Rep Node [rg2-rn3]      Status: RUNNING,REPLICA at sequence number: 1,620,315 haPort: 5011
+        Rep Node [rg3-rn3]      Status: RUNNING,MASTER  at sequence number: 1,619,967 haPort: 5012
+# Daten über Testprogramm löschen
+# Auf allen Knoten Store stoppen
+java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT
+# Auf allen Knoten!!
+# wie hier auf 1!
+cd $KVROOT/GPIDB/sn1/rg1-rn1
+ln -s snapshots/ recovery
+cd $KVROOT/GPIDB/sn1/rg2-rn1
+ln -s snapshots/ recovery
+cd $KVROOT/GPIDB/sn1/rg3-rn1
+ln -s snapshots/ recovery
+# Auf allen Knoten die Dienste neu starten
+nohup java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &
+# Warten bis Store wieder online
+java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldb01
+# Sequence Nummer sind nun zurück gesetzt:
+        Rep Node [rg1-rn3]      Status: RUNNING,REPLICA at sequence number: 1,609,571 haPort: 5010
+        Rep Node [rg2-rn3]      Status: RUNNING,REPLICA at sequence number: 1,616,853 haPort: 5011
+        Rep Node [rg3-rn3]      Status: RUNNING,MASTER at sequence number: 1,616,701 haPort: 5012
+# Anzahl der Daten im Store mit Testprogramm prüfen:
+# > Daten sind wieder da!
+# alle Recovery Links wieder entfernen
+cd $KVROOT/GPIDB/sn1/rg1-rn1
+unlink recovery
+#usw.  (darauf achten das beim unlink  Befehlt kein / am Ende steht .-) !!!
+</code>
+Mit diesem Ablauf ließ sich der Store wieder komplett auf den Snapshot Punkt zurücksetzen.
+**!!Achtung!!** \\
+!!Der Snapshot wird mit dieser Methode automatisch gelöscht!!
+=== Quelle ===
+siehe Doku : http://docs.oracle.com/cd/NOSQL/html/AdminGuide/recovery.html#restoredirect
+==== 3. Daten wieder einspielen ====
+Mit dem Lade Programm "oracle.kv.util.Load" kann ein Snapshot auch wieder in die Datenbank geladen werden.
+Verwendung:
+<code>
+java -jar KVHOME/lib/kvstore.jar load
+     -source <backupDir>
+     -store <storeName>
+     -host <hostname>
+     -port <port>
+     [-status <pathToFile>]
+     [-verbose]
+</code>
+Parameter:
+  *  -source <backupDir> Verzeichnis mit dem Snapshot
+  *  -store <storeName> Name des Stores
+  *  -host <hostname> Node für das Einlesen
+  *  -port <port> Port des SN auf dem Node
+  *  -status <pathToFile> Status File anlegen, mit Hilfe des Status Files kann bei einem Fehler wieder an gesetzt werden
+Beispiel:
+<code bash>
+java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg1-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000
+Load succeeded, wrote 2818 records
+java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg2-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000
+Load succeeded, wrote 2902 records
+java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg3-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000
+Load succeeded, wrote 2780 records
+</code>
+Nach dem laden ALLER Snapshots der drei SN sind ALLE Daten wieder da. \\
+Alle Daten werden geladen und für existierende Schlüssel die Values überschrieben.
+=== Quelle ===
+http://docs.oracle.com/cd/NOSQL/html/AdminGuide/recovery.html#usingload