Direkt zum InhaltDirekt zur SucheDirekt zur Navigation
▼ Zielgruppen ▼

Humboldt-Universität zu Berlin - Computer- und Medienservice

Umzug des MySQL-Servers 2019/2020

  • wir werden voraussichtlich am Mittwoch, dem 15. Januar 2020 ab 09:00 Uhr den MySQL-Server umziehen und dabei auch aktualisieren
  • der Umzug wird voraussichtlich ca. fünf Stunden dauern - wir vermelden auf der CMS-Webseite den erfolgreichen Abschluss
  • während dieser Zeit ist kein Zugriff auf irgendeine Datenbank möglich

Ablauf des Umzuges

  • Juni 2019 - Beginn der ersten Testphase
    • der neue Server wird unter dem Namen yama-tsuba (temporärer Name in der Testphase) in Betrieb genommen
    • alle Datenbanken wurden zum Testen von mydb nach yama-tsuba kopiert
    • Infomail an alle Datenbankbesitzer
  • Dezember 2019 - Beginn der zweiten Testphase
    • einzelne Änderungen der Konfiguration des neuen Servers und entsprechende Anpassungen auf dieser Umzugsseite
    • alle Datenbanken wurden erneut zum Testen von mydb nach yama-tsuba kopiert
    • neue Infomail an alle Datenbankbesitzer
  • 15. Januar 2020 - Umzug
    • zuerst wird der Zugriff auf mydb und yama-tsuba gesperrt
    • dann werden erneut alle Datenbanken von mydb nach yama-tsuba kopiert (die vorherigen Testdatenbanken auf yama-tsuba werden dabei überschrieben!)
    • danach wird der Server mydb abgeschaltet und der Server yama-tsuba in mydb umgenannt
    • schließlich wird der Zugriff auf den (neuen) mydb freigegeben und auf der CMS-Störungsseite das Ende des Umzuges bekanntgegeben
    • nun müssen nur noch alle Datenbankbesitzer von Datenbanken, die vorher nicht in der ersten Instanz (Port 3306) lagen, ihren Verbindungsport entsprechend der Tabelle weiter unten ändern

Neuerungen / Änderungen durch den Umzug

  • der Datenbankserver wird auf eine neue, deutlich stärkere Hardware mit neuem Betriebssystem migriert
  • die MySQL-Datenbankversion wird von Version 5.5 auf Version 8 aktualisiert
    • mit diesem Versionssprung sind zahlreiche Änderungen verbunden - klären Sie bitte rechtzeitig mit Ihrem Anwendungsentwickler, ob Ihre Datenbankanwendung prinzipiell mit MySQL 8 funktioniert
    • eine bereits festgestellte potentielle Inkompatibilität besteht z.B. darin, dass MySQL 8 mehrere neue Schlüsselwörter definitiert hat, die nun nicht mehr als Bezeichner (z.B. für Tabellen- oder Spaltennamen) verwendet werden dürfen
    • da viele dieser Probleme bereits bei einfachen Tests auftreten, sollten Sie unbedingt die Testphase (siehe unten) bis zum Umzugstag nutzen
  • die Datenbanken werden bezüglich der Instanz- und Portzuteilung neu sortiert - alle anderen Verbindungseinstellungen (Servername, DB-Account, Passwort) bleiben erhalten:
    Alte InstanzAlter PortNeue InstanzNeuer Port
    13306 13306
    23307 13306
    33308 13306
    43309 13306
    10014306 53310
    10024307 53310
    10034308 53310
    10044309 13306
    10054310 33308
    10064311 23307
    10074312 13306
    10084313 43309
    10094314 13306
    10104315 23307
    10114316 13306
    10124317 13306
    10134318 23307
    10144319 13306
    10154320 13306
  • alle Datenbanken laufen ab sofort unter der Storage-Engine InnoDB (MyISAM wird nicht mehr unterstützt)
    • dadurch wird erstmals bei allen Datenbanken kontinuierlich die referentielle Integrität sichergestellt
    • dies bedeutet insbesondere, dass referenzierte Schlüssel in jedem Fall existieren und Primärschlüssel eindeutig sein müssen
    • bisher von MySQL ignorierte Fehler werden in Zukunft (gewollt) automatisch vom Datenbanksystem abgelehnt
    • sollten bereits jetzt ungültige (bzgl. der referentiellen Integrität) Daten in Datenbanken stehen, können diese zu Problemen beim Umzug führen
    • jegliche Änderungsversuche der Storage-Engine werden serverseitig abgelehnt
  • (nur) die (neuen) Instanzen 2 bis 5 laufen mit einigen der neuen, strengeren Regeln von MySQL 8 (die bei anderen Datenbankmanagementsystemen, z.B. PostgreSQL, schon immer galten) - diese Regeln besagen unter anderem:
    • ungültige Werte in einer SQL-Anweisung führen nicht mehr zu einer automatischen, mitunter fehlerhaften Anpassung selbiger, sondern zu einem Abbruch der Anweisung mit entsprechender Fehlermeldung
    • eine Division durch Null sollte zu einem Fehler führen (aufgrund eines Fehlers in MySQL wird aber doch nur eine Warnung erzeugt und der Wert NULL generiert...)
    • für Entwickler: die Instanzen 2 bis 5 verwenden den "SQL-Mode"
      'NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO'
  • (nur) in der (neuen) Instanz 1 gelten die vorgenannten Regeländerungen nicht
    • für Entwickler: die Instanz 1 verwendet den "SQL-Mode"
      'NO_ENGINE_SUBSTITUTION'

Testphase

  • in der bereits laufenden Testphase kann und sollte die neue Datenbankversion unbedingt getestet werden - zu diesem Zweck haben wir alle Datenbanken schon einmal auf dem neuen Server (der in der Testphase unter einem anderen Namen im Netz ist) und der neuen MySQL-Version eingespielt
  • sie können mit dieser Testversion Ihrer Datenbank alles anstellen, was Ihnen zum Testen sinnvoll erscheint (insbesondere auch Schreiben/Verändern von Daten) - beachten Sie aber bitte, dass die Datenbanken der Testphase an deren Ende vollständig gelöscht werden, da sie beim Umzug durch einen aktuellen Abzug der jeweils aktuellen Version der Datenbank auf mydb ersetzt werden
  • Verbindungdaten
    • Servername: yama-tsuba.cms.hu-berlin.de
    • Port: siehe Tabelle oben
    • DB-Nutzername und DB-Passwort bleiben unverändert
  • wie bei allen anderen größeren Datenbankumstellungen mit Testphase gilt auch diesmal:
    Für Probleme, die sich nach dem Umzug/Update ergeben und die im Rahmen des Testbetriebs deutlich erkennbar gewesen wären, übernimmt der Datenbankservice keine Verantwortung!