Ingres is inmiddels alweer een aantal jaren open source en op dit moment zijn er tal van interessante community projecten bezig rondom Ingres. Indien je gebruik wilt maken van open source software en een echt Enterprise DBMS wilt gebruiken, is Ingres volgens Gartner de enige keuze (“How Open Source Impacts the RDBMS Dec. 2008”).

Ikzelf gebruik Ingres al vanaf eind jaren 80, en heb projecten gedaan met Ingres in zeer grote omgevingen. Vanuit een beheerperspectief is de back-up- en-recoverystrategie één van de meest uitdagende klussen die je tegenkomt. Ingres biedt daarvoor meerdere mogelijkheden.

Drie manieren met snapshot

Er zijn verschillende mogelijkheden om binnen Ingres een back-up van je database te maken. De eerste mogelijkheid is het maken van een dump door middel van het copydb commando. Het copydb commando is een tweetrapsraket, waarbij eerste stap het aanmaken van een sql-script is en de tweede stap het werkelijk uitkopiëren van de data. Belangrijk om te weten is dat deze back-up alleen volledig consistent is als de database niet in gebruik is. Indien de database in gebruik is, kunnen halve transacties in de dump terechtkomen.

De tweede manier om een database back-up te maken is via het relocatedb commando. Hiermee kan een kopie van de database gemaakt worden, waarbij alle databaselocaties binair worden gekopieerd. Dit zorgt voor goede prestaties , omdat het kopiëren op het niveau van het OS plaatsvindt zonder overhead van het DBMS. Nadeel is dat de brondatabase niet in gebruik mag zijn.

De derde manier is via het unloaddb commando, dit is een variant op het copydb commando. Unloaddb zal echter ook de systeemtabellen dumpen. Hierdoor is het mogelijk om objecten, zoals rapporten, forms, ABF applicaties, OpenRoad applicaties etc. ook mee te kopiëren. Deze manier kan gebruikt worden om een back-up te maken van een ontwikkeldatabase.

Incrementeel

Alle bovengenoemde methodes hebben één eigenschap gemeen: Er wordt een foto gemaakt van de database. Als de database wijzigt, zal je weer een nieuwe foto moeten maken. Dus stel dat elke nacht om 04:00 uur via copydb een dump gemaakt wordt van de database, en de disks om 16:00 uur dusdanig crashen dat er een restore nodig is, dan zijn alle wijzigingen na 04:00 verloren gegaan.

Met copydb en unloaddb is het mogelijk om een partiële back-up te maken van de database, omdat domweg niet alle tabellen uitgekopieerd dienen te worden, het relocatedb commando is echter altijd een full back-up van de database.

Gelukkig biedt Ingres nog een zeer geavanceerd tool voor het maken van back-ups of het restoren daarvan: Het ckpdb commando. Hiermee is zowel een full back-up, partiële back-up en/of incrementele back-up mogelijk, zowel met als zonder point-in-time recovery. De standaardfunctionaliteit biedt de mogelijkheid om off-line of on-line een back-up te maken. In de online modus kan de database gewoon in gebruik blijven tijdens het maken van een back-up.

Standaard zal ckpdb de gehele database veiligstellen, maar dit is ook mogelijk voor een deel van de tabellen . Dus de keuze voor een partiële back-up of een full back-up. Indien je point-in-time recovery wilt, kan je journalling aanzetten. Hierdoor worden wijzigingen in de database bijgehouden in journal files. Hierdoor kun je de database herstellen naar een willekeurig moment in het verleden.

Een journal file kan gezien worden als een incrementele back-up van de database. Deze journal kan ook afgespeeld worden op een andere database, het zogenaamde log-shipping. Met log-shipping is het mogelijk om een kopie database na te laten ijlen op de productie database. Hierdoor kan makkelijk een hot-standby gerealiseerd worden .

Indien een database meerdere database locaties heeft, kan een back-up maken, ook parallel gebeuren, dus bijvoorbeeld naar meerdere tape streamers. Dit kan optimaal ingeregeld worden aan de hand van de beschikbare CPU’s, memory, io-bandbreedte, tape streamers etc. Dit alles is nog standaard functionaliteit. Echter het is mogelijk om nog veel verder te gaan.

Het ckpdb commando maakt gebruik van een template-bestand. In deze template staan verschillende stappen die uitgevoerd worden op verschillende momenten. Welke stap wordt uitgevoerd op welk moment staat beschreven in een code aan het begin van elke regel in de template file. Deze code is opgebouwd uit vier verschillende karakters en deze karakters hebben een bepaalde betekenis.

Het begin

Het eerste karakter geeft de fase aan van de gehele operatie, De belangrijke stappen zijn hier (B) “Begin”, (W) “Work” , (E) “End”

Het tweede karakter geeft de operatie aan. Dit kan bijvoorbeeld de (S) zijn van Safe (back-up) of de (R) van Restore. Dit kan ook een (E) zijn van Either, dus beide

Het derde karakter geeft het medium aan waar de back-up naar toe gaat. (D) is de Disk en (T) is Tape.

Het laatste karakter geeft weer of het een Tabel level actie is (T) of een database level actie (D). Dit kan ook een (E) zijn van Either, dus beide

Het ckpdb commando bestaat uit drie fases. Een “begin” fase, een “work” fase en een “end” fase. De begin en end fase wordt slechts één maal uitgevoerd per back-up of restore. De “work” fase wordt voor iedere database locatie uitgevoerd.

Bijvoorbeeld:

WSTD = W – Working step, S – Save (back-up), T – To tape, D – Voor de gehele database (full back-up)

BRDT = B – Begin step, R – Restore, D – From Disk, T For one ore more tables. (Partiële restore)

Achter deze code staat een commando. Met dit mechanisme wordt het bij de fase horende commando uitgevoerd.

Binnen deze command file zijn een aantal voorgedefinieerde variabelen bekend die aan de commando’s kunnen worden meegegeven. Hieronder staan een aantal voorbeelden

%A Volledige back-up of restore path (Directory en file naam)

%C Locatie waar de back-up files komen te staan (Directory)

%D Locatie waar de data files van de database staan

%N Aantal database locaties dat meegenomen wordt in de back-up of restore

Dit configuratiebestand waarin alle deze commando’s staan, kan aangepast worden naar eigen wens. Verstandig is hier om een kopie van het origineel te maken en deze aan te passen. Vervolgens kan met de omgevingsvariabele II_CKTMPL_FILE naar deze kopie verwezen worden. Nu kan de kopie aangepast worden en back-up en restore procedure zal aangepast verlopen. De originele file staat in $II_SYSTEM/ingres/files/cktmpl.def

Disk naar disk

Stel dat we de stappen bij elkaar zoeken voor een back-up van de gehele database van disk naar disk:

De eerste stap (wordt maar 1 keer uitgevoerd) :

BSDD: /bin/echo beginning checkpoint to disk %C of %N locations

Vervolgens voor elke data locatie (dus wordt 1 of meer keer uitgevoerd):

WSDD: cd %D; /bin/tar cf %A *

Vervolgens de afsluiting (wordt maar 1 keer uitgevoerd) :

ESDD: /bin/echo ending checkpoint to disk %C of %N locations

De begin en eind fase is slechts een echo naar het scherm

De work-fase is interessant, voor elke database locatie gaan we naar de directorie naar die database locatie (cd %D) en vervolgens maken we met het tar commando een backup naar een volledig path %A.

Dus na een back-up van de gehele database van disk naar disk, zal er voor elke database locatie een tar file zijn met daarin alle files die op die database locatie stonden.

Een restore doet precies het omgekeerde :

BRDD: /bin/echo beginning restore of disk %C of %N locations

WRDD: cd %D; /bin/tar xf %A

EEDE: /bin/echo done with disk operations

Hierin is te zien dat voor elke database locatie de tar file weer uitgepakt wordt. Als laatste stap zou je wellicht ERDD verwachten, maar die bestaat niet dan wordt naar een generieke code gezocht en in dit geval wordt EEDE gevonden (E=End fase, E=Either oftewel Safe of Restore, D=Disk, E=Either oftewel tabel of database

Kortom de standaardprocedure om een back-up of restore te doen op Unix is via het tar command.

Hieronder zien we bijvoorbeeld de nodige verandering als we in plaats van tar, cpio willen gebruiken:

WSDD: cd %D; /bin/ls | /bin/cpio -oc > %A

WRDD: cd %D; /bin/cpio -icmu < %A

Of stel dat we de back-up direct willen compressen (dit is slechts een voorbeeld en niet voor productiedoeleinden):

WSDD: cd %D; /bin/tar cf - * | compress | dd of=%A

WRDD: cd %D; dd if=%A | uncompress | /bin/tar xf –

Het is ook mogelijk om een script aan te roepen in plaats van direct commando's te geven. Bijvoorbeeld:

BSDD: $II_SYSTEM/ingres/custom/start_db_backup_disk2disk %D %A %N %C

WSDD: $II_SYSTEM/ingres/custom/work_db_backup_disk2disk %D %A %N %C

ESDD: $II_SYSTEM/ingres/custom/end_db_backup_disk2disk %D %A %N %C

In deze scripts is werkelijk alles mogelijk wat het besturingssysteem te bieden heeft. Van het klonen van bestandssystemen tot het aansturen van taperobots . Denk ook aan de situatie waar data buiten de database staat, maar wel als integraal onderdeel van de database gezien moet worden (documenten, images, xml-files, ongestructureerde data). Deze scripts bieden je de mogelijkheid om data in de database als wel data buiten de database gelijktijdig veilig te stellen. Scripts bieden ook het grote voordeel om aan robuuste foutafhandeling te doen zodat bij een eventueel probleem de back-up of restore procedure weet dat iets niet helemaal goed is gegaan.

Belangrijk is om het risico aan te geven van het veranderen van de back-up en recovery procedures. Alleen door zeer grondig testen van zowel de back-up als wel de restore kun je vaststellen of dit werkt. Indien procedures veranderd worden, kan Ingres.com (de makers van ingres) natuurlijk niet garant staan voor een juiste werking. De Ingres Systeembeheerders of DBA’s zijn hiervoor zelf verantwoordelijk. Neemt niet weg dat ik ervan overtuigd ben dat voor databases, van superklein tot megagroot, een back-upstrategie te bedenken en te implementeren valt die past bij de eisen en wensen van de organisatie. Door de brede ondersteuning van back-upmogelijkheden is dit dikwijls in zeer korte tijd goed in te regelen.

Michel Sijmons is sinds 1990 eigenaar van Nibble Consultancy, een bedrijf van oudsher gespecialiseerd op beheer van zeer grote databases. Nibble positioneert haar oplossingen zo veel mogelijk met het combineren van verschillende open source producten en open source ontwikkeltools. Bron: Techworld