Cloud | Nerdpol-Blog

Ich darf in den letzten Monaten beruflich häufiger Datenbanken aus Rechenzentren nach AWS RDS migrieren. Ich gebe gerne zu, dass RDS ein großartiges Framework ist, durch das man sich nicht mehr um Installation, Konfiguration, Backup, Restore und Patching einer Datenbank kümmern muss und es dadurch bedeutend einfacher ist, Software einzusetzen, die man nicht so sehr im Detail kennt. Damit RDS so nutzbar ist, hat AWS eine eigene Konfektionierung entwickelt. Einige Funktionen sind somit leider nicht verfügbar. Da ich während meiner Arbeit immer wieder mal auf derartige Hürden stoße, möchte ich gerne über diese berichten.

Oracle

Oracle ist meiner persönlichen Meinung nach das beste relationale Datenbankmanagementsystem – jedoch auch das teuerste. Daher sollte man meiner Meinung nach auch wirklich nur Oracle einsetzen, wenn man einige Besonderheiten davon nutzen möchte.

Dateisystemschnittstellen

In eine Oracle-RDS kann man leider keine NFS-Shares von EFS oder anderen Storage mounten. Dadurch gibt es nur zwei Wege in die RDS herein und heraus:

Nutzung eines S3-Buckets als Intermediate-Storage
Upload nach S3, Download in RDS / Upload nach S3, Download nach App-Server, Schnittstellensystem, etc.
Direktkopie via Datenbanklink und DBMS_FILETRANSFER. Dazu muss jedoch die andere Quelle eine Oracle-Datenbank haben und ist daher nicht zwingend geeignet.

Ich arbeite mit Schnittstellensystemen, die Dateien von oder zur Datenbank über NFS oder SMB direkt übertragen möchten. Das ist hier leider nicht möglich.

PostgreSQL

Authentifizierung mit Zertifikaten

Bei einem Projekt wollten wir eine Authentifizierung über Zertifikate mit der Datenbank einrichten. Dies entfällt leider, da man bei RDS weder die pg_hba.conf direkt bearbeiten, noch die SSL-Zertifikate mit eigenen ersetzen kann.

Was soll ich tun, wenn ich auf derartige Probleme stoße?

Tja, schwierig. Wenn man auf derartige Probleme stößt, ist die eingesetzte Software eigentlich nicht “cloud-ready”. Als Alternative kann man bspw. Oracle oder PostgreSQL manuell auf einer EC2 installieren. Dadurch gehen jedoch die Automatisierungseffekte verloren, die einem die Administration so signifikant vereinfachen.

Bei einem Import eines Datapump-Dumps in eine Oracle-RDS-Umgebung fiel neulich folgende Problematik auf:

Ich hatte eine Rolle, die ich nicht granten konnte und das, obwohl ich mit dem RDS-Master-User arbeite. Es zeigte sich, dass ich keine GRANTs verteilen konnte, weil mir die ADMIN OPTION für diese Rolle fehlte. Leider habe ich die genaue Fehlermeldung nicht mehr parat. Da ich bei RDS auch keine SYS-Privilegien besaß, konnte ich nicht die ADMIN OPTION nachträglich setzen.

Zur Validierung habe ich erneut eine Rolle angelegt und gesehen, dass ich auch automatisch die ADMIN OPTION bei Erstellung erhalte.

CREATE ROLE TESTROLE_A NOT IDENTIFIED;

-- Grantees of TESTROLE_A
GRANT TESTROLE_A TO DB_ADMIN WITH ADMIN OPTION;

Somit bin ich zum Ergebnis gekommen, dass die Rolle von Datapump leider allgemein ohne einen einzigen Administrator importiert wurde und somit zwar allgemein nutzbar, aber nicht mehr administrierbar ist. Da man bei AWS nicht an die SYS-Privilegien herankommt und zur Modifizierung der Rolle die rdsadmin.rdsadmin_util.grant_sys_object-Prozedur nicht hilfreich ist, blieb mir nichts übrig, als manuell die Rolle zu löschen und erneut anzulegen.