[IBM i][AIX Solaris HP-UX Linux Windows]

Transaktions- und Kompensationsprotokolle in einer relationalen Datenbank für Hochverfügbarkeit speichern

Sie können Ihre WebSphere Application Server-Transaktions- und Kompensationsprotokolle in einer relationalen Datenbank speichern, anstatt sie als Betriebssystemdateien zu speichern. Dieses Feature bietet Unterstützung der Hochverfügbarkeit ohne Verwendung eines gemeinsam genutzten Dateisystems.

Informationen zu diesem Vorgang

Der WebSphere Application Server-Transaktionsservice schreibt für jede globale Transaktion, an der zwei oder mehr Ressourcen beteiligt sind oder die auf mehrere Server verteilt ist, Informationen in das Transaktionsprotokoll. Diese Transaktionen werden entweder von den Anwendungen oder von dem Container, in denen bzw. in dem sie implementiert werden. Der Transaktionsservice verwaltet Transaktionsprotokolle, um die Transaktionsintegrität sicherzustellen. In der Vorbereitungsphase einer verteilten Transaktion werden Informationen in die Transaktionsprotokolle geschrieben, damit der Transaktionsservice, die Protokolle verwenden kann, um alle unbestätigten Transaktionen zu wiederholen, falls ein WebSphere Application Server mit aktiven Transaktionen nach einem Fehler erneut gestartet wird. Dadurch kann das gesamte System wieder in einen konsistenten Zustand gebracht werden.

In früheren Releases von WebSphere Application Server wurden die Transaktionsprotokolle als Betriebssystemdateien gespeichert. In WebSphere Application Server Version 8.5.5 und höher bleibt diese Konfiguration die Standardkonfiguration. Sie können die Transaktionsprotokolle auch in einer relationalen Datenbank speichern. Diese Konfigurationsoption wird hauptsächlich für eine Hochverfügbarkeitsumgebung verwendet. In Vorgängerreleases von WebSphere Application Server setzte die Unterstützung für Hochverfügbarkeitstransaktionen die Verwendung eines gemeinsam genutzten Dateisystems zum Hosten der Transaktionsprotokolle voraus, z. b. einen über NFSv4 angehängten NAS (Network-attached Storage) oder ein SAN (Storage Area Network). Mit diesem Feature können Sie ihre Hochverfügbarkeitsdatenbank als gemeinsam genutztes Repository für die Transaktionsprotokolle verwenden,insbesondere, wenn Sie bereits in Hochverfügbarkeitsdatenbanktechnologie investiert haben, und haben somit eine Alternative zur Verwendung eines gemeinsam genutzten Dateisystems.

Anmerkung: Die aktuelle Implementierung für das Speichern der Transaktions- und Kompensationsprotokolle in einer relationalen Datenbank unterstützt Hochverfügbarkeitsfunktionen in DB2 und Oracle. Beispielsweise werden clientspezifische Features wie DB2 HADR oder Oracle RAC DataGuard, die bei einem Ausfall die Verbindungswiederholung zu einer anderen Datenbankinstanz ermöglichen, unterstützt. Hochverfügbarkeitsfunktionen in relationalen Datenbanken anderer Anbieter werden gegenwärtig nicht unterstützt.

In der aktuellen Implementierung wird die Transaktionsprotokollierung inaktiviert, wenn nicht erwartete JDBC-Ausnahmen von der Hauptwiederherstellungsprotokollfunktion festgestellt werden, und der Server muss heruntergefahren werden, damit unvollständige Transaktionen wiederhergestellt werden können. Es wird kein Versuch unternommen, die Verbindung wiederherzustellen, bis der Server erneut gestartet wurde. Die aktuelle Implementierung versucht auch nicht festzustellen, ob die Bedingung temporär ist.

In WebSphere Application Server Version 8.5.5 und höher können Sie eine ähnliche Funktion nutzen, die ebenfalls für Kunden konzipiert wurde, die in einer Hochverfügbarkeitsumgebung arbeiten. Mit dieser Funktion können Sie die Kompensationswiederherstellungsprotokolle in einer relationalen Datenbank speichern. Der WebSphere Application Server-Kompensationsservice erlaubt Anwendungen auf unterschiedlichen Systemen, Aktivitäten zu koordinieren, die flexibler verbunden sind als atomare Transaktionen. Er speichert Informationen, die für die Durchführung einer Kompensation nach einem Systemausfall erforderlich sind, in seinen eigenen dedizierten Wiederherstellungsprotokollen.

Fehler vermeiden Fehler vermeiden: Die Datenquelle des SQL-Wiederherstellungsprotokolls muss den folgenden Wert für die maximale Poolgröße haben:
(2 * die Anzahl potenzieller Server, die über den Peer wiederhergestellt werden) + 2
Diese maximale Poolgröße sorgt für eine ausreichende Anzahl an Verbindungen zur Datenbank, um alle zugehörigen Transaktionsprotokolle schließen zu können. Wenn Sie die maximale Poolgröße nicht auf diesen Wert gesetzt haben, wird möglicherweise die Fehlernachricht J2CA0045E angezeigt, aus der hervorgeht, dass nicht genügend Verbindungen verfügbar sind. gotcha

Vorgehensweise

Sie müssen die Position des Transaktionsprotokolls und des Kompensationsprotokolls für jeden Server im Cluster konfigurieren, bevor Sie die Hochverfügbarkeit aktivieren. Dazu müssen Sie die Attribute TransactionLogDirectory und CompensationLogDirectory für jeden Server setzen. Jeder Server im Cluster muss ein eindeutiges Transaktionsprotokollverzeichnis und ein eindeutiges Kompensationsprotokollverzeichnis über die Angabe einer bestimmten Eigenschaft tablesuffix referenzieren, um zu verhindern, dass mehrere Server um Ressourcen des Managementsystems für relationale Datenbanken (RDBMS) konkurrieren. Beispiel: Sie haben einen Cluster mit dem Namen AppCluster und den folgenden vier Member-Servern:
  • AppClusterMember1
  • AppClusterMember2
  • AppClusterMember3
  • AppClusterMember4
Dann können Sie die folgenden Tabellensuffixe für AppCluster definieren:
  • App1 für AppClusterMember1
  • App2 für AppClusterMember2
  • App3 für AppClusterMember3
  • App4 für AppClusterMember4

Führen Sie die folgenden Schritte aus:

  1. Nicht transaktionsorientierte Datenquelle für das Speichern eines Transaktions- und eines Kompensationswiederherstellungsprotokolls konfigurieren:
    1. Erstellen Sie einen JDBC-Provider für Ihre spezifische Implementierung des Managementsystems für relationale Datenbanken. Geben Sie als Implementierungstyp "Nicht-XA" an.
    2. Erstellen Sie einen neuen JAAS-J2C-Authentifizierungsdatenalias. Mit diesem Datenalias werden die Sicherheitsberechtigungsnachweise definiert, die für die Verbindung zum Managementsystem für relationale Datenbanken verwendet werden. Die Berechtigungsnachweise, die im Managementsystem für relationale Datenbanken definiert sind, müssen die Berechtigung zum Erstellen von Tabellen in der Datenbank einschließen.
    3. Erstellen Sie eine Datenquelle mit dem JDBC-Provider, den Sie unter Schritt a erstellt haben. Als komponentengesteuerter Authentifizierungsalias muss der unter Schritt b erstellte JAAS-Alias angegeben werden. Definieren Sie die URL für Ihre Datenquelle, um eine Verbindung zum Managementsystem für relationale Datenbanken herzustellen.
    4. Konfigurieren Sie die neue Datenquelle als nicht transaktionsorientiert, indem Sie die folgenden Schritte ausführen:
      1. Öffnen Sie Ihre neu erstellte Datenquelle.
      2. Klicken Sie unter Weitere Eigenschaften auf Eigenschaften der WebSphere Application Server-Datenquelle.
      3. Wählen Sie das Kontrollkästchen Nicht transaktionsorientierte Datenquelle aus.
      4. Speichern Sie die Änderungen.
  2. Konfigurieren Sie den Transaktionsservice, um Transaktionen in einer relationalen Datenbank zu speichern:
    1. Klicken Sie in der Administrationskonsole von WebSphere Application Server auf Server > Servertypen > WebSphere-Anwendungsserver > Servername. Die Eigenschaften des angegebenen Anwendungsservers werden angezeigt.
    2. Klicken Sie im Abschnitt Containereinstellungen auf Container-Services > Transaktionsservice. Die Seite mit den Einstellungen des Transaktionsservice wird angezeigt.
    3. Wählen Sie die Registerseite Konfiguration aus, wenn sie noch nicht angezeigt wird.
    4. Geben Sie im Feld Verzeichnis für Transaktionsprotokoll eine angepasste Zeichenfolge ein, um anzuzeigen, dass die Protokolle in einer Datenbank gespeichert werden sollen. Die Zeichenfolge muss das folgende Format haben:
      custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=JNDI-Name_der_Datenquelle,tablesuffix=suffix
      JNDI-Name_der_Datenquelle ist der JNDI-Name der zuvor erstellten, nicht transaktionsorientierten Datenquelle und Suffix ist eine Zeichenfolge, die Sie so formulieren müssen, dass jedes Member Ihres Hochverfügbarkeitsclusters eindeutig gekennzeichnet ist.
      Einschränkung: Wenn Sie eine Oracle-Datenbank verwenden, darf die Suffixzeichenfolge nicht mehr als 15 Zeichen lang sein.
  3. (Optional) Konfigurieren Sie den Kompensationsservice, um Transaktionen in einer relationalen Datenbank zu speichern, wenn Sie beabsichtigen, Kompensations- oder Aktivitätsservices in WebSphere Application Server zu verwenden:
    1. Klicken Sie in der Administrationskonsole von WebSphere Application Server auf Server > Servertypen > WebSphere-Anwendungsserver > Servername. Die Eigenschaften des angegebenen Anwendungsservers werden angezeigt.
    2. Klicken Sie im Abschnitt Containereinstellungen auf Container-Services > Kompensationsservice. Die Seite mit den Einstellungen des Kompensationsservice wird angezeigt.
    3. Wählen Sie die Registerseite Konfiguration aus, wenn sie noch nicht angezeigt wird.
    4. Geben Sie im Feld Verzeichnis für Wiederherstellungsprotokoll eine angepasste Zeichenfolge ein, um anzuzeigen, dass die Protokolle in einer Datenbank gespeichert werden sollen. Die Zeichenfolge muss das folgende Format haben:
      custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=JNDI-Name_der_Datenquelle,tablesuffix=Suffix
      JNDI-Name_der_Datenquelle ist der JNDI-Name der zuvor erstellten, nicht transaktionsorientierten Datenquelle und Suffix ist eine Zeichenfolge, die Sie so formulieren müssen, dass jedes Member Ihres Hochverfügbarkeitsclusters eindeutig gekennzeichnet ist.
      Einschränkung: Wenn Sie eine Oracle-Datenbank verwenden, darf die Suffixzeichenfolge nicht mehr als 15 Zeichen lang sein.
  4. Optional: Datenbanktabellen erstellen.

    WebSphere Application Server versucht beim ersten Start, die erforderlichen Datenbanktabellen zu erstellen. Wenn das nicht möglich ist, weil beispielsweise eine Berechtigung unzureichend ist, kann der Server nicht gestartet werden. Unter diesen Bedingungen müssen Sie die drei Datenbanktabellen manuell erstellen.

    Die folgende DDL entspricht einer eigenständigen Serverumgebung. In einer eigenständigen Umgebung sind zwei Datenbanktabellen, eine Transaktionsprotokolltabelle und eine Partnerprotokolltabelle für die Unterstützung des Transaktionsservice erforderlich. Wenn Sie beabsichtigen, den Kompensations- oder den Aktivitätsservice zu verwenden, ist außerdem eine dritte Kompensationsprotokolltabelle erforderlich.

    Sie können die Namen der Tabellen an Ihre Umgebung anpassen. Beispiel: Sie müssen vier Transaktionsprotokolltabellen, vier Partnerprotokolltabellen und optional vier Kompensationsprotokolltabellen erstellen, wenn Sie einen Cluster mit dem Namen AppCluster und den folgenden vier Member-Servern haben:
    • AppClusterMember1
    • AppClusterMember2
    • AppClusterMember3
    • AppClusterMember4
    Sie können die folgenden Tabellen für AppCluster definieren:
    Clustername Servername Transaktionsprotokolltabelle Partnerprotokolltabelle Kompensationsprotokolltabelle
    AppCluster AppClusterMember1 WAS_TRAN_LOGApp1 WAS_PARTNER_LOGApp1 WAS_COMP_LOGApp1
      AppClusterMember2 WAS_TRAN_LOGApp2 WAS_PARTNER_LOGApp2 WAS_COMP_LOGApp2
      AppClusterMember3 WAS_TRAN_LOGApp3 WAS_PARTNER_LOGApp3 WAS_COMP_LOGApp3
      AppClusterMember4 WAS_TRAN_LOGApp4 WAS_PARTNER_LOGApp4 WAS_COMP_LOGApp4
    Die folgende DDL-Strukturen zeigen, wie die Datenbanktabellen mit dem Tabellensuffix App1 unter DB2 erstellt werden:
    CREATE TABLE WAS_TRAN_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    CREATE TABLE WAS_PARTNER_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    CREATE TABLE WAS_COMP_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    Die folgenden DDL-Strukturen zeigen, wie die Datenbanktabelle unter Oracle erstellt werden:
    CREATE TABLE WAS_TRAN_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)
    CREATE TABLE WAS_PARTNER_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)
    CREATE TABLE WAS_COMP_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)

Beispiel

Wenn Sie einen Cluster mit dem Namen AppCluster und vier Member-Server mit den Namen AppClusterMember1, AppClusterMember2, AppClusterMember3 und AppClusterMember4 haben, konfigurieren Sie anschließend die Protokollpositionen wie folgt:
Clustername Servername Transaktionsprotokolltabelle Kompensationsprotokolltabelle
AppCluster AppClusterMember1 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1
AppClusterMember2 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2
AppClusterMember3 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3
AppClusterMember4 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4
In diesem Beispiel wurde der Tabellensuffix wie folgt gesetzt:
  • AppClusterMember1
  • AppClusterMember2
  • AppClusterMember3
  • AppClusterMember4
Es wurden Datenbanktabellen mit den folgenden Namen erstellt:
  • WAS_TRAN_LOGApp1
  • WAS_TRAN_LOGApp2
  • WAS_TRAN_LOGApp3
  • WAS_TRAN_LOGApp4
  • WAS_PARTNER_LOGApp1
  • WAS_PARTNER_LOGApp2
  • WAS_PARTNER_LOGApp3
  • WAS_PARTNER_LOGApp4
  • WAS_COMP_LOGApp1
  • WAS_COMP_LOGApp2
  • WAS_COMP_LOGApp3
  • WAS_COMP_LOGApp4

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjta_store_logs_in_rdb
Dateiname:tjta_store_logs_in_rdb.html