defacto.blog
Andreas Landgraf, 18.02.2007
Blitzumzug
Letzte Woche haben wir eine Datenbank mit einem Umfang von 140 Gigabyte auf neue Hardware, eine andere Betriebssystemversion und eine andere Oracle-Version migriert -- bei einer sensationell kurzen Downtime von nur 35 Minuten.
Die betroffene Datenbank unterstützt einen der erfolgreichsten Online-Shops in Deutschland, der bis zu mehreren Millionen Euro Umsatz pro Tag macht, und ist dort unternehmenskritisch. Ausgangspunkt für die Migration war der Wechsel von einem Server mit Pentium CPU und integriertem 1,3-Terabyte RAID zu einem Server mit Dual Core Xeon CPU und externem 2,1-Terabyte RAID. Durch den Umstieg von 32- auf 64-Bit-Prozessorarchitektur war es notwendig, auf die 64-Bit-Versionen des SuSE Linux Enterprise Server (SLES) und des Oracle RDBMS umzustellen.
Der "offizielle" Weg einer solchen Migration besteht im wesentlichen darin, auf der alten Hardware einen Full Dump der Datenbank zu schreiben, diesen auf die neue Hardware zu kopieren und dort zu importieren. Dies hätte aufgrund des Datenvolumens etwa 36 Stunden gedauert -- eine Ausfallzeit, die für unseren Auftraggeber nicht akzeptabel gewesen wäre.
Eine gängige Methode, eine Oracle-Datenbank in sehr kurzer Zeit von einer Hardware auf die andere zu übernehmen, besteht darin, bei laufendem Produktionssystem parallel eine Standby-Datenbank aufzubauen. Die Standby-Datenbank ist ständig bis auf wenige Minuten Verzögerung auf dem Datenstand der Produktion. Zur Umschaltung wird die Produktionsdatenbank heruntergefahren, die letzten Änderungen in der Standby-Datenbank nachgezogen und dann Standby zu Produktion umkonfiguriert. Allerdings ist das Verfahren nur für die Schaffung eines Notfallsystems gedacht, das bei Ausfall des Primärsystems einspringen kann. Daher funktioniert es offiziell nur mit identischen Hard- und Software-Versionen, nicht aber bei einer Migration von 32 auf 64 Bit.
Da unser Vorhaben, einen Switchover zur Standby-Datenbank bei gleichzeitiger 32/64-Bit-Migration offiziell "not supported" ist, waren die Originalversionen der von Oracle bereitgestellten Anleitungen und Tools erwartungsgemäß nicht in der Lage, beides in einem Schritt zu vollbringen. Es ist uns allerdings gelungen, diese so zu ändern und zu erweitern, dass der Umzug dann doch wie von uns gewünscht gelang. Nachdem wir den gesamten Zyklus mehrfach erfolgreich durchgespielt hatten, haben wir uns der Herausforderung gestellt, das Produktionssystem tatsächlich und irreversibel mit dem neu entwickelten Verfahren umzuziehen. Dank der sorgfältigen Vorbereitung hat das nicht nur funktioniert, sonder wurde auch im vorgesehenen Zeitrahmen von 35 Minuten erfolgreich abgeschlossen.
Die betroffene Datenbank unterstützt einen der erfolgreichsten Online-Shops in Deutschland, der bis zu mehreren Millionen Euro Umsatz pro Tag macht, und ist dort unternehmenskritisch. Ausgangspunkt für die Migration war der Wechsel von einem Server mit Pentium CPU und integriertem 1,3-Terabyte RAID zu einem Server mit Dual Core Xeon CPU und externem 2,1-Terabyte RAID. Durch den Umstieg von 32- auf 64-Bit-Prozessorarchitektur war es notwendig, auf die 64-Bit-Versionen des SuSE Linux Enterprise Server (SLES) und des Oracle RDBMS umzustellen.
Der "offizielle" Weg einer solchen Migration besteht im wesentlichen darin, auf der alten Hardware einen Full Dump der Datenbank zu schreiben, diesen auf die neue Hardware zu kopieren und dort zu importieren. Dies hätte aufgrund des Datenvolumens etwa 36 Stunden gedauert -- eine Ausfallzeit, die für unseren Auftraggeber nicht akzeptabel gewesen wäre.
Eine gängige Methode, eine Oracle-Datenbank in sehr kurzer Zeit von einer Hardware auf die andere zu übernehmen, besteht darin, bei laufendem Produktionssystem parallel eine Standby-Datenbank aufzubauen. Die Standby-Datenbank ist ständig bis auf wenige Minuten Verzögerung auf dem Datenstand der Produktion. Zur Umschaltung wird die Produktionsdatenbank heruntergefahren, die letzten Änderungen in der Standby-Datenbank nachgezogen und dann Standby zu Produktion umkonfiguriert. Allerdings ist das Verfahren nur für die Schaffung eines Notfallsystems gedacht, das bei Ausfall des Primärsystems einspringen kann. Daher funktioniert es offiziell nur mit identischen Hard- und Software-Versionen, nicht aber bei einer Migration von 32 auf 64 Bit.
Da unser Vorhaben, einen Switchover zur Standby-Datenbank bei gleichzeitiger 32/64-Bit-Migration offiziell "not supported" ist, waren die Originalversionen der von Oracle bereitgestellten Anleitungen und Tools erwartungsgemäß nicht in der Lage, beides in einem Schritt zu vollbringen. Es ist uns allerdings gelungen, diese so zu ändern und zu erweitern, dass der Umzug dann doch wie von uns gewünscht gelang. Nachdem wir den gesamten Zyklus mehrfach erfolgreich durchgespielt hatten, haben wir uns der Herausforderung gestellt, das Produktionssystem tatsächlich und irreversibel mit dem neu entwickelten Verfahren umzuziehen. Dank der sorgfältigen Vorbereitung hat das nicht nur funktioniert, sonder wurde auch im vorgesehenen Zeitrahmen von 35 Minuten erfolgreich abgeschlossen.