Steuert die Rolle des Servers, mit dem eine Verbindung letztendlich hergestellt wird. Wird in Hochverfügbarkeitskonfigurationen, Scale-Out-Konfigurationen mit Schreibschutz und Cloud-Konfigurationen verwendet. Je nach Einstellung wird die Verbindung möglicherweise auf einen anderen Server umgeleitet, einschließlich Lastverteilung.
Scale-Out mit Schreibschutz und Datenbankspiegelung erfordern jeweils eine getrennte Lizenz. Siehe Getrennt lizenzierbare Komponenten.
{ NodeType | NODE }={ DIRECT | PRIMARY | MIRROR | COPY | READONLY}
Nur Netzwerkserver
DIRECT Dies ist die Standardeinstellung beim Verbinden mit einem Nicht-Cloud-Datenbankserver.
Wenn der NodeType Verbindungsparameter auf DIRECT eingestellt ist, akzeptiert der Datenbankserver die Verbindung, ohne eine Lastverteilung oder Weiterleitung auszuführen.
PRIMARY Dies ist die Standardeinstellung beim Verbinden mit einem Cloud-Server.
Wenn der NodeType-Verbindungsparameter auf PRIMARY eingestellt ist und Sie eine Verbindung zum Primärserver hergestellt haben, wird die Verbindung akzeptiert. Wenn Sie sich mit einem Nicht-Primärserver verbunden haben (z.B. mit einem Spiegelserver, einem Kopieknoten oder einem beliebigen anderen Cloud-Datenbankserver), leitet der Datenbankserver die Verbindung zum Primärserver um.
Geben Sie beim Verbinden mit einem Cloud-Server mit diesem NodeType-Wert nicht den ServerName-Verbindungsparameter an.
COPY Wenn der NodeType-Verbindungsparameter auf COPY eingestellt ist, führt der Datenbankserver die Lastverteilung aus und wählt einen Kopieknoten. In der Cloud wird der Kopieknoten zufällig ausgewählt. In einem nicht Cloud-basierten Scale-Out-System mit Schreibschutz überprüft der Datenbankserver die Kopieknoten in seinem eigenen Zweig (einschließlich seiner selbst, wenn er nicht der Stammknoten ist) und wählt den Kopieknoten mit der geringsten Last. Wenn der Datenbankserver sich nicht selbst auswählt, leitet er den Client zum ausgewählten Datenbankserver um.
Geben Sie beim Verbinden mit einem Cloud-Server mit diesem NodeType-Wert nicht den ServerName-Verbindungsparameter an.
MIRROR Wenn der NodeType-Verbindungsparameter auf MIRROR eingestellt ist und Sie sich mit dem Spiegelserver verbunden haben, wird die Verbindung akzeptiert. Wenn Sie sich mit einem Nicht-Spiegelserver verbunden haben, leitet der Datenbankserver die Verbindung zum Spiegelserver um.
Geben Sie beim Verbinden mit einem Cloud-Server mit diesem NodeType-Wert nicht den ServerName-Verbindungsparameter an.
READONLY Wenn der NodeType-Verbindungsparameter auf READONLY eingestellt, werden Sie mit einem beliebigen schreibgeschützten Server verbunden, entweder mit einem Kopieknoten oder mit dem Spiegelserver. Wenn es keine Kopieknoten gibt, ist dies gleichwertig mit der Einstellung MIRROR. Wenn es Kopieknoten gibt, ist dies gleichwertig mit der Einstellung COPY.
Geben Sie beim Verbinden mit einem Cloud-Server mit diesem NodeType-Wert nicht den ServerName-Verbindungsparameter an.
DIRECT (Nicht-Cloud-Datenbankserver)
PRIMARY (Cloud-Datenbankserver)
Dieser Verbindungsparameter wird von Clientanwendungen verwendet, um die Rolle des Servers zu steuern, mit dem eine Verbindung hergestellt werden soll, sowie die Lastverteilung zwischen Datenbankservern durchzuführen, die an Scale-Out mit Schreibschutz beteiligt sind. Clients geben diesen Verbindungsparameter als Hinweis darauf an, mit welchem Datenbankservertyp eine Verbindung hergestellt werden soll. Der Datenbankserver, mit dem der Client sich zunächst verbindet, bestimmt, welcher Datenbankserver die Verbindung verwalten soll, und leitet die Verbindung gegebenenfalls zum entsprechenden Datenbankserver um, indem er die Adresse dieses Datenbankservers zurückgibt. Der Client wird automatisch vom ursprünglichen Datenbankserver getrennt und verbindet sich dann mit dem angegebenen Datenbankserver.
Verwenden von NodeType mit Nicht-Cloud-Datenbankservern Wenn Sie COPY angeben, findet die Lastverteilung auf dem Zweig statt, der den Datenbankserver enthält, mit dem sich der Client zunächst verbindet. Ein Zweig besteht aus diesem Datenbankserver und allen seinen untergeordneten Objekten. Diese Funktion kann nützlich sein, um eine Lastverteilung zwischen Servern an geografisch getrennten Standorten durchzuführen.
Wenn eine Clientverbindung an einen anderen Datenbankserver umgeleitet wird, stimmen der im Verbindungsparameter ServerName (Server) und der in der Datenbankservereigenschaft Name angegebene Wert nicht miteinander überein. Siehe Name-Servereigenschaft.
Wenn NodeType angegeben ist, stellt die Anwendung normalerweise eine Verbindung mit dem Stammknoten her, und dieser Datenbankserver entscheidet dann darüber, welcher Kopieknoten am wenigsten stark ausgelastet ist. Die Verbindung wird dann an diesen Kopieknoten umgeleitet. Wenn die Anwendung innerhalb eines kurzen Zeitraums mehrere Verbindungen dieser Art erstellt und löscht, wird die Verbindung gepoolt, und der Stammknoten wird nicht gefragt, welcher Kopieserver verwendet werden soll. Die Verwendung von Verbindungspooling verringert die Auslastung des Stammknotens, hat jedoch möglicherweise nicht das erwartete Verhalten zur Folge. Die Anwendung kann angeben, dass ihre Verbindungen nicht gepoolt werden können, und damit sicherstellen, dass der Stammserver bei jeder Verbindung festlegt, mit welchem Kopieknoten diese erfolgen soll.
Wenn Sie diesen Parameter zum Umleiten von Verbindungen verwenden, die Kerberos-Authentifizierung oder integrierte Logins verwenden, müssen alle Datenbankserver in der Scale-Out-Struktur wie folgt konfiguriert werden:
Integrierte Logins Alle Datenbankserver in der Scale-Out-Struktur müssen ein Teil derselben Windows-Benutzergruppe sein oder so konfiguriert werden, dass dieselben Windows-Benutzer auf sie zugreifen können.
Kerberos-Authentifizierung Bei allen Datenbankservern in der Scale-Out-Struktur muss die Kerberos-Authentifizierung aktiviert sein. Der Kerberos-Serverprinzipal für alle Server in der Scale-Out-Struktur muss denselben Realm haben.
Der Primär- und der Spiegelserver befinden sich in Waterloo, Ontario. Für in Japan ausgeführte Clients soll beispielsweise eine Gruppe von Kopieknoten in Japan eingerichtet werden, um die Verarbeitungszeit für die Herstellung von Verbindungen zu verringern. Wenn ein Zweig der Kopieknoten in Japan dem Stammknoten direkt untergeordnet wäre, könnten weitere untergeordnete Knoten unterhalb des Kopieknotens in Japan hinzugefügt werden. Clients würden sich mit dem Hub verbinden und Folgendes angeben: NodeType=COPY. Die lokalen, schreibgeschützten Verbindungen in Japan würden in diesem Fall eine ausgeglichene Lastverteilung zwischen den lokalen Datenbankservern aufweisen, und kein Client würde jemals eine Verbindung zu einem Datenbankserver an einem Ort außerhalb Japans herstellen. Wenn ein Client Änderungen in der Datenbank durchführen müsste, würde sich die entsprechende Verbindungszeichenfolge wie folgt ändern: NodeType=PRIMARY.
Um sich mit der Lesen-Schreiben-Datenbank "joey" zu verbinden, die in einer Cloud-Datenbankkonfiguration ausgeführt wird, wobei "kangaroo1" und "kangaroo2" zwei Hosts sind, auf denen Cloud-Server laufen, können Sie die folgenden Verbindungsparameter verwenden:
UID=rick;PWD=secret;DBN=joey;Host=kangaroo1,kangaroo2 |
Um sich mit der schreibgeschützten Datenbank "joey" zu verbinden, die in einer Cloud-Datenbankkonfiguration ausgeführt wird, wobei "kangaroo1" und "kangaroo2" zwei Hosts sind, auf denen Cloud-Server laufen, können Sie die folgenden Verbindungsparameter verwenden:
UID=rick;PWD=secret;DBN=joey;Host=kangaroo1,kangaroo2;NodeType=READONLY |
![]() |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2013, SAP AG oder ein SAP-Konzernunternehmen. - SAP Sybase SQL Anywhere 16.0 |