Wie wir ein Downgrade von Jira Data Center 8.22.6 auf 8.20.30 ohne Ausfallzeit durchführten

Vor Kurzem wurde unser Team mit einer ungewöhnlichen Herausforderung betraut: Ein Jira Data Center in AWS war versehentlich auf Version 8.22.6 aktualisiert worden, obwohl eigentlich 8.20.30 vorgesehen war. Das erforderte ein gezieltes Downgrade – eine Aufgabe, die selten unkompliziert ist, insbesondere wenn keine Ausfallzeit entstehen darf. So haben wir diese komplexe Situation gemeistert:

Schritt 1: Überprüfung möglicher Datenbankinkompatibilitäten

Der erste und womöglich wichtigste Schritt bestand darin sicherzustellen, dass das in Version 8.22.6 eingeführte Datenbankschema keine Inkompatibilitäten aufwies, die ein Zurücksetzen auf 8.20.30 verhindern würden. Durch den Vergleich der entitymodel.xml-Dateien beider Versionen (im Verzeichnis WEB-INF/classes/entitydefs/) konnten wir Änderungen an Tabellen, Spalten, Datentypen und Beziehungen nachvollziehen.

Schritt 2: Datenbankversion zurücksetzen

Anschließend aktualisierten wir die in den Systemeigenschaften von Jira gespeicherte Datenbankversion auf unser Downgrade-Ziel. Der folgende SQL-Befehl wurde ausgeführt:

UPDATE propertystring SET propertyvalue = '820030'
    WHERE id = (SELECT id FROM propertyentry 
        WHERE property_key = 'jira.version.patched');

Damit entsprach der interne Versionsstand von Jira wieder der Zielversion.

Schritt 3: Rückgängig machen von Schema-Änderungen

Auf Basis unseres Vergleichs stellten wir fest, dass wir eine Schemaänderung rückgängig machen mussten, indem wir eine Spalte wieder hinzufügten, die in der höheren Version entfernt worden war:

ALTER TABLE component ADD deleted VARCHAR(10);

Schritt 4: Deaktivierung von AutoScaling-Health-Check

Um zu verhindern, dass AWS AutoScaling die neuen, möglicherweise langsamer startenden Nodes fälschlich beendet, deaktivierten wir die Health Checks vorübergehend.

Schritt 5: Bereinigung der Plugin-Versionen im Shared Home

Wir entfernten alle zur Version 8.22.6 gehörenden Plugin-Artefakte im gemeinsamen Verzeichnis, um Konflikte mit der Downgrade-Version zu vermeiden:

find /media/atl/jira/shared -type f -name "*4.22.6*" -delete && find /media/atl/jira/shared -type f -name "*8.22.6*"- delete

Schritt 6: Anpassung der Jira-Version im Shared Home

Wir setzten die Version in der Datei jira-software.version explizit auf die Zielversion:

echo "8.20.30" > /media/atl/jira/shared/jira-software.version

Schritt 7: Start des Rolling Updates

Nach Abschluss der Vorbereitungen begannen wir mit einem Rolling Update – einer Methode, bei der jeweils nur ein Node aktualisiert wird, um durchgehend Betrieb sicherzustellen.

Schritt 8: Aktualisierung des CloudFormation-Templates

Das AWS CloudFormation-Template wurde angepasst, um die Zielversion 8.20.30 zu verwenden – damit neue Nodes direkt korrekt konfiguriert starten.

Schritt 9–12: Node-Management

Wir führten eine stufenweise Migration durch:

1. Einen Node abkoppeln und durch einen neuen Node mit Version 8.20.30 ersetzen.
2. Die verbleibenden Nodes nacheinander stoppen.
3. Rolling Update über alle Nodes abschließen.
4. Alle Nodes neu starten, um sicherzustellen, dass sie mit der korrekten Version laufen.

Dank sorgfältiger Planung und exakter Umsetzung konnten wir Jira Data Center erfolgreich von Version 8.22.6 auf 8.20.30 downgraden – und das ganz ohne Ausfallzeit. Diese Erfahrung verdeutlicht, wie wichtig sorgfältige Versionskontrolle und betriebliche Checks beim Management von Unternehmenssoftware in der Cloud sind.