Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Versionshinweise

- Previous: HADB-Dateisystem-Unterstützung
- Next: Bekannte SQL-Einschränkungen

## Upgrade der High Availability-Datenbank

- Tasks/Datenzusammenführung vor dem Upgrade

- Upgrade-Verfahren

- Testen des Upgrades

- Spezielle Bereitstellungs- und Upgrade-Informationen

### Tasks/Datenzusammenführung vor dem Upgrade

##### Bevor Sie beginnen

Die Benutzer müssen HADB-Verlaufsdateien, Management-Agent-Konfigurationsdateien, Protokolldateien und Repository sowie alle Datengeräte außerhalb des Installationspfads abgelegt haben. Sollte dies nicht der Fall sein, muss dies noch vor dem Upgrade erfolgen. So verschieben Sie Management-Repository- und Konfigurationsdateien:

1. Beenden Sie alle alten Management-Agenten und führen Sie die HADB-Knoten weiter aus.

2. Verschieben Sie an jedem Host das Repository-Verzeichnis an den neuen Pfad.

3. Kopieren Sie auf jedem Host das Verzeichnis `dbconfig` an den neuen Pfad.

4. Aktualisieren Sie auf jedem Host die Datei `mgt.cfg` und wählen Sie den korrekten Pfad für `dbconfig` und das Repository-Verzeichnis.

5. Starten Sie die Management-Agenten unter Verwendung der aktualisierten Datei `mgt.cfg`.

### Upgrade-Verfahren

Zur Aufrüstung von HADB-Version 4.4.x auf Version 4.4.2-7 gehen Sie wie folgt vor:

1. Führen Sie die oben genannten Tasks vor dem Upgrade nach Bedarf aus.

2. Installieren Sie HADB-Version 4.4.2-7 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.x, zum Beispiel unter `/opt/SUNWhadb/4.4.2-7`).

3. Installieren Sie HADB-Version 4.4.2-7 auf den `hadbm`-Client-Hosts, wenn diese sich von den HADB-Hosts unterscheiden.

4. Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.

5. Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl `hadbm`, der im `bin`-Verzeichnis der neuen Version zu finden ist.

6. Registrieren Sie das Paket in der Management-Domäne (der Standardpaketname lautet V4.4, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen tragen):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7

7. Führen Sie den Befehl `hadbm listpackages` aus und prüfen Sie, ob das neue Paket in der Domäne registriert ist.

8. Starten Sie die Datenbank mit der neuen `hadbm`-Version 4.4.2-7 neu. Wenn es erforderlich ist, die Geräte- und Verlaufsdateien zu verschieben, führen Sie ein Online-Upgrade aus und legen dabei in einem Schritt neue Pfade für Geräte und Verlaufsdateien fest:

       hadbm set packagename=V4.4.2-7,devicepath=new_devpath,
       historypath=new_histpath

   Wenn sich die Geräte und Verlaufsdateien anderenfalls bereits außerhalb des Installationsverzeichnisses befinden, führen Sie den folgenden Befehl aus, der lediglich einen Bilddurchlauf-Neustart der Knoten auslöst:

       hadbm set packagename=V4.4.2-7 Datenbankname

9. Prüfen Sie (mithilfe des Befehls `hadbm status`), ob der Datenbankstatus "running" lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.

10. Wenn alles funktioniert, kann die alte Installation später entfernt werden. Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der `ma`Repository. Anderenfalls schlägt der Befehl `hadbm unregisterpackage` fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. `hadbm set connectiontrace= wie voriger Wert` entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:

        hadbm unregisterpackage [--hosts=Hostliste] alter Paketname

11. Entfernen Sie die alte Installation aus dem Dateisystem.

### Testen des Upgrades

Um unter Solaris zu testen, ob das Upgrade erfolgreich war, prüfen Sie, ob das Upgrade ordnungsgemäß durchgeführt wurde:

1. Vergewissern Sie sich, dass die laufenden Prozesse die neuen Binärdateien verwenden. Prüfen Sie in allen HADB-Knoten Folgendes:

       neuer Pfad/bin/ma -v
       neuer Pfad/bin/hadbm -v

2. Prüfen Sie, ob die Datenbank ausgeführt wird. Der folgende Befehl sollte zeigen, dass alle HADB-Knoten den Status “running” aufweisen.

       neuer Pfad/bin/hadbm status -n

3. Vergewissern Sie sich, dass Produkte mit Verwendung von HADB ihre Zeiger so geändert haben, dass sie auf den neuen HADB-Pfad verweisen.

4. Die Produkte mit Verwendung von HADB können ihre Upgrade-Tests ausführen, um zu prüfen, dass das HADB-Upgrade ebenfalls funktioniert.

   Wenn nach einem Online-Upgrade die neue Version nicht ordnungsgemäß funktioniert, wechseln Sie wieder zur Verwendung der vorherigen HADB-Version. Wenn jedoch eine Änderung am Management-Agent-Repository durchgeführt wurde, kann die HADB selbst heruntergestuft werden. Allerdings muss der neue Management-Agent weiter ausgeführt werden.

### Spezielle Bereitstellungs- und Upgrade-Informationen

In diesem Abschnitt werden zusätzliche Informationen über HADB-Bereitstellung und Upgrade aufgeführt.

- Bereitstellung

- Online-Upgrade von 4.4.1 auf 4.4.2

#### Bereitstellung

- Speichern Sie Geräte-, Protokoll- und Verlaufsdateien nur auf lokalen Festplatten. Verwenden Sie keine entfernt bereitgestellten Dateisysteme.

- Wenn mehrere Knoten auf einem Host platziert wurden, wird empfohlen, dass die Geräte zu allen Knoten der verschiedenen Festplatten gehören. Anderenfalls würde die Leistung durch die Konkurrenzsituation zwischen den Festplatten herabgesetzt werden. Symptome für dieses Problem sind in den Verlaufsdateien anhand von Meldungen ersichtlich wie `BEWARE - last flush/fputs took too long`. Wenn ein Knoten über mehrere Datengerätedateien verfügt, wird empfohlen, separate Festplatten für diese Gerätedateien zu verwenden.

- Verwenden Sie lokale Festplatten (möglichst eine andere als die für Datengeräte verwendete Festplatte), um HADB-Binärdateien auf HADB-Hosts zu installieren. NFS-Verzögerungen oder Zugriffskonflikte können zu Knotenneustarts mit der Warnung "`Process blocked for` `nnn``, max block time is` `nnn`" in den Verlaufsdateien führen.

- Legen Sie die HADB-Geräte, Verlaufsdateien, Management-Agent-Verzeichnisse und agent config-Dateien nicht im HADB-Paketpfad ab. Dies führt zu Problemen beim Upgrade auf neuere Versionen sowie beim Löschen des alten Paketpfads.

- Diese HADB-Version wird offiziell für maximal 28 Knoten unterstützt, und zwar für 24 aktive Datenknoten mit 4 Ersatzknoten.

- Es wird empfohlen, dieselbe Version für den JDBC-Treiber und den HADB-Server zu verwenden.

- IPv6 wird nicht unterstützt, sondern lediglich IPv4.

- Die Länge der Befehlszeile unter Windows ist auf 2048 Byte beschränkt.

- Das Netzwerk muss für UDP Multicast konfiguriert sein.

- Aufgrund des übermäßigen Swappings von RedHat Enterprise Linux 3.0, Updates 1 bis 3, empfehlen wir es nicht als Bereitstellungsplattform. Das Problem wurde in RedHat Enterprise Linux 3.0, Update 4 behoben.

- Möglichkeit, `NSUP` mit Echtzeit-Priorität auszuführen.

  Die Prozesse des Knoten-Supervisors (`NSUP`) (`clu_nsup_srv` ) stellen die hohe Verfügbarkeit von HADB mithilfe des termingemäßen Austauschs von "heartbeat"-Nachrichten sicher. Die zeitliche Koordinierung wird beeinträchtigt, wenn ein `NSUP` mit anderen Prozessen gemeinsam untergebracht wird, da dies zu einem Ressourcenschwund führt. Die Folge sind eine falsche Netzwerkpartitionierung und Knotenneustarts (vorher wird die Warnung “Process blocked for `n` seconds” in den Verlaufsdateien ausgegeben), die zu abgebrochenen Transaktionen und anderen Ausnahmefehlern führen.

  Um dieses Problem zu lösen, muss für `clu_nsup_srv` (unter `Installationspfad``/lib/server` zu finden) das `suid`-Bit gesetzt sein und Eigentümer der Datei muss der Benutzer "root" sein. Dies wird manuell durch folgende Befehle erzielt:

      # chown root clu_nsup_srv
      # chmod u+s clu_nsup_srv

  Dadurch wird der Prozess `clu_nsup_srv`, wenn er gestartet wird, als Benutzer `root` ausgeführt. Dies wiederum ermöglicht dem Prozess, sich selbst automatisch Echtzeit-Priorität nach dem Start zuzuweisen. Zur Vermeidung von Sicherheitsproblemen bei Verwendung von `setuid` wird die Echtzeit-Priorität ganz am Anfang festgelegt und der Prozess kehrt zur effektiven UID zurück, sobald die Priorität geändert wurde. Andere HADB-Prozesse senken ihre Priorität auf Zeitteilungspriorität ab.

  Wenn NSUP die Echtzeit-Priorität nicht setzen konnte, wird der Warnhinweis “Could not set realtime priority” (`Unix: Fehler-Nr. wird auf EPERM` gesetzt) ausgegeben, der in der Datei `ma.log` dargelegt ist, und der Prozess wird ohne Echtzeit-Priorität fortgesetzt.

  Es gibt Fälle, in denen es nicht möglich ist, Echtzeit-Prioritäten festzulegen; beispielsweise in folgenden Situationen:

  - Bei Installation in nichtglobalen Zonen von Solaris 10

  - Wenn die Berechtigungen `PRIV_PROC_LOCK_MEMORY` (Ermöglichen, dass ein Prozess Seiten im physischen Speicher sperren kann) und/oder `PRIV_PROC_PRIOCNTL` in Solaris 10 aufgerufen werden.

  - Benutzer deaktivieren die Berechtigung `setuid`

  - Benutzer installieren die Software als tar-Dateien (Installationsoption nonroot für `App.server`)

  Der Prozess `clu_nsup_srv` ist nicht CPU-konsumierend und sein Ressourcenbedarf ist gering. Wenn er mit Echtzeit-Priorität ausgeführt wird, beeinflusst er nicht die Leistung.

- Konfiguration von IP-Netzwerk-Multipathing für HADB für Solaris (nur unter Solaris 9 getestet).

  Sun empfiehlt, dass Solaris-Hosts, auf denen HADB ausgeführt wird, mit Netzwerk-Multipathing eingerichtet werden, um die höchstmögliche Netzwerkverfügbarkeit sicherzustellen. Die Einrichtung von Network-Multipathing wird in allen Einzelheiten im IP Network Multipathing Administration Guide behandelt. Wenn Sie sich dafür entscheiden, Multipathing mit HADB zu verwenden, lesen Sie im IP Network Multipathing Administration Guide den Abschnitt "Verwaltung von Netzwerk-Multipathing", um Multipathing einzurichten, bevor Sie mit dem Anpassen des Multipathing-Setups für HADB fortfahren (siehe unten). Der IP Network Multipathing Administration Guide gehört zur System Administrator Collection von Solaris 9 und kann von der Adresse `http://docs.sun.com` heruntergeladen werden.

  - Einrichten der Netzwerkschnittstellenfehler-Erkennungszeit

    Damit HADB die Multipathing-Ausfallsicherung ordnungsgemäß unterstützt, darf die Netzwerkschnittstellenfehler-Erkennungszeit gemäß Spezifikation durch den Parameter `FAILURE_DETECTION_TIME` in `/etc/default/mpathd` 1000 Millisekunden nicht übersteigen. Bearbeiten Sie die Datei und ändern Sie den Wert dieses Parameters auf `1000`, wenn der Originalwert höher ist:

        FAILURE_DETECTION_TIME=1000

    Damit die Änderung wirksam ist, geben Sie den folgenden Befehl aus:

        pkill -HUP in.mpathd

  - Mit HADB zu verwendende IP-Adressen

    Gemäß Erläuterungen im Solaris IP Network Multipathing Administration Guide umfasst das Multipathing die Gruppierung physischer Netzwerkschnittstellen in Multipath-Schnittstellengruppen. Jede physische Schnittstelle in einer derartigen Gruppe ist mit zwei IP-Adressen assoziiert: einer physischen Schnittstellenadresse und einer Testadresse. Lediglich die physische Schnittstellenadresse kann zum Übertragen von Daten verwendet werden. Die Testadresse dient nur für interne Solaris-Zwecke. Wenn `hadbm create --hosts` ausgeführt wird, darf jeder Host mit nur einer physischen Schnittstellenadresse der Multipath-Gruppe spezifiziert werden.

  - Beispiel

    Angenommen, Host 1 und Host 2 verfügen jeweils beide über zwei physische Netzwerkschnittstellen. Auf jedem Host werden diese beiden Schnittstellen als Multipath-Gruppe eingerichtet und beim Ausführen von `ifconfig -a` erhalten Sie Folgendes:

    Host 1

        bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000
        broadcast 129.159.115.255

    Host 2

        bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000
        broadcast 129.159.115.255

    Hier sind die physischen Netzwerkschnittstellen auf beiden Hosts, als `bge0` und `bge1` aufgelisteten Schnittstellen. Die als `bge0:1` und `bge1:1` aufgelisteten Schnittstellen sind Multipath-Testschnittstellen (sie werden daher im `ifconfig`-Output mit DEPRECATED gekennzeichnet). Siehe dazu auch den IP Network Multipathing Administration Guide.

    Zum Einrichten von HADB in dieser Umgebung wählen Sie eine physische Schnittstellenadresse von jedem Host. In diesem Beispiel wählen wir `129.159.115.10` von Host 1 und `129.159.115.20` von Host 2. Zum Erstellen einer Datenbank mit einem Datenbankknoten pro Host verwenden Sie das folgende Argument für `hadbm create`:

        --host 129.159.115.10,129.159.115.20

    Zum Erstellen einer Datenbank mit zwei Datenbankknoten auf jedem Host verwenden Sie das folgende Argument:

        --host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20

    In beiden Fällen muss die Variable `ma.server.mainternal.interfaces` auf beiden Hosts auf `129.159.115.0/24` festgelegt werden.

#### Online-Upgrade von 4.4.1 auf 4.4.2

Es ist nicht möglich, online von 4.2 oder 4.3 auf 4.4 upzugraden. Die Version 4.4 unterstützt jedoch Online-Upgrades für zukünftige Versionen. Zum Aufrüsten von 4.4.1 auf 4.4.2 gehen Sie wie folgt vor:

1. Installieren Sie 4.4.2 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.1 – beispielsweise `/opt/SUNWhadb/4.4.2-6`).

2. Installieren Sie die neue Version auf den `hadbm client`-Hosts.

3. Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.

4. Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl `hadbm`, der im `bin`-Verzeichnis der neuen Version zu finden ist.

5. Registrieren Sie das Paket in der Management-Domäne (der Standard-Paketname lautet hier `V4.4`, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen haben):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2

6. Starten Sie die Datenbank mit der neuen Version neu (mit dem folgenden Befehl wird ein Bildlauf-Neustart der Knoten ausgeführt):

       hadbm set packagename=V4.4.2 Datenbankname

7. Prüfen Sie (mithilfe des Befehls `hadbm status`), ob der Datenbankstatus “running” lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.

8. Wenn alles funktioniert, kann die alte Installation später entfernt werden:

   Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der `ma`-Repository. Anderenfalls schlägt `hadbm unregisterpackage` fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. hadbm set connectiontrace=`<wie voriger wert>` entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:

       hadbm unregisterpackage [--hosts=<host_list>] <old_package_name>

   Entfernen Sie die alte Installation aus dem Dateisystem (siehe HADB-Installationsanweisungen.

- Previous: HADB-Dateisystem-Unterstützung
- Next: Bekannte SQL-Einschränkungen

- © 2010, Oracle Corporation and/or its affiliates