Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nosql:administration_oracle_nosql_db_11gr2 [2013/06/18 14:16] – [Backup des Store] gpipperr
+++ nosql:administration_oracle_nosql_db_11gr2 [2014/06/21 19:36] (aktuell) – [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  ======
+====== Administration der Oracle NoSQL Database 11gR2 - 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.
@@ Zeile 14: / Zeile 18: @@
 ==== 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 Replicas) ein Snapshot der Daten erzeugt.
+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ürde auch jeweilige Master auf den Knoten ausreichen.
+    * im Prinzip würden auch jeweilige Master auf den Knoten ausreichen.
   * Snapshot löschen
@@ Zeile 47: / Zeile 51: @@
 </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 initalisiert werden.
+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 kompleten Node wieder neu anzulegen:
+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
@@ Zeile 62: / Zeile 66: @@
 ===== Restore eines Stores =====
-Für das Restore stehen zwei Möglichkeiten zur Verfügung, den Snapshot direkt wieder einspielen oder die Daten erneut laden.
+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 Topology hat sich nicht verändert d.h. alle Knoten sind unverändert konfiguriert und online!
+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!
@@ Zeile 97: / Zeile 101: @@
-Ein erster Test war allerdings nicht nicht so recht erfolgreich, der Store ließ sich so nicht wirklich wieder zurüksetzen, evlt. nützlich bei größeren Datenmengen um einen Master Teil wieder herzustellen?
+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ück setzen ===
+=== Test 2 - gesamten Store zurücksetzen ===
 Ablauf:
@@ Zeile 106: / Zeile 110: @@
   * Daten im Store "ausversehen .-)" gelöscht
   * Store komplett gestoppt
-  * alle Recovery Verzeichniss auf allen Knoten auf Snapshot verlinkt
+  * 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 Verzeichniss gelinkt um  beim Neustart der Knoten die alten Daten wieder einzulesen.
+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.
@@ Zeile 162: / Zeile 166: @@
 cd $KVROOT/GPIDB/sn1/rg1-rn1
 unlink recovery
-#usw.  (darauf achten das kein / am ende steht .-) !!!
+#usw.  (darauf achten das beim unlink  Befehlt kein / am Ende steht .-) !!!
 </code>
-Mit diesen Ablauf ließ sich der Store wieder komplet auf den Snapshot Punkt zurücksetzen.
+Mit diesem Ablauf ließ sich der Store wieder komplett auf den Snapshot Punkt zurücksetzen.
 **!!Achtung!!** \\
@@ Zeile 175: / Zeile 179: @@
 siehe Doku : http://docs.oracle.com/cd/NOSQL/html/AdminGuide/recovery.html#restoredirect
-==== Daten wieder einspielen ====
+==== 3. Daten wieder einspielen ====
 Mit dem Lade Programm "oracle.kv.util.Load" kann ein Snapshot auch wieder in die Datenbank geladen werden.