Datenmigration wie im Flug - Flyway
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 6 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/62481 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2023 | |
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
1
4
00:00
Computer animation
00:17
Computer animation
02:03
Computer animation
10:54
Computer animation
19:45
Computer animation
Transcript: German(auto-generated)
00:00
Vielen Dank! Ja, Dankeschön für die Anmoderation. Gerne. Ja, eigentlich wollte Pascal den Vortrag selber halten. Jetzt müssen wir halt mit mir Vorlieb nehmen. Datenmigration wie im Flug, Flyway. Alle reden immer über Migration, also gerade so zu der Zeit. Alle migrieren von DS6 auf DS7. Die Frage
00:28
ist, was heißt das eigentlich genau? Wer migriert da? Was? Wohin? Die Community migriert sehr viel. Ja, also von dem Code, der, ich muss vorhin sagen, die DS6 war, hat die Community jetzt
00:41
jahrelang Code migriert. Aber sie haben natürlich unter Umständen selber auch Code produziert in ihren, in ihrer Legacy DS6 Installation, nenne ich das jetzt mal. Das heißt, es gibt Custom Code, der zu migrieren ist. Wenn der im Backend war, muss der auch jetzt wieder ins Backend migriert
01:03
werden. Also sprich, der muss in die Restart geportiert werden. Wenn der im Layout war, und das haben wir heute Morgen schon gehört, das ist eine schlechte Nachricht, sie müssen eigentlich komplett neu schreiben. Mehr oder weniger komplett, komplett in Anführungszeichen, weil was sie machen können, ist HTML, Code und CSS Klassen so ein bisschen weiter zu verwenden.
01:26
Was auch migriert werden muss, natürlich, das ist der Löwenanteil von dem, was die Community nicht migriert, sind Daten, also Bereiche und Sammlungen, die sie angelegt haben, Veröffentlichungen mit ihren Metadaten und ihren Bitstreams und die Nutzungsstatistiken,
01:46
die während der ganzen Zeit vorher angefallen sind auch unter Umständen und auch die Indizes, die immer wieder erstellt wurden. Im Rahmen dieses Vortrags befassen wir uns vor allem mit
02:00
der Migration von Daten, nicht mit der Migration von Code. Datenmigration, welche Technologien werden verwendet? Bei den Statistiken gibt es ein Tool, ich glaube, das ist Bestandteil des DeSpace Commander Sign Tools und das Command nennt sich Solar Export Statistics, damit können sie
02:21
Solar Statistiken aus der Legacy Umgebung exportieren und in die neue Umgebung importieren. Die Indizes, die brauchen sie überhaupt nicht migrieren, die werden neu aufgebaut in der DeSpace 7 Instanz. Die Bitstreams, die wurden ja immer schon in einem Asset Store gespeichert,
02:43
das kann eine Struktur auf der Platte gewesen sein, das kann eine S3 Store gewesen sein. Die können sie einfach kopieren bzw. in der S3 Store einfach weiterverwenden. Spannend wird es jetzt für uns in dem Vortrag bei den Metadaten, Bereichen, Sammlungen, das wird alles in der Relationalen
03:04
Datenbank gespeichert und der Vergangenheit hat DeSpace Oracle und Postgres unterstützt, das ist nunmehr im Sommer glaube ich nicht mehr so, da läuft die Oracle Unterstützung aus. Das heißt, da muss dann sowieso alles auf Postgres migriert werden. Das heißt,
03:24
die Problematik ist, eine neuere Version des Datenbank-Management-Systems fällt unter Umständen eine Migration an, weil Postgres in ihrer Legacy Installation vielleicht nur in der Version 8 oder 9 oder 10 war und DeSpace 7 arbeitet halt mit 11 aufwärts. Genau, die andere
03:51
Problematik ist, unter Umständen müssen sie von Oracle nach Postgres migrieren und was natürlich migriert werden muss und da kommt dann Flyway ins Spiel, ist das Schema, also der Aufbau der
04:06
Datenbank oder die Struktur der Datenbank. Es ist ja so, dass DeSpace 7 eine Reihe von Funktionalitäten hinzufügt, auch im Vergleich zu DeSpace 6, beispielsweise kriegen wir Entitäten dazu, führt natürlich dazu, dass wir in der Datenbank selber unter Umständen auch andere Strukturen
04:25
haben und das erledigt, wie ich später noch an einem Beispiel zeigen werde, Flyway für uns. Wie migrieren wir die Datenbanken am besten oder die Datenbank, über die wir ja reden?
04:43
Die Vorgehensweise, die wir normalerweise verwenden sind, wir lassen zwei Instanzen parallel laufen, sie haben die Legacy-Instanz und sie bauen parallel eine neue DeSpace-Instanz auf und dann zum Zeitpunkt x, wenn sie migrieren wollen, gibt es folgende Migrationsschritte,
05:06
die dann durchgeführt werden. Erstmal müssen sie beide Instanzen offline nehmen, das heißt, sie killen die Servlet-Container, zum Beispiel Tomcat, dann machen sie einen Datenbankdumpf
05:21
von der Legacy-Instanz. Das Resultat davon ist eine SQL-Datei, die da normalerweise rauskommt, es sei denn sie geben dem Postgres-Tool als zu nutzendes Format Custom mit an, was wir aber normalerweise nicht tun. Postgres hat den tollen, das nicht Custom-Format hat den schönen Vorteil,
05:49
dass es SQL ist und dass es menschenlesbar ist. Das heißt, sie sehen tatsächlich, was das Dampf-Fail dann macht. Der zweite Schritt ist, das File zu nehmen, in die neue Instanz zu integrieren,
06:03
das heißt, da einzuspielen, das Dampf-Fail einfach laufen zu lassen, das ja aus SQL-Befehlen besteht. Und der dritte Schritt, also genau, als Resultat haben sie dann sozusagen die alte Datenbank in der neuen Instanz, aber es hat noch das alte Schema und es ist eins zu eins
06:27
eigentlich eine Kopie von der Legacy-Datenbank, aber in der neuen Instanz. Und der dritte Schritt ist dann, das Schema von der Legacy-Instanz auf die Space-7 hochzuziehen und das macht Flyway.
06:41
Schauen wir uns erstmal so einen Datenbank-Dampf an. Wird erzeugt mit pg-dumpf, das ist ein Postgres Tool. Die Problematik dabei ist, pg-dumpf muss bei einem Versionssprung von Postgres, da muss die neuere Version von pg-dumpf den Dampf ausführen. Das heißt, wir müssen pg-dumpf
07:07
von der neuen Instanz in die Lage versetzen, sich gegen den Datenbank-Server der alten Instanz zu connecten. Und sie müssen das pg-dumpf von der neuen Instanz ausführen. Der Befehl, den
07:21
sehen Sie hier unten, den muss ich Ihnen nicht vorlesen, nur der Vollständigkeit halber, dass der hier mal steht. Wichtig ist die Parameter h und p, post und port, weil ich mal vermuten würde, dass das bei den meisten so ist, dass dann die alte und die neue Instanz einfach auch auf unterschiedlichen Rechnern laufen. Heißt, dass sie müssen sozusagen über Rechner hinweg dann
07:44
auch die Instanzen connecten. Genau, Resultat ist dann dieses Output-File, von dem ich die ganze Zeit geredet habe. Das sehen wir uns dann im Detail noch an. Hier mal ein Beispiel davon. Sie sehen, das hat einen Kopf. Da sehen wir auch schon genau, wie der Versionsstand der Datenbank ist,
08:05
die Sie ausgelesen haben damit. Und Sie sehen, mit welcher Version des Tools Sie das ausgelesen haben. Und wie gesagt, die Tool-Version sollte größer gleich der Datenbank-Version sein. Sonst ist nicht gewährleistet, dass das Auslesen vollständig ist. Wie ich gesagt habe, das
08:26
File besteht aus einer Reihe von SQL-Befehlen. Ich habe hier mal für einen einfachen Table das einfach mal dargestellt. Hoppla, jetzt ist da was runtergefallen. Und zwar ein einfacher Table mit
08:43
zwei Spalten. Da wird erstmal das Schema kreiert, also Create Table Befehl. Und der wird dann dem neuen Nutzer, in dem Fall dspace, einfach vergeben. Sie sehen also, das ist lesbar und das sind ganz normale SQL-Befehle. Spannend wird es jetzt. Jetzt kommt nämlich der Teil noch, wo die Daten
09:05
reinkopiert werden. Und da sehen Sie auch, Sie sehen die Menschen lesbar vor sich. Das heißt, das ist auch ein guter Moment möglicherweise, die hier in dem Fall zu editieren, bevor Sie sie wieder einlesen, wenn Sie da irgendwelche Korrekturen machen wollen. Wichtig ist, Sie sehen da ganz am
09:26
Ende diesen Comment, PostgreSQL-Database-dump-complete, der sollte auf jeden Fall drin sein in dem File. Wenn der nicht drin ist, heißt das, der Export ist an irgendeiner Stelle abgebrochen und das File ist nicht vollständig. Also das heißt, an der Stelle müssten Sie prüfen, ob das File vollständig
09:45
ist. So, das war der Schritt auslesen. Kommen wir zu dem Schritt einlesen in den neuen Instanz. Was ich vorher nicht dazu gesagt habe, die Befehle, die geben Sie in einer, in der Shell des Datenbank-Servers.
10:03
Genau, und jetzt muss in der neuen Instanz erstmal die Datenbank gelöscht werden. Weil normalerweise, wenn Sie dspace7 installiert haben, wird die Datenbank angelegt und die müssen erst mal löschen. Und dazu gibt es zwei Wege. Ich sage Ihnen mal beide. Der erste Weg ist, Sie müssen
10:23
die Löschsicherung ausschalten, die dspace7 mitbringt. Das heißt, Sie müssen dbCleanDisabled auf Voll setzen, entweder in der Umgebungsvariablen, das ist dieser Exportbefehl, den wir da sehen, oder in der Konfigurationsdatei, das ist local.cfg oder dspace.cfg. Löschsicherung ausschalten,
10:44
Sie merken schon, das klingt ein bisschen gefährlich. Der Punkt ist nämlich, und deswegen machen wir das nicht so gern, Sie dürfen nicht vergessen, ihn dann wieder einzuschalten. Sonst kann es durch eine Ungeschicklichkeit passieren, dass Sie die Datenbank irgendwann mal löschen und es ist unschön, dann
11:03
die Sicherung wieder aufspülen zu müssen. Vielleicht verlieren Sie dabei auch einen gewissen Stand. Also deswegen, wenn Sie sich zutrauen, dran zu denken, die Sicherung wieder einzuschalten, können Sie das gern so machen. Wir machen das in der Regel anders, weil wir lieber auf Nummer sicher gehen.
11:20
Wir benutzen die Postgres-Tools dafür. Das ist etwas unkomfortabler, aber dafür auch etwas sicherer. Und da gibt es den Postgres-Befehl drop db dspace. Damit droppen Sie einfach die komplette Datenbank, die in Postgres dspace hat. Danach kreieren Sie eine neue, leere Datenbank mit dem create db-Befehl.
11:47
Und danach müssen Sie noch die pg-crypto-Extension in der Datenbank aktivieren. pg-crypto wird von dspace 7 benutzt, um die UUIDs zu generieren. Wird also benötigt. Genau, das ganze steht auch in der
12:06
Dokumentation zur dspace 7 Installation noch mal ausführlicher. So, jetzt haben wir die alte
12:20
Datenbank gelöscht. Also die Datenbank, die bei der Installation angelegt wurde, gelöscht. Wir haben eine neue, leere Datenbank eingefügt. Und jetzt können wir die Kopie der legacy-Datenbank da einlesen. Das passiert, indem einfach diese SQL-Datei, die wir vorher mit dem dump erzeugt
12:44
haben, ausgeführt wird. Und das Resultat ist dann, wenn alles glatt gegangen ist, eine Kopie der legacy-Datenbank auf dem Datenbank-Server der neuen Instanz. Eine Kopie der legacy-Datenbank,
13:01
das heißt, die Datenbank ist noch auf dem alten Stand. Und jetzt kommt Flyway ins Spiel. Flyway ist ein Tool, das Datenbank-Schematar und Daten in der Datenbank per Skript verändern kann. Funktioniert folgendermaßen. Flyway migriert relationale Datenbanken, also sowohl Schema als
13:25
auch Daten und verwendet dabei ein SQL-Skript. Funktioniert so, dass eine Baseline erzeugt wird erst mal. Also das allererste Flyway-Skript, das Sie in dem Verzeichnis sehen werden, wo die Flyways-Kripte stehen, erzeugt ein komplettes Schema auf einem alten Stand, also sozusagen
13:50
das Wurzelschema. Und alles, was danach an Schemaänderungen kam, wurde über Flyways-Kripte auf dieses alte Schema angewendet. Also diese Baseline wird erzeugt als Wurzel und darauf werden alle
14:05
weiteren Migrations-Kripte angewendet. Die Migrations-Kripte werden an einem festen Ort gespeichert, den Flyway kennt. Das heißt, wenn da ein neues Skript drin steht, merkt Flyway das auch und führt das aus. Die Migrations-Skripte haben eine bestimmte Konvention, wie die benannt
14:26
werden. Die weisen Versionsnummern auf. Das heißt, sie sehen den auch an oder Flyway sieht den auch an, in welcher Reihenfolge die ausgeführt werden müssen. In der migrierten Datenbank wird die
14:41
Baseline und die Durchführung der Migration dann noch protokolliert quasi, also in der Tabelle Schema-Version gespeichert. Dieser Tabelle sehen Sie an, auf welchem Migrationsstand die Datenbank tatsächlich ist, also sprich, welche Skripte alle durchgelaufen sind. Und so weiß das
15:00
Tool, welche Skripte schon ausgeführt sind und welche noch ausgeführt werden müssen. Wie sieht so ein Flyway-Skript aus? Ich habe schon gesagt, es ist im Prinzip auch nur eine SQL-Datei mit einer fetten Warnung im Header. Sie sollen die möglichst nicht manuell ausführen,
15:24
obwohl sie das natürlich könnten mit PSQL. Der Punkt ist, wenn wir das tun, ist nicht gewährleistet, dass sich die Datenbank merkt, welche Skripte sie alle schon ausgeführt haben. Das heißt, unter Umständen kommen sie in einen nicht definierten Stand der Datenbank rein. Also
15:42
das sicherste ist, Flyway das machen zu lassen. Und Sie sehen auch, das ist das Flyway-Skript, mit dem die B-Space Entities eingeführt wurden. Da passieren im Prinzip immer nur drei Sachen. Erstmal werden Primärschlüssel, für Primärschlüssel Sequences angelegt,
16:02
damit die Primärschlüssel hochgezählt werden können. Dann wird eine Datenbank Entity Type angelegt mit einer ID und einem Label. Da steht dann sowas wie Person, Organisation, Projekt oder irgendwie sowas mit seinem Primärschlüssel drin. Dann gibt es ein Table Relationship Type. Das ist
16:27
dann schon ein bisschen komplexer. Da steht dann sowas drin, wie ist Autor von und ist Herausgeber von und so weiter. Jeweils von der einen Richtung und von der anderen Richtung ausgelesen. Und dann kommt der Table, wo die eigentlichen Nutzdaten später drin stehen werden, nämlich
16:43
die Beziehungen. Also Person A ist Autor von Publikation B, meines Weges. Auf das Ganze werden noch Indizes gebildet, damit das ein bisschen performanter wird. Ja, und das ist so ein
17:00
typisches Skript, das ein Schema erzeugt. Es gibt noch eine andere Art von Befehlen, die da oft vorkommt in dem Skript. Das hier ist ein Beispiel, wo Daten manipuliert werden. Da wird einfach in der Tabelle eine Spalte geändert, mit einem bestimmten Kriterium. Ja, also sie sehen,
17:23
das ist keine schwarze Magie, sondern sie können das lesen. Sie können das theoretisch editieren und sie sehen den Skripten an, was sie tun. Also es ist keine Black Box. Sie können da reinschauen. Wie ruft man das am besten auf? Ich habe schon gesagt, bitte nicht händisch ausführen. Die
17:43
Flyways-Kripte liegen in diesem Verzeichnis hier. Am besten führt man die aus mit dem dspace-kommando-Zeihentool. Das ist dann dspace-database-migrate-ignored. Ignored deswegen,
18:02
weil es sein kann, dass in ihrer legacy-Installation bestimmte Funktionalitäten nicht gebraucht haben und deswegen die Datenbanken nicht manipuliert haben. Ist jetzt aber beim Sprung auf dspace-7 zwingend nötig, die Migration nachzuziehen. Das heißt, alle Flyways-Kripte,
18:25
die vorher ignoriert wurden, müssen jetzt ausgeführt werden und der Befehl migrate-ignored tut genau das. Der nimmt also auch die Skripte, die vorher ignoriert wurden und führt die aus. Resultat ist dann hoffentlich, dass Sie auf Ihrer neuen Instanz eine Datenbank haben im neuen Schema
18:44
auf der aktuellen Evolutionsstufe mit den Daten zum Zeitpunkt, wo Sie den servlet-container ausgeschaltet haben. Wir prüfen Sie, ob da alles glattgegangen ist. Dazu gibt es auch ein Befehl, das ist jetzt ein bisschen klein, das sieht man in der letzten Reihe sicher nicht. Ich lese den
19:04
kurz vor, dspace-database-info ist wahrscheinlich sehr viel geläufig. Wenn Sie den Befehl eingeben, dann kriegen Sie genau diese Protokolltabelle, von der ich vorher geredet habe, wo Flyway seine Skriptdurchläufe reinschreibt, dann kriegen Sie einen Abzug davon und da steht in der ersten
19:26
Zeile dann Baseline und ansonsten sollten die Skripte der Reihe nach drin stehen, jeweils am Ende mit dem Status Success. Und wenn das der Fall ist, dann ist Ihre Datenbank genau da, wo sie sein sollte. Ja, vielen Dank, das ist es erstmal dafür, aber davon gibt es Fragen.