5 Minuten Lesezeit (1045 Worte)

Der neue Mieter: Informix Tenant Migration mit Loopback Replication

Freitag, 07. Mai 2021

Schon seit jeher beinhaltet jede Instanz des Informix Dynamic Servers multiple Datenbanken. Seit Version 12.10 kennt Informix auch Tenant-Datenbanken. Obwohl diese auf den ersten Blick ähnlich zu normalen Datenbanken aussehen, haben sie eine Reihe von Vorteilen:

Ressourcen wie Memory- oder CPU-Nutzung einer Tenant-Datenbank lassen sich dynamisch zur Laufzeit skalieren. Normale Datenbanken bedienen sich aus einem Pool von Ressourcen.
Durch Limitierung des Logspaces von Tenant-Datenbanken lassen sich blockierende Long Transactions weitestgehend vermeiden, die sonst alle (sowohl Tenant- als auch nicht-Tenant-) Datenbanken betreffen würden.
Es ist möglich, Tenant-Datenbanken separat aus einer onbar-Sicherung wiederherzustellen. Bei normalen Datenbanken war dazu immer ein kompletter Restore aller Datenbanken nötig, sodass auch Datenbanken, die nicht von einem Problem betroffen waren, zurückgesetzt wurden.

Anlegen lässt sich eine Tenant-Datenbank nicht etwa mit dem üblichen create database-Befehl, sondern mit der sysadmin-Funktion task oder admin und der Option tenant create, etwa:

dbaccess sysadmin -
> execute function task ('tenant create' , 'stores_tenant' , '{dbspace:"stores_tenant"}');

Dabei ist zu beachten, dass der gewählte Dbspace leer sein muss und auch nur von einer Tenant-Datenbank genutzt werden kann.

Nun stellt sich die Frage, ob und wie sich eine existierende, normale Datenbank in eine Tenant-Datenbank migrieren lässt. Je nach Größe der Datenbank lassen sich verschiedene Herangehensweisen wählen.

dbexport / dbimport

Prinzipiell steht immer der Weg über dbexport/dbimport offen, auch wenn diese Methode nur bei kleineren Datenbanken, oder bei solchen, die eine längere Downtime in Kauf nehmen können, gewählt werden sollte.
Nun zeigt sich beim Import eine Herausforderung: Eine Tenant-Datenbank muss bereits vor dem Import angelegt werden, aber dbimport würde seinerseits versuchen, die Datenbank anzulegen.

dbimport stores_tenant
*** create database
330 - Cannot create or rename the database.
100 - ISAM error:  duplicate value for a record with unique key.

Hier hilft Option -exists. Diese Option ist noch undokumentiert, obwohl sie bereits seit längerer Zeit existiert.

dbimport stores_tenant -exists
...
dbimport completed

Loopback Replication

Ab dem Fixpack 12.10.xC11 oder ganz offiziell ab Version 14.10 unterstützt Informix die Loopback Replication. Dabei handelt es sich um eine Erweiterung der Enterprise Replication, bei der auf dieselbe Informix-Instanz zurück repliziert wird. Allgemein lässt sich Enterprise Replication gut zur Migration großer Datenbanken mit geringer Downtime verwenden.

Die üblichen Voraussetzungen für ER können online umgestellt werden:

Die Datenbank muss mit Logging betrieben werden (zu erreichen mit ontape oder ondblog)
Es muss ein SmartBlobSpace angelegt werden, welcher als Spooler für die übertragenen Zeilen dient. Nach dem Anlegen kann dieser online mit dem folgenden Kommando zur onconfig hinzugefügt werden:
cdr change onconfig "CDR_QDATA_SBSPACE cdr_sbspace"
Tabellen, die repliziert werden sollen, müssen einen Primary oder Unique Key haben. Tabellen, die darüber nicht verfügen, können mit Shadow Columns (ERKEYs) versehen werden. Dadurch werden die rows für Enterprise Replication eindeutig identifizierbar:
alter table ... add erkey;

Zur onconfig fügt man einen neuen (frei wählbaren) Namen als TCP-Alias für den Loopback hinzu. Der Alias darf nicht der Hauptname sein.

DBSERVERNAME      ids1410
DBSERVERALIASES   loopback

Die sqlhosts wird wie üblich mit Gruppennamen erweitert. Dabei bekommt jeder Alias seine eigene Nummer

me         group       -       -           i=1
ids1410    onsoctcp   linux    sqlexec     g=me
myself     group      -        -           i=2
loopback   onsoctcp   linux    loopback    g=myself

Der Listener dazu kann online gestartet werden:

onmode -P start loopback

Jetzt kann die Loopback Replication gestartet werden. Die Loopback-Verbindung muss als Nonroot-Knoten definiert werden:

cdr define server --init me
cdr define server --sync=me --nonroot --init myself

Eine komfortable Methode ist hier, ein Template vorzubereiten, welches wir to_tenant nennen, und das alle Tabellen der Datenbank stores7 einschließen soll. Replikate werden dadurch noch nicht automatisch erstellt. Diese Methode eignet sich, wenn bei der Migration die Datenbankstruktur übernommen werden soll.

cdr define template to_tenant --master=me \
--conflict=always --database=stores7 --all

In einigen Versionen der 12.10 funktioniert das Anlegen der Templates trotz Shadow Columns nicht. In der 14.10 ließ sich das so nicht mehr beobachten.

Das Erstellen der Replikate kommt nun im nächsten Schritt. Ausgehend von der Ursprungsdatenbank sollen die Replikate auf die Tenant-Datenbank gehen. Dabei sollen alle noch nicht existierenden Tabellen angelegt werden. Die einzelnen Replikate werden dabei zu einer Menge (replset) zusammengefasst.

cdr realize template to_tenant \
stores7@me \
stores_tenant@myself  \
--autocreate

Man beachte, dass bei der "autocreate"-Methode Partitionierung und Detached Columns oder Detached Indizes unberücksichtigt bleiben und unpartitioniert/attached angelegt werden. Auch andere Konstrukte wie Views, Synonyme oder Row Types werden ebenfalls nicht mit übertragen und müssen manuell am Ziel erstellt werden.

Eine Synchronisierung der Daten kann mit dem entsprechenden Befehl erreicht werden:

cdr sync replicateset --replset=to_tenant --master=me myself

Dabei ist zu beachten, dass dies je nach Umfang der Daten viele Ressourcen beanspruchen kann. Ein Monitoring der Datenbankserver und Nachjustierung der CDR-Einstellungen kann nötig werden. Auch kann es zielführender sein, die Replikate einzeln statt gebündelt zu synchronisieren.

Inhaltliche Änderungen an der Ursprungsdatenbank übertragen sich auf die Zieldatenbank. Zum Zeitpunkt der letztendlichen Umstellung nimmt man die Anwendung offline und synchronisiert erneut wie oben beschrieben. Sobald die Sende-Queue in der Progress Table leer ist (onstat -g rqm SENDQ), kann die Umstellung auf die neue Datenbank erfolgen.

Die CDR-Konfiguration und die Shadow Columns dürfen nach erfolgreicher Übernahme wieder entfernt werden. Damit ist die Migration abgeschlossen.

Man beachte, dass Tenant-Datenbanken nicht umbenannt werden können.

Fazit

Eine Migration auf Tenant-Datenbanken funktioniert sowohl althergebracht mit dbexport/dbimport als auch mit der neuen Loopback-Methode. Mit ein paar Abstrichen beim manuellen Anlegen funktioniert der Umstieg auf Tenant-Datenbanken in der 14.10.

Glossar

Long Transaction
Wenn eine Transaktion über einen bestimmten Prozentsatz von verbrauchtem Logspace hinausgeht, wird sie zu einer Long Transaction und wird zurückgerollt. Sollte das Zurückrollen ebenfalls noch einen bestimmten Prozentsatz an Logspace übersteigen, so kann es zu einer Blockade für andere Transaktionen (auch anderer Datenbanken) kommen, da dem Zurückrollen höchste Priorität eingeräumt wird.

Enterprise Replication (ER)
Eine logische Replikationsmethode, bei der Tabellen(-inhalte) auf einen anderen Informix-Server übertragen werden können. Auch unter Continuous Data Replication (CDR) bekannt.

Detached Index / Column
Dabei handelt es ich um Indizes und Large-Object-Spalten, die in einen separaten Dbspace ausgelagert werden. Das kann zu Performancevorteilen oder besserer Nutzung der Dbspaces führen. Ohne explizite Auslagerung sind Indizes und Spalten attached.

Partitionierung
Hierbei werden Tabellen in mehrere Fragmente aufgeteilt, üblicherweise in separate Dbspaces. Auch hier sind oft Performance-Steigerungen zu erreichen. Partitionierung funktioniert nur mit den Informix Enterprise Editions.

{loadmoduleid 179}