Erweiterte Replikation

Sie können sich über die Konzepte und Tasks der erweiterten Replikation informieren, u. a. zum Beispiel über die in der folgenden Liste:

Replikationdatenbank pflegen
Replikationen planen und überwachen
Authentifizierung während der Replikation

Möglicherweise ist es für Sie auch hilfreich, sich die Einzelheiten des zugrunde liegenden Replikationsprotokolls noch einmal anzusehen und die API-Referenzdokumentation durchzugehen.

Pflege der Replikationsdatenbank

Eine Replikationsdatenbank muss wie jede andere Datenbank überwacht werden. Ohne regelmäßige Pflege der Datenbank könnten sich ungültige Dokumente ansammeln, die durch Unterbrechungen des Replikationsprozesses verursacht wurden. Eine hohe Anzahl ungültiger Dokumente kann zu einer übermäßigen Belastung auf Ihrem Cluster führen, wenn der Replikatorprozess durch IBM® Cloudant® for IBM Cloud®-Operationen erneut gestartet wird.

Entfernen Sie zur Pflege einer Replikationsdatenbank alte Dokumente. Sie können alte Dokumente entfernen, indem Sie ihr Alter bestimmen und sie löschen, wenn sie nicht mehr benötigt werden.

Replikationsscheduler

Der neue IBM Cloudant Replication Scheduler bietet im Vergleich zu dem früheren IBM Cloudant-Replikationmechanismus eine Reihe von Verbesserungen und Erweiterungen.

Insbesondere ist die Netznutzung während der Replikation effizienter. Der Scheduler berücksichtigt die aktuelle Auslastung für einzelne Datenbankknoten in einem Cluster, wenn er die Zuteilung von Replikationstasks festlegt.

Darüber hinaus wird der Zustand einer Replikation jetzt differenzierter dargestellt und besteht aus sieben unterschiedlichen Statuswerten:

initializing - (Wird initialisiert) Die Replikation wurde dem Scheduler hinzugefügt, wurde jedoch noch nicht abschließend initialisiert oder zur Ausführung geplant. Der Status wird angezeigt, wenn ein neues oder aktualisiertes Replikationsdokument in der Datenbank _replicator gespeichert wird.
error - (Fehler) Die Replikation kann nicht in einen Job umgewandelt werden. Dieser Fehler kann auf verschiedene Weise verursacht werden. Beispiel: Die Replikation muss gefiltert werden, jedoch war es nicht möglich, den Filtercode aus der Quellendatenbank abzurufen.
pending - (Anstehend) Der Replikationsjob ist zur Ausführung geplant, wird jedoch noch nicht ausgeführt.
running - (Aktiv) Der Replikationsjob wird zurzeit ausgeführt.
crashing - (Absturz) Es ist ein temporärer Fehler aufgetreten, der sich auf den Replikationsjob auswirkt. Der Job wird automatisch später wiederholt.
completed - (Abgeschlossen) Der Replikationsjob ist abgeschlossen. Dieser Status gilt nicht für fortlaufende Replikationen.
failed - (Fehlgeschlagen) Der Replikationsjob ist fehlgeschlagen. Der Fehler ist permanent. Dieser Status bedeutet, dass kein weiterer Versuch zur Replikation mit dieser Replikationstask unternommen wird. Der Fehler kann auf verschiedene Weise verursacht werden, zum Beispiel wenn die URL der Quelle oder des Ziels nicht gültig ist.

Die Übergänge zwischen diesen Statuswerten werden im folgenden Diagramm dargestellt:

Die Übergänge zwischen den Zuständen sind , , und . — Zustände des Replikationsplaners

Der Scheduler führt zwei neue Endpunkte ein:

Über diese Endpunkte können Sie den Replikationsstatus schneller und einfacher verwalten und ermitteln.

Der typische Prozess zur Verwendung des Replikationsschedulers für die Verwaltung und Überwachung von Replikationen sieht wie folgt aus:

Erstellen Sie ein Replikationsdokument, das die erforderliche Replikation beschreibt, und speichern Sie das Dokument in der Replikationsdatenbank.
Überwachen Sie den Status der Replikation über den Endpunkt /_scheduler/docs.

Authentifizierung während der Replikation

In jeder Produktionsanwendung ist die Sicherheit der Quellen- und Zieldatenbanken von entscheidender Bedeutung. Zur fortgesetzten Ausführung der Replikation ist eine Authentifizierung erforderlich, um auf die Datenbanken zuzugreifen. Replikations-Checkpoints sind standardmäßig aktiviert, was bedeutet, dass für die Replikation der Quelldatenbank Schreibzugriff erforderlich ist.

Zur Aktivierung der Authentifizierung während der Replikation geben Sie einen Benutzernamen und das zugehörige Kennwort in der Datenbank-URL mit an. Der Replikationsprozess verwendet die angegebenen Werte für die HTTP-Basisauthentifizierung.

Beispiel für die Angabe der Werte für Benutzername und Kennwort für den Zugriff auf Quellen- und Zieldatenbanken während der Replikation:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  }
}

Für IAM-Anmeldeinformationen verwenden Sie das folgende Beispiel zur Authentifizierung mit einem IAM-API-Schlüssel:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  }
}

Gefilterte Replikation

In manchen Fällen ist es nicht wünschenswert, alle Dokumente von der Quelle auf das Ziel zu replizieren. Zur Auswahl der zu übertragenden Dokumente können Sie eine oder mehrere Filterfunktionen in einem Entwurfsdokument auf der Quelle angeben. Anschließend können Sie den Replikator anweisen, diese Filterfunktionen zu verwenden.

Die Filterung von Dokumenten während der Replikation ähnelt dem Prozess der Filterung des Änderungsdatenfeeds (_changes).

Eine Filterfunktion akzeptiert zwei Argumente:

Das zu replizierende Dokument
Die Replikationsanforderung

Eine Filterfunktion gibt den Wert true oder false zurück. Wenn das Ergebnis den Wert 'true' hat, wird das Dokument repliziert.

Zur Einrichtung der Filterung verwenden Sie nach Möglichkeit das Feld selector. Wenn Sie das Feld selector verwenden, können Sie einen Filter angeben, ohne die gesamte Datenbank replizieren zu müssen. Diese Methode macht die Filterung schneller und verursacht weniger Arbeitslast für IBM Cloudant. Weitere Informationen finden Sie in der Dokumentation zum Feld „ selector “.

Beispiel für eine Filterfunktion:

function(doc, req) {
	return !!(doc.type && doc.type == "foo");
}

Filter werden unter dem Schlüssel filters der höchsten Ebene im Entwurfsdokument gespeichert.

Beispiel für das Speichern einer Filterfunktion in einem Entwurfsdokument:

{
	"_id": "_design/myddoc",
	"filters": {
		"myfilter": "function goes here"
	}
}

Eine gefilterte Replikation wird durch eine JSON-Anweisung gestartet, die die folgenden Elemente angibt:

Die Quellendatenbank
Die Zieldatenbank
Den Namen des Filters, der unter dem Schlüssel filters im Entwurfsdokument gespeichert ist

JSON-Beispiel für das Starten einer gefilterten Replikation:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter"
}

Argumente können durch die Angabe von Schlüssel:Wert-Paaren im Feld query_params des Aufrufs an die Filterfunktion übergeben werden.

JSON-Beispiel für das Starten einer gefilterten Replikation mit Parameterangabe:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter",
  "query_params": {
    "key": "value"
  }
}

Die Option selector bietet Leistungsvorteile im Vergleich zur Verwendung der Option filter. Verwenden Sie nach Möglichkeit die Option selector. Weitere Informationen finden Sie in der selector Dokumentation.

Beseitigen von Konflikten, die die Replikation verwenden

Verwenden Sie die Option winning_revs_only: true, um nur Gewinnerversionen von Dokumenten zu replizieren. Diese Revisionen sind die Revisionen, die vom GET $ACCOUNT/$DATABASE/$DOCID-API-Endpunkt standardmäßig zurückgegeben werden oder in der _changes-Feed mit den Standardparametern.

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"winning_revs_only": true
}

Bei der Replikation mit diesem Modus werden in Konflikt stehende Revisionen verworfen. Daher kann es eine Möglichkeit sein, Konflikte durch Replikation zu entfernen.

Replikations-IDs und Checkpoint-IDs, die von winning_revs_only: true Diese Replikationen unterscheiden sich von den standardmäßig generierten Replikationen, sodass es möglich ist, zunächst die erfolgreichen Revisionen zu replizieren und anschließend die übrigen Revisionen mit einem regulären Replikationsauftrag nachzuholen.

Die Option winning_revs_only: true kann mit Filtern oder anderen Optionen wie continuous: true oder create_target: true kombiniert werden.

Replikation benannter Dokumente

Es gibt Fälle, in denen Dokumente nicht repliziert werden sollen. Für einfache Replikationen muss keine Filterfunktion geschrieben werden. Stattdessen fügen Sie zum Replizieren bestimmter Dokumente eine Liste von Schlüsseln als Array im Feld doc_ids hinzu.

Beispiel für die Replikation nur bestimmter Dokumente:

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://127.0.0.1:5984/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"doc_ids": ["foo", "bar", "baz"]
}

Eigenschaft `user_ctx` und Delegierungen

Replikationsdokumente können eine angepasste Eigenschaft user_ctx enthalten. Diese Eigenschaft definiert den Benutzerkontext, unter dem eine Replikation ausgeführt wird.

Bei einer älteren Methode zur Auslösung von Replikationen durch das Senden einer POST-Anforderung an den Endpunkt /_replicate/ war die Eigenschaft user_ctx nicht erforderlich. Dies hat den Grund, dass im Moment der Auslösung der Replikation alle erforderlichen Informationen zu dem authentifizierten Benutzer verfügbar sind.

Im Unterschied dazu ist die Replikatordatenbank eine reguläre Datenbank. Die Informationen über den authentifizierten Benutzer liegen erst dann vor, wenn das Replikationsdokument in die Datenbank geschrieben wird. Das heißt mit anderen Worten, dass sich die Implementierung der Replikatordatenbank ähnlich wie eine Anwendung für die Verarbeitung von Änderungsdatenfeeds (_changes) mit der Einstellung ?include_docs=true verhält.

Für die Replikation bedeutet dieser Implementierungsunterschied, dass für Nicht-Admin-Benutzer im Replikationsdokument eine Eigenschaft „ user_ctx “ definiert werden muss, die den Namen des Benutzers und eine Teilmenge seiner Rollen enthält. Diese Anforderung wird von einer Validierungsfunktion berücksichtigt, die im Standardentwurfsdokument der Replikatordatenbank enthalten ist. Die Funktion validiert jede Dokumentaktualisierung. Diese Validierungsfunktion stellt außerdem sicher, dass ein Benutzer ohne Administratorrechte in der Eigenschaft „ user_ctx “ keinen Benutzernamen festlegen kann, der nicht dem korrekten Benutzernamen entspricht. Dasselbe Prinzip gilt auch für Rollen.

Beispiel für ein delegiertes Replikationsdokument:

{
	"_id": "my_rep",
	"source": {
	  "url": "https://$SERVER.com:5984/foo",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/bar",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"continuous":  true,
	"user_ctx": {
		"name": "joe",
		"roles": ["erlanger", "researcher"]
	}
}

Für Administratoren ist die Eigenschaft user_ctx optional. Wenn die Eigenschaft fehlt, wird standardmäßig ein Benutzerkontext mit dem Namen null und einer leeren Liste von Rollen verwendet.

Die leere Rollenliste bedeutet, dass Entwurfsdokumente während der Replikation nicht in lokale Ziele geschrieben werden. Wenn Sie Entwurfsdokumente in lokale Ziele schreiben möchten, muss ein Benutzerkontext mit der Rolle _admin explizit festgelegt werden.

Von Administratoren kann die Eigenschaft user_ctx darüber hinaus dazu verwendet werden, eine Replikation für einen anderen Benutzer auszulösen. Dieser Benutzerkontext wird an Validierungsfunktionen der lokalen Zieldatenbankdokumente übergeben.

Die Eigenschaft user_ctx gilt nur für lokale Endpunkte.

Zusammenfassend lässt sich sagen, dass die Eigenschaft „ user_ctx “ für Administratoren optional ist. Für normale Benutzer (ohne Administratorberechtigung) ist dies obligatorisch. Wenn die Rolleneigenschaft von user_ctx fehlt, wird standardmäßig eine leere Liste [ ] verwendet.

Für eine Replikation können verschiedene leistungsbezogene Optionen festgelegt werden, indem sie in das Replikationsdokument eingefügt werden.

use_bulk_get: Wird auf true gesetzt, um die Leistung von Replikationsjobs zu verbessern. Eine Replikation ruft Dokumente in Stapeln aus der Quelle ab. Die erhöhte Replikationsrate kann die Kapazität der Quell- und Zielkonten schneller aufbrauchen und dazu führen, dass bei gleichzeitigen Nicht-Replikationsanforderungen auf diesen Konten mehr 429 HTTP Fehler auftreten.
connection_timeout: Die maximale Inaktivitätsdauer für eine Verbindung in Millisekunden. Wenn eine Verbindung über diesen Zeitraum inaktiv ist, wird die aktuelle Anforderung wiederholt. Standardwert: 30000 Millisekunden (30 Sekunden).
http_connections: Die maximale Anzahl der HTTP-Verbindungen pro Replikation. Für Push-Replikationen beträgt die effektive Anzahl der verwendeten HTTP-Verbindungen min(worker_processes + 1, http_connections). Für Pull-Replikationen entspricht die effektive Anzahl der verwendeten Verbindungen dem Wert dieses Parameters. Standardwert: 20.
retries_per_request: Die maximale Anzahl der Wiederholungen pro Anforderung. Vor einer Wiederholung wartet der Replikator eine kurze Zeit, bevor er die Anforderung wiederholt. Dieser Zeitraum verdoppelt sich von einer Wiederholung zur nächsten, überschreitet jedoch nie den Zeitraum von 5 Minuten. Der Minimalwert vor der ersten Wiederholung ist 0,25 Sekunden. Standardwert: 10 Wiederholungen.
socket_options: Eine Liste der Optionen, die an die Anschlussbuchsen übergeben werden sollen. Die verfügbaren Optionen finden Sie in der Dokumentation zur Erlang-Funktion „ setopts “ des Moduls „ inet “. Standardwert: [{keepalive, true},{nodelay, false}].
worker_batch_size: Von Workerprozessen werden die Stapel der Replikationstasks ausgeführt, wobei die Stapelgröße durch diesen Parameter definiert wird. Die Größe entspricht der Anzahl von Datenfeedzeilen für _changes. Größere Werte für die Stapelgröße können zu besserer Leistung führen. Kleinere Werte bedeuten, dass häufiger Prüfpunktverfahren durchgeführt werden. Standardwert: 500.
worker_processes: Die Anzahl der Prozesse, die der Replikator in jeder Replikationstask zum Übertragen von Dokumenten von der Quellen- zur Zieldatenbank verwendet. Höhere Werte können wegen der höheren Parallelität von Netz- und Platten-E/A-Aktivitäten möglicherweise zu einem besseren Durchsatz führen, jedoch geht diese Verbesserung auf Kosten eines höheren Hauptspeicherbedarfs und potenziell eines höheren CPU-Zeitbedarfs. Standardwert: 4.

Beispiel für Leistungsoptionen in einem Replikationsdokument:

{
	"source": {
	  "url": "https://example.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT1",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT2",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"connection_timeout": 60000,
	"retries_per_request": 20,
	"http_connections": 30
}

Effekt großer Anhänge

Eine hohe Anzahl von Anhängen in Dokumenten kann einen negativen Effekt auf die Replikationsleistung haben.

Weitere Informationen zum Effekt von Anhängen auf die Replikationsleistung finden Sie unter Leistungsaspekte.

Endpunkt `/_replicate` vermeiden

Verwenden Sie den Scheduler _replicator anstelle des Endpunkts /_replicate.

Wenn während der Replikation ein Problem auftritt, wie zum Beispiel eine Blockierung, eine Zeitlimitüberschreitung oder ein Absturz einer Anwendung, wird eine Replikation, die in der Datenbank _replicator definiert ist, durch das System automatisch erneut gestartet. Wenn Sie jedoch eine Replikation durch Senden einer Anforderung an den Endpunkt /_replicate definieren, kann sie im Falle eines Problems vom System nicht erneut gestartet werden, weil die Replikationsanforderung nicht permanent gespeichert wird. Replikationen, die in der Datenbank _replicator definiert werden, lassen sich leichter überwachen.

Erweiterte Replikation

Erweiterte Replikation

Pflege der Replikationsdatenbank

Replikationsscheduler

Authentifizierung während der Replikation

Gefilterte Replikation

Beseitigen von Konflikten, die die Replikation verwenden

Replikation benannter Dokumente

Eigenschaft user_ctx und Delegierungen

Leistungsbezogene Optionen

Effekt großer Anhänge

Endpunkt /_replicate vermeiden

Eigenschaft `user_ctx` und Delegierungen

Endpunkt `/_replicate` vermeiden