Amazon Relational Database Service (Amazon RDS) ist ein Web-Service zum einfachen Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud. Sie stellt kostengünstige und anpassbare Kapazitäten zur Verfügung und erledigt gleichzeitig zeitraubende Datenbankverwaltungsaufgaben, sodass Sie sich stärker auf Ihre Anwendungen und Ihr Unternehmen konzentrieren können.

Amazon RDS bietet Ihnen Zugriff auf den Funktionsumfang einer vertrauten MySQL-, Oracle– oder SQL Server-Datenbank. Das bedeutet, dass der Code, die Anwendungen und die Tools, die Sie heute mit Ihren bestehenden MySQL-Datenbanken nutzen, nahtlos in Amazon RDS funktionieren sollten. Amazon RDS führt automatisch Patches der Datenbank-Software durch und erstellt Backups Ihrer Datenbank. Diese Backups werden für einen vom Benutzer definierten Zeitraum aufbewahrt. Ein weiterer Vorteil für Sie ist die flexible Skalierung der Rechenressourcen oder der Speicherkapazität für die Instanz Ihrer relationalen Datenbank über einen einzigen API-Aufruf oder einige Klicks in der AWS Management Console. Darüber hinaus können Sie mit Amazon RDS einfach mithilfe von Replizierung (derzeit nur mit MySQL und Oracle möglich) die Datenbankverfügbarkeit und die Datenbeständigkeit verbessern oder über Kapazitätsgrenzen einer einzelnen Datenbank-Instance hinaus skalieren, wenn Sie Datenbankarbeitslasten mit umfassenden Lesevorgängen haben. Wie bei allen Amazon Web Services fallen keine Vorabkosten an, und Sie zahlen nur für die Ressourcen, die Sie tatsächlich nutzen.

F: Was ist eine Database Instance (DB Instance)?

Man kann sich eine DB Instance als eine Datenbank-Umgebung in der Cloud vorstellen, die über die vom Benutzer festgelegten Rechen– und Speicherressourcen verfügt. Mithilfe der AWS Management Console, der Amazon RDS-APIs und der Befehlszeilen-Tools können Sie DB Instances erstellen und löschen, Infrastrukturattribute der DB Instance(s) definieren bzw. weiterentwickeln und den Zugriff und die Sicherheit kontrollieren. In einer vorhandenen DB-Instance können mehrere MySQL– oder SQL Server-Datenbanken (bis zu 30) oder Oracle-Datenbankschemas erstellt werden.

F: Was verwaltet Amazon RDS für mich?

Amazon RDS verwaltet die mit der Einrichtung einer relationalen Datenbank verbundenen Arbeitsschritte, von der Bereitstellung der gewünschten Infrastrukturkapazität bis hin zur Installation der Datenbank-Software. Sobald Ihre Datenbank auf der eigenen DB Instance ausgeführt wird, automatisiert Amazon RDS allgemeine administrative Aufgaben, z. B. die Durchführung von Backups und die Aktualisierung der Datenbank-Software mit Patches. Für optionale Multi-AZ-Bereitstellungen (derzeit mit MySQL und Oracle möglich) verwaltet Amazon RDS auch die synchrone Datenreplizierung über mehrere Availability Zones hinweg und den automatischen Failover.

Dank des nativen Datenbankzugriffs in Amazon RDS interagieren Sie mit der Software der relationalen Datenbank auf die übliche Weise. Das bedeutet, dass Sie immer noch für die Verwaltung der anwendungsspezifischen Datenbankeinstellungen verantwortlich sind. Sie müssen das relationale Schema entwickeln, das am besten für Ihren Anwendungsfall geeignet ist, und zudem die Leistung Ihrer Datenbank für die Auftragsabläufe Ihrer Anwendung optimieren.

F: Wann sollte ich Amazon RDS anstatt Amazon-EC2-AMIs für relationale Datenbanken, Amazon SimpleDB oder Amazon DynamoDB nutzen?

Amazon Web Services bietet eine Reihe verschiedener Datenbanklösungen für Entwickler an. Mit Amazon RDS kann eine voll funktionsfähige relationale Datenbank ausgeführt und gleichzeitig die Datenbankverwaltung vereinfacht werden. Amazon SimpleDB bietet einfache Indizierungs– und Abfragefunktionen mit nahtloser Skalierbarkeit. Amazon DynamoDB ist ein vollständig verwalteter NoSQL-Datenbankservice, der schnelle und planbare Leistung mit nahtloser Skalierbarkeit bietet. Und mit dem Einsatz einer unserer zahlreichen AMIs für relationale Datenbanken in Amazon EC2 und Amazon EBS können Sie zudem Ihre eigene relationale Datenbank in der Cloud betreiben. Zwischen diesen Alternativen gibt es wichtige Unterschiede, daher sollte gut überlegt sein, welche für Ihre Bedürfnisse am besten geeignet ist. Auf der Seite Betreiben von Datenbanken mit AWS erfahren Sie mehr darüber, welche Lösung am besten für Sie geeignet ist.

F: Welche ersten Schritte sind für die Benutzung von Amazon RDS notwendig?

Um sich für Amazon RDS anzumelden, klicken Sie auf der Detailseite von Amazon RDS auf die Schaltfläche "Sign up for Amazon RDS" und führen Sie den Anmeldevorgang durch. Hierfür ist ein Amazon-Web-Services-Konto erforderlich. Wenn Sie bisher noch kein Konto eröffnet haben, werden Sie zur Erstellung eines Kontos aufgefordert, wenn Sie sich bei Amazon RDS anmelden. Nach der Anmeldung für RDS lesen Sie sich bitte die Dokumentation zu Amazon RDS durch, die das Handbuch "Erste Schritte" enthält.

Wenn Sie sich mit Amazon RDS vertraut gemacht haben, können Sie in wenigen Minuten eine DB Instance mithilfe der AWS Management Console oder der Amazon RDS-APIs starten.

F: Wie erstelle ich eine DB Instance?

DB Instances sind einfach zu erstellen. Sie können hierfür entweder die AWS Management Console, Amazon RDS-APIs oder Befehlszeilen-Tools verwenden. Um eine DB Instance über die AWS Management Console zu starten, klicken Sie auf die Schaltfläche "Launch DB Instance" (DB Instance starten) unter der Registerkarte "Amazon RDS". Von dort aus können Sie die DB Instance-Verarbeitungsklasse, den zugewiesenen Speicher, den DB Engine, die Version der DB Engine (optional), das Lizenzmodell (optional), die DB Instance-Kennung, den Master-Benutzernamen und das Master-Benutzerpasswort Ihrer DB Instance angeben und festlegen, ob Ihre DB Instance als Multi-AZ-Bereitstellung betrieben werden soll. Darüber hinaus haben Sie die Möglichkeit, die Backup-Aufbewahrungsrichtlinie, das bevorzugte Backup-Fenster und das Fenster für geplante Aktualisierungen für Ihre DB Instance zu ändern. Alternativ können Sie Ihre DB Instance auch mithilfe der API "CreateDBInstance" oder über den Befehl rds-create-db-instance erstellen.

F: Wie kann ich auf eine ausgeführte DB Instance zugreifen?

Sobald Ihre DB Instance verfügbar ist, können Sie deren Endpunkt über die DB Instance-Beschreibung in der AWS Management Console oder über die API "DescribeDBInstance" abrufen. Mithilfe dieses Endpunkts können Sie die für eine direkte Verbindung zu Ihrer DB Instance erforderliche Zeichenfolge erstellen und dabei Ihr bevorzugtes Datenbank-Tool bzw. Ihre bevorzugte Programmiersprache verwenden. Um für Ihre ausgeführte DB Instance Netzwerkanfragen zu ermöglichen, müssen Sie den Zugriff autorisieren. Eine ausführliche Anleitung zur Erstellung der Verbindungszeichenfolge sowie Hinweise zu den ersten Schritten finden Sie im Handbuch "Erste Schritte".

F: Wie viele DB Instances kann ich mit Amazon RDS ausführen?

Standardmäßig können die Kunden über bis zu 20 Amazon RDS DB Instances verfügen. Von diesen 20 können bis zu 10 Oracle– oder SQL Server-DB-Instances unter das Modell "License Included" (Lizenz eingeschlossen) fallen. Alle 20 können für MySQL, Oracle oder SQL Server gemäß dem "BYOL"-Modell (Verwendung der eigenen Lizenz) genutzt werden. Wenn Sie für Ihre Anwendung mehr als 20 DB Instances benötigen, können Sie weitere DB Instances über dieses Formular anfordern.

F: Wie importiere ich Daten in Amazon RDS?

Es gibt verschiedene einfache Möglichkeiten, Daten in Amazon RDS zu importieren, z. B. die Hilfsprogramme „mysqldump“ oder „mysqlimport” für MySQL; Data Pump, „Import/Export“ oder SQL Loader für Oracle und der Import/Export-Assistent und das Bulk Copy Program (BCP) für SQL Server. Weitere Informationen zum Im– und Exportieren von Daten finden Sie im Datenimporthandbuch für MySQL, Datenimporthandbuch für Oracle und Datenimporthandbuch für SQL Server.

F: Welche relationalen Datenbanksysteme werden von Amazon RDS unterstützt?

Amazon RDS unterstützt derzeit MySQL 5.1 und 5.5 (Community Edition) mit InnoDB als standardmäßige Datenbank-Storage-Engine, Oracle Database 11gR2 und SQL Server 2008 R2.

Falls Sie MySQL verwenden, können Sie für optionale Kontrolle über die MySQL Nebenversion für Ihre DB Instance das Amazon RDS MySQL DB Engine Version Management verwenden.

Falls Sie Oracle verwenden, können Sie für die optionale Kontrolle über die Patch-Ebene Ihrer DB Instance das Amazon RDS Oracle DB Engine Version Management nutzen.

Falls Sie SQL Server verwenden, können Sie für die optionale Kontrolle über die Patch-Ebene Ihrer DB Instance das Amazon RDS SQL Server DB Engine Version Management nutzen.

F: Welche Speicher-Engines unterstützt Amazon RDS für MySQL?

Die Funktionen "Point-In-Time-Restore" und "Snapshot-Restore" von Amazon RDS for MySQL benötigen eine Speicher-Engine, die im Falle eines Ausfalls wiederhergestellt werden kann. Sie werden nur für InnoDB-Speicher-Engines unterstützt. MySQL unterstützt zwar mehrere Speicher-Engines mit unterschiedlichen Fähigkeiten und Kapazitäten, jedoch sind nicht alle von ihnen für die Wiederherstellung nach Ausfall und für Datenbeständigkeit optimiert. Beispielsweise unterstützt die MyISAM-Speicher-Engine kein zuverlässiges Crash Recovery und kann zu Datenverlust oder –beschädigung führen, wenn MySQL nach einem Ausfall neu gestartet wird. Daher können die Funktionen Point-In-Time-Restore oder Snapshot-Restore nicht wie beabsichtigt ausgeführt werden. Möchten Sie MyISAM trotzdem mit Amazon RDS verwenden, befolgen Sie diese Schritte, die in bestimmten Szenarios der Snapshot-Restore-Funktion hilfreich sein können.

Wenn Sie vorhandene MyISAM-Tabellen in InnoDB-Tabellen umwandeln möchten, können Sie den Befehl alter table verwenden (z. B. alter table TABLE_NAME engine=innodb;). Beachten Sie jedoch, dass MyISAM und InnoDB über unterschiedliche Stärken und Schwächen verfügen. Sie sollten daher vor dem Wechsel die Auswirkungen auf Ihre Anwendung umfassend auswerten.

Darüber hinaus wird die Federated Storage Engine aktuell von Amazon RDS für MySQL nicht unterstützt.

F: Was ist ein Aktualisierungsfenster? Steht meine DB Instance während der Softwareaktualisierung zur Verfügung?

Das Amazon RDS-Aktualisierungsfenster bietet gewissermaßen die Möglichkeit, zu kontrollieren, wann Modifizierungen der DB Instance (z. B. eine Skalierung der DB Instance-Klasse) oder Software-Patches vorgenommen werden, sollten diese angefordert oder notwendig werden. Wenn ein "Wartungs"-Ereignis für eine bestimmte Woche angesetzt ist, wird es zu einem Zeitpunkt innerhalb des von Ihnen festgelegten, vierstündigen Wartungsfensters begonnen und abgeschlossen.

Die einzigen Aktualisierungsarbeiten, bei denen Amazon RDS Ihre DB Instance offline nehmen muss, sind Skalierungen des Datenverarbeitungsbetriebs (die in der Regel nur wenige Minuten in Anspruch nehmen) sowie erforderliche Software-Patches. Erforderliche Patches werden automatisch und nur für Patches, die relevant für die Sicherheit und Zuverlässigkeit sind, angesetzt. Diese Patches erfolgen in unregelmäßigen Abständen (in der Regel einmal alle paar Monate) und sollten selten mehr als einen Bruchteil Ihres Aktualisierungsfensters in Anspruch nehmen. Falls Sie kein bevorzugtes Aktualisierungsfenster festlegen, wenn Sie Ihre DB Instance erstellen, wird ein 30-minütiger Standardwert zugewiesen. Wenn Sie den Zeitpunkt der Aktualisierungen modifizieren möchten, können Sie hierfür Ihre DB Instance in der AWS Management Console oder mithilfe der API "ModifyDBInstance" modifizieren. Dabei haben Sie die Möglichkeit, für die einzelnen DB Instances unterschiedliche bevorzugte Aktualisierungsfenster anzugeben.

Wenn Sie Ihre DB Instance als Multi-AZ-Bereitstellung ausführen, können Sie die Auswirkungen der Aktualisierungsarbeiten weiter reduzieren, da Amazon RDS die Aktualisierungen zunächst an der Standby-Replika vornimmt, diese dann zur Primärinstanz hochstuft und dann die alten Primärdaten aktualisiert, die daraufhin die Rolle der neuen Standby-Replika einnehmen.

Weitere Informationen zur Verwendung der APIs oder der Befehlszeilenschnittstelle zur Festlegung Ihres Aktualisierungsfensters finden Sie im Amazon-RDS-Entwicklerhandbuch. Klicken Sie hier für weitere Informationen zu Multi-AZ-Bereitstellungen.

F: Was soll ich tun, wenn die Ausführung meiner Abfragen langsam erscheint?

Falls Sie MySQL verwenden, haben Sie für Ihre Datenbank Zugriff auf die Protokolle zu langsamen MySQL-Abfragen. Daraus können Sie erkennen, ob langsame SQL-Abfragen vorhanden sind und, falls dies der Fall ist, die Leistungsmerkmale der einzelnen Abfragen feststellen. Sie können den DB-Parameter "slow_query_log" bestimmen und die Tabelle mysql.slow_log abfragen, um die langsamen SQL-Abfragen zu überprüfen. Weitere Informationen finden Sie im Amazon RDS-Benutzerhandbuch.

Falls Sie Oracle verwenden, können Sie Oracle Ablaufdateidaten verwenden, um langsame Abfragen zu identifizieren. Für weitere Informationen zu Ablaufdateidaten lesen Sie bitte das Amazon RDS Benutzerhandbuch.

Falls Sie SQL Server verwenden, können Sie die SQL Server-Ablaufverfolgungsprotokolle auf Client-Seite zum Bestimmen langsamer Abfragen nutzen. Weitere Informationen für den Zugriff auf die Daten in der Ablaufverfolgungsdatei auf Serverseite finden Sie im Amazon RDS-Benutzerhandbuch.

Darüber hinaus haben Sie die Möglichkeit, über Amazon CloudWatch die Werte der CPU-Auslastung für Ihre DB Instance zu überprüfen. Eine erhöhte CPU-Auslastung kann die Abfrageleistung verringern. In diesem Fall könnte sich eine Skalierung Ihrer DB Instance-Klasse anbieten. Weitere Informationen zur Überwachung der CPU-Auslastung finden Sie im Amazon RDS-Handbuch zur Überwachung.

Fakturierung

F: Wie wird mir die Nutzung von Amazon RDS in Rechnung gestellt?

Sie zahlen nur für das, was Sie tatsächlich nutzen. Es gibt keine Mindest– oder Einrichtungsgebühren. Ihre Nutzung wird folgendermaßen abgerechnet:

DB Instance-Stunden – diese basieren auf der Klasse (z. B. Standard Small, Large, Extra Large) der genutzten DB Instance. Angefangene DB Instance-Stunden werden als volle Stunden in Rechnung gestellt.
Speicherung (pro GB und Monat) – die Speicherkapazität, die Sie Ihrer DB Instance zur Verfügung gestellt haben. Bei einer Skalierung der zur Verfügung gestellten Speicherkapazität im laufenden Monat werden die Gebühren entsprechend anteilig erfasst.
E/A-Anfragen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranfragen.
Bereitgestellte IOPS – Ihnen werden die IOPS und der Speicher, den Sie bereitstellen, jeden Monat berechnet, gleichgültig ob Sie sie verwenden oder nicht. Wenn Sie bereitgestellte E/A\Sek. verwenden, werden Ihnen E/A-Anforderungen nicht in Rechnung gestellt. Wenn Sie E/A-intensive Arbeitslasten haben, können Sie möglicherweise Geld sparen, indem Sie auf bereitgestellte IOPS umstellen.
Backup-Speicher – der Backup-Speicher ist der Speicher für Ihre automatisierten Datenbank-Backups und jegliche selbst erstellten aktiven Datenbank-Snapshots. Wenn Sie die Aufbewahrungszeit Ihrer Backups erhöhen oder zusätzliche Datenbank-Snapshots erstellen, belegt Ihre Datenbank dementsprechend mehr Backup-Speicher. Amazon RDS bietet ohne Aufpreis eine Backup-Speicherung von bis zu 100 % Ihres bereitgestellten Datenbankspeichers. Wenn Sie beispielsweise über einen bereitgestellten Datenspeicher von monatlich 10 GB verfügen, bieten wir Ihnen ohne Aufpreis bis zu 10 GB Backup-Speicher pro Monat. Nach unserer eigenen Erfahrung als Datenbankadministratoren benötigen die weitaus meisten Datenbanken weniger reinen Speicher für das Backup als für den primären Datensatz, d. h., dass unsere Kunden in der Regel nie für Backup-Speicher zahlen müssen. Der Backup-Speicher ist nur für aktive DB Instances kostenlos.
Datenübertragung – ein– und ausgehende Internet-Datenübertragung Ihrer DB Instance.

Informationen zu den Preisen von Amazon RDS finden Sie auf der Amazon-RDS-Produktseite.

F: Wann beginnt und endet die Fakturierung meiner Amazon-RDS-DB-Instances?

Die Fakturierung einer DB Instance beginnt zu dem Zeitpunkt, ab dem die Instanz verfügbar ist. Die Fakturierung wird so lange fortgesetzt, bis die DB Instance durch Löschen oder aufgrund eines Ausfalls beendet wird.

F: Wie werden abrechnungsfähige Amazon-RDS-Instanzstunden definiert?

Die Abrechnung erfolgt für jede Stunde, in der die DB Instance in einem verfügbaren Zustand ausgeführt wird. Wenn Sie für die DB Instance keine Gebühren mehr zahlen möchten, müssen Sie sie beenden, damit Ihnen keine weiteren Instanzstunden in Rechnung gestellt werden. Angefangene DB-Instance-Stunden werden als volle Stunden in Rechnung gestellt.

F: Warum ist ein zusätzlicher Backup-Speicher teurer als der zugewiesene DB Instance-Speicher?

Der Speicher, der Ihrer DB Instance für Ihre primären Daten zur Verfügung gestellt wird, befindet sich in einer einzigen Availability Zone. Beim Backup Ihrer Datenbank werden die Backup-Daten (einschließlich der Transaktionsprotokolle) für eine höhere Datenbeständigkeit georedundant in mehreren Availability Zones repliziert. Der Preis für die Backup-Speicherung, der über die kostenlose Zuordnung hinausgeht, spiegelt diese zusätzliche Replizierung wider, die durchgeführt wird, um die Beständigkeit Ihrer kritischen Backups zu maximieren.

F: Wie werden Bereitstellungen von Multi-AZ DB Instances abgerechnet?

Wenn Sie festlegen, dass Ihre DB Instance als Multi-AZ-Bereitstellung genutzt wird, wird entsprechend den Multi-AZ-Preisen, die auf der Seite zu den Amazon RDS-Preisen einzusehen sind, abgerechnet. Der Multi-AZ-Abrechnung liegen folgende Faktoren zu Grunde:

Multi-AZ DB Instance-Stunden – diese basieren auf der Klasse (z. B. Small, Large, Extra Large) der genutzten DB Instance. Wie bei Standardbereitstellungen in einer einzelnen Availability Zone werden angebrochene DB Instance-Stunden als ganze Stunden in Rechnung gestellt. Wenn Sie innerhalb einer angebrochenen Stunde zwischen einer DB Instance-Standardbereitstellung und einer Multi-AZ-Bereitstellung wechseln, werden die beiden jeweiligen Gebühren für diese Stunde in Rechnung gestellt.
Bereitgestellter Speicherplatz (für Multi-AZ DB Instance) – wenn Sie innerhalb einer angebrochenen Stunde zwischen einer DB Instance-Standardbereitstellung und einer Multi-AZ-Bereitstellung wechseln, wird der höhere der beiden jeweiligen Gebührensätze für Speicher für diese Stunde in Rechnung gestellt.
E/A-Anfragen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranfragen. Bei Multi-AZ-Bereitstellungen werden mehr E/A-Anfragen als bei standardmäßigen DB Instance-Bereitstellungen verbraucht, in Abhängigkeit von den Schreib-/Leseraten Ihrer Datenbank. Die E/A-Vorgänge im Zusammenhang mit Datenbank-Updates werden verdoppelt, da Amazon RDS Ihre Daten synchron in der Standby-DB Instance repliziert. Die E/A-Auslastung für Lesevorgänge bleibt unverändert.
Backup-Speicher – der Bedarf an Backup-Speicher bleibt gleich, egal, ob Sie eine standardmäßige oder eine Multi-AZ-Bereitstellung Ihrer DB Instance nutzen. Backups werden einfach von der Standby-Replika angefertigt, um E/A-Unterbrechungen bei den primären Daten der DB Instance zu vermeiden.
Datenübertragung – der beim Replizieren der Daten zwischen Primär-Instanz und Replika anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt.

F: Sind Steuern im Preis enthalten?

Falls nicht anders bezeichnet, gelten unsere Preise zuzüglich anwendbarer Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Unsere Preise für die Region Asien-Pazifik (Tokio) verstehen sich beispielsweise inklusive japanischer Verbrauchssteuer.

Reserved Instances

F: Was sind Amazon RDS Reserved Instances?

Mit reservierten Instances können Sie gegen eine einmalige Vorauszahlung eine ein– oder dreijährige Reservierung zur Ausführung Ihrer DB Instance in einer bestimmten Region tätigen, und erhalten einen erheblichen Rabatt auf die laufenden stündlichen Nutzungsgebühren. Es gibt drei Reserved Instance-Typen (reservierte Instances mit geringer, mittlerer und hoher Auslastung), die Ihnen die Möglichkeit bieten, den Betrag für die Vorabzahlung und die Gebühren pro Stunde gegeneinander abzuwägen:

F: Wie unterscheiden sich Reserved Instances von On-Demand DB Instances?

Funktionell gesehen sind reservierte Instances und On-Demand Instances genau gleich. Der einzige Unterschied besteht in der Abrechnung Ihrer Instance(s). Bei reservierten DB Instances tätigen Sie eine einmalige Vorauszahlung und sichern sich damit eine niedrigere stündliche Nutzungsgebühr (verglichen mit On-Demand DB Instances) für die Dauer des Nutzungszeitraums.

F: Wie kann ich reservierte Instances erwerben und erstellen?

Sie können die Option "Reservierte DB Instance kaufen" in der AWS Management Console verwenden. Alternativ können Sie API-Tools verwenden. Sie können die verfügbaren Reservierungen zum Kauf mit der DescribeReservedDBInstancesOfferings API-Methode auflisten und dann eine DB Instance-Reservierung kaufen, indem Sie die PurchaseReservedDBInstancesOffering-Methode aufrufen.

Reserved Instances werden genauso erstellt und gestartet wie On-Demand Instances. Sie verwenden einfach den Befehl "rds-create-db-instance", den API-Befehl "CreateDBInstance" oder die Option "Launch DB Instance" (DB Instance starten) aus der AWS Management Console, und geben dabei die DB Instance-Klasse und die Region, für die Sie die Reservierung tätigen möchten, an. Nach erfolgtem Erwerb der Reservierung erhalten Sie von Amazon RDS den entsprechenden reduzierten Stundensatz für die neue DB Instance.

F: Stehen immer Reservierungen zum Erwerb zur Verfügung?

Ja. Reservierte Instances werden für die Region, nicht für die Availability Zone erworben. Also auch dann, wenn die Kapazität in einer Availability Zone begrenzt ist, können Reservierungen für eine Region erworben und in einer anderen Availability Zone innerhalb der Region genutzt werden.

F: Wie viele Reserved Instances kann ich erwerben?

Sie können bis zu 20 reservierte DB-Instanzen erwerben. Wenn Sie mehr als 20 DB Instances ausführen möchten, füllen Sie bitte das Anfrageformular für Amazon RDS DB Instances aus.

F: Was muss ich tun, wenn ich eine vorhandene DB Instance in eine reservierte DB Instance umwandeln möchte?

Erwerben Sie einfach eine DB Instance-Reservierung derselben DB Instance-Klasse, dem gleichen DB Engine und Lizenzmodell in derselben Region wie die DB Instance, die Sie aktuell ausführen und reservieren möchten. Nach erfolgreichem Erwerb der Reservierung wendet Amazon RDS die neue stündliche Nutzungsgebühr automatisch auf Ihre bestehende DB Instance an.

F: Wann beginnt der Nutzungszeitraum, wenn ich mich für eine reservierte Instance anmelde? Was geschieht mit meiner DB Instance nach Ablauf des Zeitraums?

Preisänderungen für reservierte Instances werden aktiviert, sobald Ihre Anfrage während der Zahlungsautorisierung eingegangen ist. Sie können den Status Ihrer Reservierung auf der Seite zu den AWS-Kontoaktivitäten oder über den API-Befehl "DescribeReservedDBInstances" verfolgen. Falls die einmalige Zahlung nicht erfolgreich bis zur nächsten Abrechnungsperiode autorisiert werden kann, wird der rabattierte Preis nicht übernommen.

Nach Ablauf Ihres Reservierungszeitraums gilt für Ihre reservierte Instance wieder der entsprechende On-Demand-Nutzungstarif Ihrer DB Instance-Klasse und –Region.

F: Wie kann ich kontrollieren, welche Instances nach dem Tarif für reservierte DB Instances berechnet werden?

Die Amazon RDS-APIs zum Erstellen, Modifizieren und Löschen von DB Instances unterscheiden nicht zwischen On-Demand und reservierten Instances, sodass Sie beide Arten nahtlos verwenden können. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten DB Instances nach dem reduzierten Stundentarif für reservierte DB Instances abgerechnet werden.

F: Wenn ich meine reservierte Instance hoch oder herunterskaliere, was geschieht dann mit meiner Reservierung?

Jede Reservierung wird mit dem folgenden Satz an Attributen verknüpft: DB Engine, DB Instance-Klasse, Bereitstellungstyp, Lizenzmodell und Region. Jede Reservierung kann nur für eine DB Instance mit den gleichen Attributen für die Dauer der Laufzeit angewandt werden. Wenn Sie sich entscheiden, Ihre DB Instance-Klasse vor dem Ende des Abrechnungszeitraums zu modifizieren, gelten wieder die normalen On-Demand-Tarifsätze für diese DB Instance anstatt des Stundentarifsatzes. Wenn Sie die Attribute der ausgeführten DB Instance später an die ursprüngliche Reservierung anpassen oder eine neue DB Instance mit denselben Attributen wie Ihre ursprüngliche Reservierung erstellen, findet bis zum Ende Ihres Reservierungszeitraums wieder der reduzierte Tarif Anwendung.

F: Kann ich eine Reserved Instance von einer Region oder Availability Zone in eine andere verschieben?

Jede reservierte Instance ist mit einer bestimmten Region verbunden, die für die Lebensdauer der Reservierung festgelegt ist und nicht geändert werden kann. Jede Reservierung kann jedoch in beliebigen AZs der zugeordneten Region verwendet werden.

F: Sind reservierte Instances für Multi-AZ-Bereitstellungen verfügbar?

Ja. Wenn Sie den API-Befehl "DescribeReservedDBInstancesOfferings" nutzen, halten Sie einfach nach den Multi-AZ-Optionen Ausschau, die für die zum Erwerb verfügbaren DB Instance-Konfigurationen aufgelistet sind. Wenn Sie eine Reservierung für eine DB Instance mit synchroner Replizierung über mehrere Availability Zones erwerben möchten, spezifizieren Sie eines dieser Angebote im API-Befehl "PurchaseReservedDBInstancesOffering".

F: Sind reservierte Instances für Read Replicas verfügbar?

Eine standardmäßige DB Instance-Reservierung kann auch auf eine Read Replica angewandt werden, vorausgesetzt, die DB Instance-Klasse und –Region sind identisch. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten Instances nach dem reduzierten Stundentarif für reservierte DB Instances abgerechnet werden.

F: Kann ich eine Reservierung stornieren?

Die Einmalzahlung für eine reservierte Instance kann nicht rückerstattet werden. Sie können jedoch jederzeit Ihre DB Instance kündigen. Ab diesem Moment werden keine stündlichen Nutzungsgebühren mehr eingezogen.

F: Kann ich meine vorhandenen Reserved Instances gegen die günstigeren Reserved Instances vom 5. März 2012 tauschen?

Allgemein werden Reserved Instances nicht erstattet. Als spezielle Ausnahme gilt jedoch Folgendes: Wenn Sie innerhalb der letzten 30 Tage eine einjährige Reserved Instance oder innerhalb der letzten 90 Tage eine dreijährige Reserved Instance gekauft haben, können Sie sie gegeben eine der neuen Reserved Instances austauschen. Beim Austauschen einer Reserved Instance, werden vorausbezahlte Gebühren anteilig erstattet und Gebühren für bereits genutzte Instance-Stunden werden nicht erstattet. Wenn Sie eine Reserved Instance gegen eine der neuen austauschen möchten, nehmen Sie mit uns Kontakt auf.

Hardware und Skalierung

F: Wie bestimme ich, welche DB-Instance-Klasse und welche Speicherkapazität für meine anfänglichen Anforderungen angemessen sind?

Um Ihre anfängliche DB-Instance-Klasse und Speicherkapazität auszuwählen, sollten Sie den Rechen– und Speicherbedarf der betreffenden Anwendung abschätzen. Weitere Hinweise zur Auswahl der richtigen DB Instance-Klasse und Speicherkapazität finden Sie im Amazon RDS-Leitfaden zur richtigen Größenordnung von DB Instances.

F: Wie skaliere ich die mit meiner RDS Database Instance verbundenen Rechenressourcen und/oder Speicherkapazitäten?

Sie können die Ihrer DB Instance zugewiesenen Rechenressourcen und die Speicherkapazität mit der API "ModifyDBInstance" oder über die AWS Management Console (durch Auswahl der gewünschten DB Instance und Klicken auf die Schaltfläche "Modify") skalieren. Speicher– und CPU-Ressourcen können durch eine Änderung der DB-Instance-Klasse modifiziert werden, und der verfügbare Speicher wird geändert, wenn Sie Ihre Speicherzuteilung ändern. Bitte beachten Sie, dass alle gewünschten Änderungen der DB Instance-Klasse oder des zugeteilten Speichers während des festgelegten Aktualisierungsfensters durchgeführt werden. Alternativ können Sie ein "apply-immediately"-Flag setzen, um die angeforderte Skalierung sofort durchzuführen. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls durchgeführt werden.

Mit Amazon CloudWatch können Sie die Auslastung der Rechen– und Speicherkapazitäten Ihrer DB Instance ohne zusätzliche Gebühren überwachen. Sie können Werte wie die CPU-Auslastung, die Speicherauslastung oder den Netzwerkverkehr abrufen. Klicken Sie hierfür auf die Registerkarte "Monitoring" (Überwachung) in der AWS Management Console oder verwenden Sie die Amazon CloudWatch-APIs. Weitere Informationen zur Überwachung Ihrer aktiven DB Instances finden Sie im Amazon-RDS-Handbuch zur Überwachung.

Beachten Sie für SQL Server, dass Amazon RDS aufgrund der Einschränkungen bei der Erweiterbarkeit von Speicher mit Striping-Technologie, der an eine Windows Server –Umgebung angeschlossen ist, eine Speichervergrößerung derzeit nicht unterstützt. Amazon plant, diese Funktionalität künftig zu unterstützen, und empfiehlt die Bereitstellung von Speicher basierend auf dem erwarteten künftigen Speicherbedarf. Wenn es in der Zwischenzeit erforderlich wird, den Speicher einer SQL Server DB Instance zu vergrößern, müssen Sie die Daten exportieren, eine neue DB Instance mit größerem Speicher erstellen und die Daten in diese importieren. Weitere Informationen finden Sie im Datenimporthandbuch für SQL Server.

F: Welche Hardware-Konfiguration ist für den Amazon RDS-Standard-Speicher zu empfehlen?

Amazon RDS verwendet EBS-Datenträger zum Speichern von Datenbank und Protokoll. Je nach der Größe des erforderlichen Speichers verteilt Amazon RDS Daten automatisch per Striping auf mehrere EBS-Datenträger, um die IOPS-Leistung zu verbessern. Sie können bei MySQL und Oracle bei einer vorhandenen DB-Instance eine Verbesserung der E/A-Kapazität feststellen, wenn Sie Ihren Speicher vergrößern. Sie können die der DB-Instance zugewiesene Speicherkapazität erweitern. Verwenden Sie hierfür die AWS Management Console oder die ModifyDBInstance-API.

Beachten Sie jedoch für SQL Server, dass Amazon RDS aufgrund der Einschränkungen bei der Erweiterbarkeit von Speicher mit Striping-Technologie, der an eine Windows Server –Umgebung angeschlossen ist, eine Speichervergrößerung derzeit nicht unterstützt.

F: Ist meine DB Instance während der Skalierung weiterhin verfügbar?

Ihre DB Instance ist auch während einer Skalierung der ihr zugeteilten Speicherkapazität verfügbar. Bei einer Skalierung der zur Verfügung stehenden Rechenressourcen Ihrer DB Instance ist die Datenbank jedoch während der Änderung der DB Instance vorübergehend nicht verfügbar. Der Zeitraum der Nichtverfügbarkeit dauert in der Regel nur wenige Minuten und liegt innerhalb des Aktualisierungsfensters für Ihre DB Instance, es sei denn, Sie legen fest, dass die Änderung sofort durchgeführt werden soll.

F: Wie kann ich meine DB Instance so skalieren, dass sie die höchste DB-Instance-Klasse und die höchste Speicherkapazität übersteigt?

Amazon RDS unterstützt eine Reihe verschiedener DB-Instance-Klassen und Speicherzuteilungen, die diverse Anwendungsanforderungen erfüllen. Wenn die von Ihrer Anwendung benötigten Rechenressourcen die höchste DB-Instance-Klasse bzw. die maximale Speicherzuteilung übersteigen, können Sie eine Partitionierung implementieren und dadurch die Daten auf mehrere DB Instances verteilen.

F: Was sind bereitgestellte IOPS für Amazon RDS?

Von Amazon RDS bereitgestellte IOPS sind eine Speicheroption, die so konzipiert wurde, dass sie eine schnelle, vorhersehbare und konsistente E/A-Leistung bietet. Mit von Amazon RDS bereitgestellten IOPS geben Sie bei der Erstellung einer DB-Instance eine IOPS-Rate an und Amazon RDS stellt diese IOPS-Rate dann für die Lebensdauer der DB-Instance bereit. Von Amazon RDS bereitgestellte E/A\Sek. sind für E/A-intensive, transaktionale Datenbankarbeitslasten (OLTP) optimiert. Nähere Informationen finden Sie im Benutzerhandbuch zu Amazon RDS.

F: Welche minimale und maximale E/A\Sek.-Kapazität wird von Amazon RDS unterstützt?

Die von Amazon RDS unterstützte E/A\Sek.-Kapazität hängt von der jeweiligen Datenbank-Engine ab. Nähere Informationen finden Sie im Benutzerhandbuch zu Amazon RDS.

F: Wann sollte ich bereitgestellte IOPS statt RDS-Standard-Speicher wählen?

Sie sollten den bereitgestellten IOPS-Speicher wählen, wenn Sie eine konsistente Leistung benötigen und Datenbankarbeitslasten haben, die hauptsächlich direkte E/A-Zugriff erzeugen. Bereitgestellte IOPS sind für Produktionsarbeitslasten für die transaktionale Online-Datenverarbeitung (OLTP) ideal. Für Ihre Produktion und OLTP-Datenbank-Arbeitslasten empfehlen wir bereitgestellte IOPS zusammen mit Multi-AZ. Nähere Informationen finden Sie im Benutzerhandbuch zu Amazon RDS.

Automatische Backups und Datenbank-Snapshots

F: Was ist der Unterschied zwischen automatischen –-Backups und DB-Snapshots?

Amazon RDS bietet zwei verschiedene Methoden zum Backup und zur Wiederherstellung Ihrer DB Instance(s): automatische Backups und Datenbank-Snapshots (DB Snapshots).

Die Amazon RDS-Funktion für automatisierte Backups gestattet Wiederherstellungen Ihrer DB Instance zu einem beliebigen Zeitpunkt. Wenn automatisierte Backups für Ihre DB Instance aktiviert sind, führt Amazon RDS täglich automatisch einen vollständigen Snapshot Ihrer Daten aus (im Rahmen Ihres festgelegten Backup-Fensters) und generiert Transaktionsprotokolle (zu den Updates Ihrer DB Instance). Wenn Sie eine Wiederherstellung für einen bestimmten Zeitpunkt initiieren, werden die Transaktionsprotokolle für das passendste Backup angewandt, um Ihre DB Instance zu dem gewünschten Zeitpunkt wiederherzustellen. Amazon RDS bewahrt Backups einer DB Instance für einen begrenzten, benutzerdefinierten Zeitraum (den "Aufbewahrungszeitraum") auf. Dieser liegt standardmäßig bei einem Tag, kann aber auf bis zu 35 Tage verlängert werden. Sie können eine Wiederherstellung zu jeder beliebigen Sekunde Ihres Wiederherstellungszeitraums bis zum letztmöglichen Zeitpunkt initiieren. Sie können die API "DescribeDBInstances" verwenden, um den letztmöglichen Wiederherstellungszeitpunkt für Ihre DB Instance(s) zu nutzen. Dieser liegt in der Regel innerhalb der letzten fünf Minuten. Alternativ können Sie den letztmöglichen Wiederherstellungszeitpunkt für eine DB Instance auch finden, indem Sie die Instance in der AWS Management Console auswählen und unter der Registerkarte "Description" (Beschreibung) im unteren Arbeitsbereich der Console nachsehen.

DB Snapshots werden vom Benutzer initiiert und ermöglichen es Ihnen, Ihre DB Instance in einem bekannten Zustand beliebig oft zu sichern und dann diesen spezifischen Zustand jederzeit wiederherzustellen. DB Snapshots können mit der AWS Management Console oder der "CreateDBSnapshot"-API erstellt werden. Sie werden so lange aufbewahrt, bis Sie sie mit der Console oder der "DeleteDBSnapshot"-API explizit löschen.

Die von Amazon RDS zur Aktivierung automatischer Backups ausgeführten Snapshots stehen zum Kopieren (über die AWS-Konsole oder den Befehl "rds-copy-db-snapshot") oder für die Snapshot-Wiederherstellung zur Verfügung. Sie ermitteln sie anhand des "automatisierten" Snapshot-Typs. Außerdem können Sie die Zeit ermitteln, zu der der Snapshot erstellt wurde, indem Sie das Feld "Zeitpunkt der Snapshot-Erstellung" anzeigen. Die Kennzeichnung des "automatisierten" Snapshots enthält ebenfalls die Zeit (UTC), zu der der Snapshot erstellt wurde.

Hinweis: Wenn Sie einen Wiederherstellungsvorgang zu einem bestimmten Zeitpunkt oder mithilfe eines DB Snapshots durchführen, wird eine neue DB Instance mit einem neuen Endpunkt erstellt (die alte DB Instance kann auf Wunsch mit der AWS Management Console oder der "DeleteDBInstance"-API gelöscht werden). Auf diese Weise haben Sie die Möglichkeit, mehrere DB Instances aus einem bestimmten DB Snapshot oder zu einem bestimmten Zeitpunkt zu erstellen.

F: Muss ich Backups für meine DB Instance aktivieren oder geschieht dies automatisch?

Das automatische Backup Ihrer DB Instance ist in Amazon RDS standardmäßig aktiviert und kostenlos. Es gilt ein Aufbewahrungszeitraum von einem Tag. Der kostenlose Backup-Speicher ist auf die Größe der bereitgestellten Datenbank begrenzt und gilt nur für aktive DB Instances. Wenn Sie beispielsweise über einen bereitgestellten Datenspeicher von monatlich 10 GB verfügen, bieten wir Ihnen ohne Aufpreis höchstens 10 GB Backup-Speicher pro Monat. Mit der "CreateDBInstance"-API (bei der Erstellung einer neuen DB Instance) oder der ModifyDBInstance-API (bei einer bestehenden DB Instance) kann der Aufbewahrungszeitraum für Backups über den standardmäßigen Zeitraum hinaus verlängert werden. Setzen Sie hierzu mithilfe der APIs den Parameter für den Aufbewahrungszeitraum von 1 auf die gewünschte Anzahl an Tagen. Weitere Informationen zu automatischen Backups finden Sie im Amazon RDS-Entwicklerhandbuch.

F: Was ist ein Backup-Fenster und wofür wird es benötigt? Steht meine Datenbank während des Backup-Fensters zur Verfügung?

Beim bevorzugten Backup-Fenster handelt es sich um den vom Benutzer festgelegten Zeitraum, in dem das Backup der DB Instance durchgeführt wird. Amazon RDS nutzt diese regelmäßigen Daten-Backups in Verbindung mit Ihren Transaktionsprotokollen, um Ihnen die Möglichkeit zu geben, Ihre DB Instance zu jeder Sekunde des Aufbewahrungszeitraums bis zum letztmöglichen Wiederherstellungszeitpunkt (üblicherweise innerhalb der letzten fünf Minuten) wiederherzustellen. Innerhalb des Backup-Fensters werden E/A-Speichervorgänge während der Durchführung der Datensicherung möglicherweise vorübergehend unterbrochen. Diese E/A-Unterbrechungen dauern in der Regel nicht mehr als wenige Minuten. Mit Multi-AZ DB-Bereitstellungen lassen sich diese Unterbrechungen vermeiden, da das Backup von der Standby-Replika angefertigt wird.

F: Wo werden meine automatisierten Sicherungen und DB-Snapshots gespeichert und wie kann ich deren Aufbewahrung verwalten?

Amazon RDS DB Snapshots und automatisierte Sicherungen werden in S3 gespeichert.

Mithilfe der AWS Management Console oder der "ModifyDBInstance"-API können Sie den Aufbewahrungszeitraum für automatische Backups verwalten, indem Sie den "RetentionPeriod"-Parameter ändern. Wenn Sie die Durchführung automatischer Backups vollständig deaktivieren möchten, setzen Sie den Aufbewahrungszeitraum auf 0 (nicht empfohlen). Sie können Ihre benutzererstellten DB Snapshots über den Bereich "DB Snapshots" in der AWS Management Console verwalten. Alternativ können Sie sich mithilfe der "DescribeDBSnapshots"-API eine Liste der vom Benutzer erstellten DB Snapshots anzeigen lassen. Mithilfe der "DeleteDBSnapshot"-API können Sie Snapshots löschen.

F: Was passiert mit meinen Backups und DB Snapshots, wenn ich meine DB Instance lösche?

Wenn Sie eine DB-Instance löschen, können Sie vor dem Löschvorgang einen letzten DB-Snapshot erstellen. In diesem Fall können Sie diesen DB-Snapshot zum Wiederherstellen der gelöschten DB-Instance zu einem späteren Zeitpunkt nutzen. Amazon RDS behält diesen letzten vom Benutzer erstellten DB-Snapshot zusammen mit allen anderen manuell erstellten DB-Snapshots bei, nachdem die DB-Instance gelöscht wurde. Auf der Seite mit den Preisen finden Sie Details zu den Kosten des Speicherns von Sicherungen.

Beim Löschen der DB-Instance werden automatisierte Sicherungen gelöscht. Nach dem Löschen der DB-Instance werden nur manuell erstellte DB-Snapshots beibehalten.

Sicherheit

F: Was ist Amazon Virtual Private Cloud (VPC) und warum sollte ich sie eventuell mit Amazon RDS nutzen?

Mit Amazon VPC können Sie eine virtuelle Netzwerkumgebung in einem privaten, isolierten Bereich der Amazon Web Services (AWS)-Cloud erstellen. Hier haben Sie die vollständige Kontrolle über private IP-Adressbereiche, Subnetze, Routing-Tabellen und Netzwerk-Gateways. Mit Amazon VPC definieren Sie eine virtuelle Netzwerktopologie und passen die Netzwerkkonfiguration an Ihre Bedürfnisse an, so dass sie einem herkömmlichen IP-Netzwerk ähnelt, das sie in Ihrem eigenen Rechenzentrum betreiben könnten.

Eines der Szenarien, in denen es hilfreich wäre, wenn Sie Amazon RDS in VPC verwenden ist die Ausführung einer öffentlich zugänglichen Webanwendung bei einer gleichzeitigen Nutzung nicht öffentlich zugänglicher Backend-Server in einem privaten Subnetz. Sie können ein öffentlich zugängliches Subnetz für Ihre Webserver erstellen, das Zugang zum Internet hat und Ihre Backend RDS DB Instances in einem nicht öffentlich zugänglichen Subnetz ohne Internetzugriff einrichten. Weitere Informationen zu Amazon VPC erhalten Sie im Amazon Virtual Private Cloud User Guide.

F: Inwiefern unterscheidet sich die Nutzung von Amazon RDS in einer VPC von der Nutzung außerhalb?

Die grundlegenden Funktionen von Amazon RDS sind dieselben, unabhängig davon, ob VPC genutzt wird. Amazon RDS verwaltet Sicherungen, Software-Patches, automatische Fehlererkennung, Read Replicas und Wiederherstellungen unabhängig davon, ob Ihre DB-Instances innerhalb oder außerhalb einer VPC bereitgestellt werden.

Amazon RDS DB Instances, die außerhalb einer VPC bereitgestellt werden, erhalten eine externe IP-Adresse (bei der der Endpunkt/DNS-Name aufgelöst wird). Diese stellt die Verbindung von EC2 oder vom Internet dar. In Amazon VPC haben Amazon RDS DB Instances nur eine private IP-Adresse (innerhalb eines von Ihnen definierten Subnetzes).

F: Was ist eine DB Subnet Group und warum benötige ich eine?

Eine DB Subnet Group ist eine Sammlung von Subnetzen, die Sie für Ihre RDS DB Instances in einer VPC verwenden könnten. Jede DB Subnet Group sollte mindestens über ein Subnetz für jede Availability Zone in einer bestimmten Region verfügen. Wenn Sie eine DB Instance in VPC erstellen, müssen Sie eine DB Subnet Group auswählen. Amazon RDS verwendet diese DB Subnet Group und Ihre bevorzugte Availability Zone dann zur Auswahl eines Subnetzes und einer IP-Adresse in diesem Subnetz. Amazon RDS erstellt und ordnet Ihrer DB Instance eine Elastic-Netzwerkschnittstelle mit dieser IP-Adresse zu.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB Instance verwenden, da die zugrunde liegende IP-Adresse sich ändern kann (z. B während eines Failovers).

Bei Multi-AZ-Bereitstellungen kann Amazon RDS durch die Definition eines Subnetzes für alle Availability Zones in einer Region bei Bedarf eine neue Standby-Instance in einer anderen Availability Zone erstellen. Sie müssen dies sogar für Einzel-AZ-Bereitstellungen vornehmen, nur für den Fall, dass Sie sie zu einem späteren Zeitpunkt in Multi-AZ-Bereitstellungen umwandeln möchten.

F: Wie kann ich eine Amazon RDS DB Instance in VPC erstellen?

Ein detailliertes Beispiel zur Erstellung einer DB Instance in VPC erhalten Sie im Amazon RDS User Guide.

Im Folgenden sehen Sie die erforderlichen Voraussetzungen zum Erstellen von DB Instances in einer VPC:

In jeder Availability Zone einer Region, in der Sie Ihre DB Instance bereitstellen möchten, muss eine VPC mit mindestens einem Subnetz eingerichtet sein. Weitere Informationen zum Erstellen von Amazon VPC und Subnetzen erhalten Sie im Getting Started Guide for Amazon VPC.
Für Ihre VPC muss eine DB Subnet Group definiert sein.
Für Ihre VPC muss eine DB Security Group definiert sein (oder Sie können den verfügbaren Standard verwenden).
Außerdem sollten Sie jedem Subnetz entsprechend große CIDR-Blocks zuweisen, damit ausreichend zusätzliche IP-Adressen für Amazon RDS zur Verfügung stehen. Diese können Sie während Wartungsaktivitäten, u. a. Skalierung des Rechenbetriebs und Failover, verwenden.

F: Wie kontrolliere ich den Netzwerkzugriff auf meine DB Instance(s)?

Im Amazon RDS User Guide finden Sie im Abschnitt Security GroupsInformationen zu den verschiedenen Möglichkeiten, den Zugriff auf Ihre DB-Instances zu steuern.

F: Wie sichere ich Amazon RDS-DB-Instances, die in meiner VPC ausgeführt werden?

Sie können VPC-Sicherheitsgruppen verwenden, um DB-Instances innerhalb einer Amazon VPC zu schützen. Zusätzlich kann eingehender oder ausgehender Netzwerkverkehr der Subnetze über Netzwerk-Zugriffskontrolllisten (ACLs) zugelassen oder gesperrt werden. Sie können den gesamten ein– und ausgehenden Netzwerkverkehr Ihrer VPC über die IPsec VPN-Verbindung mit Ihrer bestehenden Sicherheitsinfrastruktur, wie Firewalls und Intrusion-Detection– und Intrusion-Prevention-Systeme, am Standort überprüfen.

F: Wie kann ich eine Verbindung mit einer RDS DB Instance in VPC herstellen?

Auf DB Instances, die innerhalb einer VPC bereitgestellt werden, kann von in derselben VPC bereitgestellten EC2 Instances zugegriffen werden. Wenn diese EC2-Instances in einem öffentlichen Subnetz mit zugeordneten Elastic IP-Adressen bereitgestellt werden, können Sie auf die EC2-Instances über das Internet zugreifen.

Auf in einer VPC bereitgestellte DB-Instances kann über das Internet oder von EC2-Instances außerhalb der VPC über VPN oder Bastion-Hosts zugegriffen werden, die Sie in Ihrem öffentlichen Subnetz oder über die Amazon RDS-Option "Publicly Accessible" starten können:

Wenn Sie einen Bastion-Host verwenden möchten, müssen Sie ein öffentliches Subnetz mit einer EC2-Instanz einrichten, die als SSH-Bastion fungiert. Dieses öffentliche Subnetz muss über ein Internet-Gateway und Routing-Regeln verfügen, die erlauben, dass der Datenverkehr über den SSH-Host gerichtet wird. Dieser muss dann Anforderungen an die private IP-Adresse Ihrer RDS DB-Instanz weiterleiten.
Erstellen Sie für eine öffentliche Anbindung Ihre DB-Instances mit auf "yes" festgelegter Option "Publicly Accessible". Wenn "Publicly Accessible" aktiv ist, kann von außerhalb Ihrer VPC standardmäßig auf Ihre DB-Instances in der VPC voll zugegriffen werden. Das heißt, dass Sie kein VPN bzw. keinen Bastion-Host konfigurieren müssen, um den Zugriff auf Ihre Instances zuzulassen.

Sie können auch ein VPN-Gateway einrichten, durch das Ihr Unternehmensnetzwerk in Ihre VPC erweitert wird und das einen Zugriff auf die RDS DB Instance in dieser VPC ermöglicht. Weitere Informationen hierzu finden Sie im Amazon VPC User Guide.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB Instance verwenden, da sich die zugrunde liegende IP-Adresse ändern kann (z. B während eines Failovers).

F: Kann ich meine vorhandenen DB Instances außerhalb der VPC in meine VPC verschieben?

Sie können einen Snapshot Ihrer DB Instance außerhalb der VPC erstellen und ihn in der VPC wiederherstellen, indem Sie die gewünschte DB Subnet Group angeben. Sie können auch eine "Wiederherstellung zu einem bestimmten Zeitpunkt" vornehmen.

F: Kann ich meine vorhandenen DB Instances von innerhalb der VPC aus der VPC heraus verschieben?

Aktuell wird eine direkte Migration der DB Instances von innerhalb zu außerhalb der VPC nicht unterstützt. Aus Sicherheitsgründen kann ein Snapshot einer DB Instance in einer VPC nicht außerhalb der VPC wiederhergestellt werden. Dasselbe gilt für die Funktion "Wiederherstellung zu einem bestimmten Zeitpunkt". Wenn Sie Ihre DB Instance von innerhalb der VPC nach außen verschieben, müssen Sie Ihre Daten aus Ihrer Quell-DB Instance in Ihrer VPC in Ihre außerhalb der VPC bereitgestellte Ziel-DB Instance exportieren.

F: Welche Vorkehrungen sollte ich treffen, um sicherzustellen, dass meine Anwendung auf die DB Instances in der VPC zugreifen kann?

Sie müssen Routing-Tabellen und Netzwerk-ACLs in Ihrer VPC entsprechend ändern, um sicherzustellen, dass Ihre DB Instance für Ihre Client-Instances im VPC erreichbar sind.

Bei Multi-AZ-Bereitstellungen befinden sich Ihre Client-EC2 Instance und die RDS DB-Instance eventuell in verschiedenen Availability Zones. Sie sollten Ihre Netzwerk-ACLs so konfigurieren, dass eine übergreifende AZ-Kommunikation möglich ist.

F: Kann ich die DB Subnet Group meiner DB Instance ändern?

Eine vorhandene DB Subnet Group kann aktualisiert werden, um nach dem Erstellen der DB Instance für vorhandene Availability Zones oder für neue Availability Zones mehr Subnetze hinzuzufügen. Das Ändern der DB Subnet Group einer bereitgestellten DB Instance ist aktuell nicht erlaubt.

F: Was ist ein Amazon RDS-Master-Benutzerkonto und wie unterscheidet es sich von einem AWS-Konto?

Um Amazon RDS verwenden zu können, benötigen Sie ein AWS-Entwicklerkonto. Wenn Sie vor der Anmeldung für Amazon RDS kein Entwicklerkonto besitzen, werden Sie zu Beginn des Anmeldevorgangs zur Erstellung eines solchen Kontos aufgefordert. Ein Master-Benutzerkonto unterscheidet sich von einem AWS-Entwicklerkonto und wird ausschließlich im Rahmen von Amazon RDS verwendet, um den Zugriff auf Ihre DB Instance(s) zu kontrollieren. Beim Master-Benutzerkonto handelt es sich um das Benutzerkonto einer nativen Datenbank, über das Sie auf Ihre DB Instance zugreifen können. Bei Erstellung der einzelnen DB Instances können Sie festlegen, welcher Master-Benutzername und welches Kennwort ihnen zugewiesen werden sollen. Nach Erstellung Ihrer DB Instance können Sie mithilfe der Master-Benutzerdaten auf die Datenbank zugreifen. Anschließend können Sie weitere Benutzerkonten erstellen, mit denen Sie den Zugriff auf Ihre DB Instance einschränken können.

F: Welche Berechtigungen werden dem Master-Benutzer meiner DB Instance gewährt?

Der Master-Benutzer verfügt über folgende Standardberechtigungen für MySQL: Erstellen, Entfernen, Referenzen, Ereignis, Ändern, Löschen, Index, Einfügen, Auswählen, Aktualisieren, temporäre Tabellen erstellen, Tabellen sperren, Auslösen, Ansicht erstellen, Ansicht anzeigen, Routine ändern, Routine erstellen, Ausführen, Benutzer erstellen, Verarbeiten, Datenbanken anzeigen, Option erteilen.

Der Master-Benutzer verfügt in Oracle über die "DBA"-Rolle. Der Master-Benutzer übernimmt die der Rolle zugeordneten Berechtigungen. Bitte lesen Sie das Amazon RDS Benutzerhandbuch für eine Liste mit den eingeschränkten Privilegien und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Privilegien eventuell erfordern.

Bei SQL Server wird dem Benutzer, der eine Datenbank anlegt, die Rolle "db_owner" zugewiesen. Im Amazon RDS User Guide finden Sie eine Liste mit den eingeschränkten Berechtigungen und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Berechtigungen eventuell erfordern.

F: Gibt es in Amazon RDS Besonderheiten, was die Benutzerverwaltung anbetrifft?

Nein, alles funktioniert so, wie Sie es von relationalen Datenbanken gewohnt sind, die Sie selbst verwalten.

F: Können Programme, die auf Servern in meinem eigenen Rechenzentrum ausgeführt werden, auf Amazon RDS-Datenbanken zugreifen?

Ja. Sie müssen den Zugriff auf Ihre Datenbank über das Internet absichtlich aktivieren, indem Sie Sicherheitsgruppen konfigurieren. Sie können den Zugriff nur für die spezifischen IP-Adressen, IP-Adressbereiche und Subnetze autorisieren, die Servern in Ihrem eigenen Rechenzentrum entsprechen.

F: Kann ich Verbindungen zwischen meiner Anwendung und meiner DB-Instance mithilfe von SSL verschlüsseln?

Ja, diese Option wird jedoch nur für MySQL– und SQL Server-Engines unterstützt.

Amazon RDS generiert für jede DB-Instance ein SSL-Zertifikat. Einzelheiten zum Einrichten einer verschlüsselten Verbindung mit Amazon RDS finden Sie im Amazon RDS MySQL User Guide und SQL Server User Guide. Nach dem Erstellen einer verschlüsselten Verbindung werden Daten zwischen der DB Instance und Ihrer Anwendung verschlüsselt übertragen. Wenn Sie eine Datenverschlüsselung für Daten, die in der Datenbank "ruhen", benötigen, muss Ihre Anwendung die Ver– und Entschlüsselung der Daten verwalten. Beachten Sie auch, dass die SSL-Unterstützung in Amazon RDS zur Verschlüsselung der Verbindung zwischen Ihrer Anwendung und Ihrer DB Instance dient. Sie sollte nicht zur Authentifizierung der DB Instance selbst genutzt werden.

Wenngleich SSL Sicherheitsvorteile bietet, sollten Sie daran denken, dass eine SSL-Verschlüsselung sehr rechenintensiv ist und die Latenz Ihrer Datenbankverbindung erhöhen wird. Weitere Informationen zur Funktionsweise von SSL mit MySQL oder SQL Server finden Sie in der MySQL-Dokumentation hier oder auf der MSDN-Website in der SQL Server-Dokumentation hier.

F: Kann ich festlegen, dass meine DB Instance nur verschlüsselte Verbindungen akzeptiert?

Nachdem Sie unter Eingabe des Master-Benutzernamens und des Master-Passworts eine Verbindung zur DB Instance hergestellt haben, können Sie das GRANT-Statement nutzen, um SSL-Verbindungen für bestimmte Benutzerkonten vorauszusetzen. Sie können beispielsweise das folgende Statement verwenden, damit für das Benutzerkonto "encrypted_user" eine SSL-Verbindung vorausgesetzt wird:

GRANT USAGE ON *.* TO ‘encrypted_user’@’%’ REQUIRE SSL

DB-Parametergruppen

F: Wie wähle ich die passenden Konfigurationsparameter für meine DB Instance(s) aus?

Amazon RDS wählt standardmäßig die optimalen Konfigurationsparameter für Ihre DB Instance aus und berücksichtigt dabei die Rechenressource und Speicherkapazität der DB Instance. Sie können die Standardeinstellung jedoch über die Konfigurationsverwaltungs-APIs ändern. Bitte beachten Sie, dass eine Änderung der empfohlenen Werte der Konfigurationsparameter unbeabsichtigte Folgen haben kann, die von einer herabgesetzten Leistung bis hin zu Systemzusammenbrüchen reichen können. Derartige Änderungen sollten daher nur von erfahrenen Benutzern vorgenommen werden, die bereit sind, diese Risiken in Kauf zu nehmen. Weitere Informationen zum Ändern von Parametern finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was sind DB Parameter Groups? Wofür sind sie hilfreich?

Eine Database Parameter Group (DB Parameter Group) dient als eine Art "Behälter" für die Werte der Engine-Konfiguration, die für eine oder mehrere DB Instances verwendet werden können. Falls Sie eine DB Instance erstellen, ohne eine DB Parameter Group zu erstellen, wird eine DB Parameter Group verwendet. Diese Standardgruppe enthält Engine-Standards und Systemstandards für Amazon RDS, die für gerade ausgeführte DB Instances optimiert sind. Wenn Sie die DB Instance jedoch mit benutzerdefinierten Werten für die Engine-Konfiguration ausführen möchten, können Sie einfach eine neue DB Parameter Group erstellen, die betreffenden Parameter ändern und festlegen, dass die DB Instance die neue DB Parameter Group verwendet. Nach der Zuordnung der einzelnen DB Instances zu bestimmten DB Parameter Groups werden alle DB Instances mit den Parametern der jeweiligen DB Parameter Group aktualisiert. Weitere Informationen zur Konfiguration von DB Parameter Groups finden Sie im DB-Bereitstellungsleitfaden für Parameter Groups.

F: Wie kann ich die aktuelle Einstellung für die Parameter einer bestimmten RDS DB Parameter Group anzeigen?

Informationen zu den DB Parameter Groups und den entsprechenden Parametereinstellungen können mithilfe der AWS Management Console, der Amazon RDS-APIs oder mit den Befehlszeilen-Tools angezeigt werden.

Replikation

F: Welche Arten von Replizierung unterstützt Amazon RDS, und wann sollte ich die einzelnen Arten verwenden?

Amazon RDS unterstützt die Datenbank-Engines MySQL, Oracle und SQL Server. Ein Kunde kann den Datenbank-Engine wählen, der am besten seine Anforderungen erfüllt.

Amazon RDS bietet zwei verschiedene Replizierungsoptionen für unterschiedliche Zwecke an.

Wenn Sie mithilfe von Replizierung die Datenbankverfügbarkeit erhöhen und gleichzeitig Ihre aktuellsten Datenbank-Updates gegen ungeplante Ausfälle schützen möchten, sollten Sie Ihre DB Instance als Multi-AZ-Bereitstellung ausführen. Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und wartet Amazon RDS automatisch synchron eine "Standby"-Replika in einer anderen Availability Zone (unabhängige Infrastruktur an einem physisch getrennten Standort). Im Fall einer geplanten Datenbank-Aktualisierung, eines Ausfalls einer DB Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur aktuellen Standby-Replika durch, sodass der Datenbankbetrieb schnell und ohne Verwaltungsaufwand fortgesetzt werden kann. Multi-AZ-Bereitstellungen verwenden eine synchrone Replizierung, wobei Datenbank-Schreibvorgänge gleichzeitig in der primären und der Standby-Instanz erfolgen, sodass die Standby-Replika im Fall eines Failovers stets auf dem aktuellsten Stand ist. Unsere technologische Implementierung für Multi-AZ DB Instances maximiert zwar die Beständigkeit Ihrer Daten bei Ausfällen, gleichzeitig ist es hier aber nicht möglich, die Standby-Daten direkt aufzurufen oder für Lesevorgänge zu verwenden. Aufgrund ihrer Fehlertoleranz sind Multi-AZ-Bereitstellungen ideal für Produktionsumgebungen. Weitere Informationen über Multi-AZ-Bereitstellungen finden Sie unter diesem Abschnitt der häufig gestellten Fragen. Multi-AZ-Bereitstellungen werden derzeit mit MySQL– und Oracle-Datenbank-Engines unterstützt.

Wenn Sie die Vorteile der integrierten Replikation von MySQL nutzen möchten, um eine Skalierung über die Kapazitätseinschränkungen einer einzelnen DB Instance hinaus vorzunehmen und so leseintensive Datenbankarbeitslasten zu bewältigen, erleichtert Ihnen Amazon RDS mit Read Replicas die Arbeit. Sie können eine Read Replica einer gegebenen "Quell"-DB-Instance über die AWS Management Console oder den API-Befehl "CreateDBInstanceReadReplica" erstellen. Nach dem Erstellen der Read Replica werden Datenbank-Aktualisierungen an der Quell-DB-Instance auch für die Read Replica übernommen. Sie können mehrere Read Replicas für eine gegebene Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung auf diese verteilen. Anders als Multi-AZ-Bereitstellungen verwenden Read Replicas die integrierte Replizierung von MySQL und unterliegen deren Stärken und Einschränkungen. Das bedeutet insbesondere, dass Updates in Ihrer/n Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind ("asynchrone" Replizierung), und die Verzögerung bei der Replizierung kann erheblichen Schwankungen unterliegen. Das bedeutet, dass kürzlich an einer standardmäßigen Quell-DB-Instance (nicht Multi-AZ) durchgeführte Datenbank-Updates bei einem ungeplanten Ausfall der Quell-DB-Instance möglicherweise noch nicht in der zugehörigen Read Replica übernommen wurden. Read Replicas an sich bieten daher nicht dieselben Vorteile in puncto Datenbeständigkeit wie Multi-AZ-Bereitstellungen. Read Replicas können einige Vorteile im Hinblick auf die Verfügbarkeit von Leseleistung bieten, sind aber nicht darauf ausgelegt, um die Leistung bei Schreibvorgängen zu verbessern. Read Replicas werden nur von Amazon RDS für MySQL unterstützt.

Mit Amazon RDS können Sie Multi-AZ-Bereitstellungen und Read Replicas in Kombination verwenden, um sich die Vorteile beider Lösungen zunutze zu machen. Sie können einfach festlegen, dass eine gegebene Multi-AZ-Bereitstellung die Quell-DB-Instance für Ihre Read Replica(s) sein soll. Auf diese Weise sichern Sie sich die Vorzüge, die Multi-AZ-Bereitstellungen im Hinblick auf die Beständigkeit und Verfügbarkeit von Daten bieten, und die erhöhte Leseleistung von Read Replicas.

Multi-AZ-Bereitstellungen

F: Was bedeutet es, eine DB Instance als Multi-AZ-Bereitstellung zu betreiben?

Wenn Sie Ihre DB Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und wartet Amazon RDS automatisch synchron eine "Standby"-Replika in einer anderen Availability Zone. Aktualisierungen Ihrer DB Instance werden synchron über mehrere Availability Zones an den Standby-Daten repliziert, damit Ihre aktuellsten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB Instance geschützt bleiben. Während bestimmten geplanten Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zu den Standby-Daten aus, sodass Sie die Schreib– und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortsetzen können. Da der Namen-Datensatz für Ihre DB Instance gleich bleibt, kann Ihre Anwendung den Datenbankbetrieb fortsetzen, ohne dass ein manueller administrativer Eingriff erforderlich ist. Mit Multi-AZ-Bereitstellungen erhalten Sie eine transparente Replizierung: Sie interagieren nicht direkt mit der Standby-Instanz, und diese kann nicht zur Unterstützung des Lesedatenverkehrs genutzt werden. Wenn Sie bei Verwenden von Amazon RDS für MySQL den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB Instance hinaus skalieren möchten, können Sie eine oder mehrere Read Replicas bereitstellen.

F: Was ist eine Availability Zone?

Availability Zones sind isolierte Standorte innerhalb einer Region, d. h. sie sind bei Ausfällen in anderen Availability Zones nicht betroffen. Jede Availability Zone wird auf ihrer eigenen physisch getrennten unabhängigen Infrastruktur ausgeführt und ist auf hohe Zuverlässigkeit ausgelegt. Übliche Fehlerquellen wie Generatoren und Kühlanlagen werden nicht von mehreren Availability Zones geteilt. Die physische Trennung sorgt außerdem dafür, dass sogar bei äußerst seltenen Katastrophen wie Bränden, Stürmen oder Überflutungen nur eine Availability Zone betroffen ist. Availability Zones innerhalb derselben Region profitieren von einer Netzwerkverbindung mit niedrigen Latenzen.

F: Was bedeutet "primär" und "Standby" im Zusammenhang mit Multi-AZ-Bereitstellungen?

Wenn Sie eine DB Instance als Multi-AZ-Bereitstellung betreiben, dient die Primär-Instanz den Schreib– und Lesevorgängen in der Datenbank. Zusätzlich dazu stellt Amazon RDS im Hintergrund eine "Standby"-Instanz zur Verfügung, die eine stets aktuelle Replika der Primär-Instanz darstellt, und wartet diese. Bei Failover-Vorgängen wird die Standby-Instanz "hochgestuft". Nach dem Failover wird also die Standby-Instanz zur Primär-Instanz und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instanz (etwa bei Lesevorgängen). Wenn Sie den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus skalieren möchten, lesen Sie die Fragen und Antworten unter Read Replicas.

F: Welche Vorteile bietet eine Multi-AZ-Bereitstellung?

Die Hauptvorteile einer Ausführung Ihrer DB Instance als Multi-AZ-Bereitstellung sind die erhöhte Zuverlässigkeit und Verfügbarkeit der Datenbank. Dank ihrer erhöhten Verfügbarkeit und Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für wichtige Produktionsumgebungen.

Wenn Sie Ihre DB Instance als Multi-AZ-Bereitstellung ausführen, sind Ihre Daten im unwahrscheinlichen Fall, dass eine DB Instance-Komponente ausfällt oder der Dienst in einer Availability Zone unterbrochen wird, sicher. Wenn beispielsweise ein Speicher-Volume Ihrer Primär-Instance ausfällt, initiiert Amazon RDS automatisch einen Failover zur Standby-Instance, wo all Ihre Datenbank-Updates in intakter Form vorliegen. Dies bietet also zusätzliche Datenbeständigkeit im Vergleich zu Standard-Bereitstellungen in einer einzelnen AZ: Hier wäre eine vom Benutzer angestoßene Wiederherstellung erforderlich, und Updates, die nach dem letztmöglichen Wiederherstellungszeitpunkt (in der Regel in den letzten fünf Minuten) durchgeführt wurden, ständen nicht zur Verfügung.

Beim Betrieb Ihrer DB Instance als Multi-AZ-Bereitstellung profitieren Sie darüber hinaus von einer verbesserten Datenbankverfügbarkeit. Wenn es zu einem Ausfall einer Availability Zone oder DB-Instance kommt, wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, den das automatische Failover dauert (üblicherweise 3-6 Minuten). Die Verfügbarkeitsvorteile von Multi-AZ kommen auch bei geplanten Aktualisierungen zum Tragen. So werden E/A-Vorgänge in Ihrer Primär-Instanz beispielsweise bei automatisierten Backups im von Ihnen bestimmten Backup-Fenster nicht mehr unterbrochen, da die Backups von der Standby-Replika angefertigt werden. Im Fall von Patches oder Skalierungen der DB Instance-Klasse werden diese zunächst an der Standby-Replika vorgenommen, bevor der automatische Failover erfolgt. Das Ergebnis: Es kommt lediglich für die Dauer, die der automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit.

Ein weiterer Vorteil, den die Ausführung Ihrer DB Instance als Multi-AZ-Bereitstellung mit sich bringt, liegt darin, dass der DB Instance-Failover automatisch erfolgt und keine Wartungsarbeiten mit sich bringt. Im Hinblick auf Amazon RDS bedeutet das, dass Sie nicht die DB Instance-Ereignisse überwachen und eine manuelle Wiederherstellung der DB Instance anstoßen müssen (über die APIs "RestoreDBInstanceToPointInTime" oder "RestoreDBInstanceFromSnapshot"), sollte es zu einer Unterbrechung in einer Availability Zone oder zu einem DB Instance-Ausfall kommen.

F: Hat die Ausführung meiner DB Instance als Multi-AZ-Bereitstellung Auswirkungen auf die Leistung?

Aufgrund der synchronen Datenreplikation, die für Sie durchgeführt wird, kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB Instance in einer einzigen Availability Zone kommen.

F: Kann ich, wenn ich meine DB Instance als Multi-AZ-Bereitstellung betreibe, die Standby-Replika für Lese– oder Schreibvorgänge nutzen?

Nein, die Standby-Replika kann keine Leseanfragen bearbeiten. Der Zweck von Multi-AZ-Bereitstellungen ist eine Verbesserung der Datenbankverfügbarkeit und –zuverlässigkeit und nicht eine Skalierung der Lesevorgänge. Die Replikation zwischen primärer und Standby-Instanz erfolgt synchron. Durch unsere Implementierung wird sichergestellt, dass Primär– und Standby-Instanz konstant synchronisiert werden, gleichzeitig ist die Standby-Instanz aber von Lese– oder Schreibvorgängen ausgeschlossen. Wenn Sie sich für eine Lösung zur Skalierung der Lesevorgänge interessieren, erfahren Sie mehr in den häufig gestellten Fragen unter dem Punkt Read Replicas.

F: Wie richte ich eine Multi-AZ DB Instance-Bereitstellung ein?

Um eine Multi-AZ-Bereitstellung einer DB Instance einzurichten, klicken Sie einfach auf die Option "Yes" (Ja) für "Multi-AZ Deployment" (Multi-AZ-Bereitstellung", wenn Sie eine DB Instance mit der AWS Management Console starten. Wenn Sie die Amazon RDS-APIs verwenden, können Sie die "CreateDBInstance"-API nutzen und den Parameter "Multi-AZ" auf "true" setzen. Um eine bestehende, standardmäßige DB Instance (einzelne AZ) in eine Multi-AZ-Bereitstellung zu konvertieren, modifizieren Sie die DB Instance in der AWS Management Console oder verwenden Sie die "ModifyDBInstance"-API und setzen Sie den Parameter "Multi-AZ" auf "true".

F: Welche Ereignisse würden Amazon RDS zu einem Failover auf das Standby-Replikat veranlassen?

Bei Multi-AZ-Bereitstellungen erfolgt bei den meisten gängigen Ausfallszenarien nach deren Erkennen eine automatische Wiederherstellung durch Amazon RDS, sodass Sie ohne Verwaltungsaufwand Datenbankvorgänge schnellstmöglich fortsetzen können. Amazon RDS führt in den folgenden Szenarien automatisch ein Failover durch:

Verlust der Verfügbarkeit in der primären Availability Zone
Verlust der Netzwerkverbindung zur Primär-Instanz
Ausfall einer Datenverarbeitungseinheit in der Primär-Instanz
Speicherfehler in der Primär-Instanz

Hinweis: Wenn für Multi-AZ-Bereitstellungen Vorgänge wie die Skalierung von DB-Instances oder System-Upgrades wie das Einspielen von Betriebssystem-Patches ausgelöst werden, werden diese zur Optimierung der Verfügbarkeit vor einem automatischen Failover zunächst auf das Standby-Replikat angewendet. Es kommt deshalb lediglich für die Dauer, die das automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit. Hinweis: Bei Multi-AZ-Bereitstellungen von Amazon RDS erfolgt kein automatisches Failover als Reaktion auf Datenbankvorgänge wie lang andauernde Abfragen, gegenseitige Sperren (Deadlocks) oder Fehler aufgrund von Datenbankbeschädigungen.

F: Werde ich bei einem automatischen Failover benachrichtigt?

Ja, Amazon RDS veranlasst ein DB Instance-Ereignis, um Sie über den automatischen Failover zu informieren. Sie können die "DescribeEvents"-API verwenden, um Informationen zu Ereignissen im Zusammenhang mit Ihrer DB Instance abzurufen, oder auf den Abschnitt "DB Events" (DB-Ereignisse) der AWS Management Console klicken.

F: Was geschieht während eines Multi-AZ-Failovers, und wie viel Zeit nimmt dieser in Anspruch?

Der Failover wird automatisch von Amazon RDS durchgeführt, damit Sie den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können. Bei einem Failover wechselt Amazon RDS einfach den anerkannten Namensdatensatz (CNAME) für Ihre DB Instance, sodass auf die Standby-Replika verwiesen wird, die dadurch zur neuen Primär-Instanz hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, die gegebenenfalls erneut versucht, eine Datenbankverbindung herzustellen. Failover-Zeiten sind abhängig von der benötigten Dauer einer Wiederherstellung nach einem Systemausfall. Ein vollständiges Failover dauert in der Regel 3-6 Minuten.

F: Kann ich ein Failover für meine Multi-AZ-Bereitstellung von DB-Instances "erzwingen"?

Amazon RDS führt bei einer Vielzahl von Fehlerbedingungen automatisch ein Failover durch, ohne dass Benutzer eingreifen müssen. Zusätzlich bietet Amazon RDS eine Option zum Initiieren eines Failovers beim Neustarten Ihrer Instance. Sie können auf diese Funktion über die AWS Management Console oder bei Verwendung des RebootDBInstance-API-Aufrufs zugreifen.

F: Wie kontrolliere/konfiguriere ich die synchrone Multi-AZ-Replikation?

Bei Multi-AZ– Bereitstellungen setzen Sie einfach den "Multi-AZ"-Parameter auf "true". Die Erstellung der synchronen Standby-Replika und Failovers werden automatisch abgewickelt. Das bedeutet, dass Sie nicht die Availability Zone auswählen können, in der Ihre Standby-Replika bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instanzen verändern können (Amazon RDS erzeugt eine dedizierte Standby-Replika pro primärer DB Instance). Die Standby-Replika kann ferner nicht zur Bearbeitung von Datenbank-Lesevorgängen konfiguriert werden (klicken Sie hier für weitere Details).

F: Befindet sich meine Standby-Replika in derselben Region wie die Primär-Instanz?

Ja. Ihre Standby-Replika wird automatisch in einer anderen Availability Zone in derselben Region wie Ihre primäre DB Instance bereitgestellt.

F: Kann ich sehen, in welcher Availability Zone sich meine Primär-Instanz derzeit befindet?

Ja, Sie können über die AWS Management Console oder mithilfe der "DescribeDBInstances"-API den Speicherort der aktuellen Primär-Instanz ermitteln.

F: Nach einem Failover befindet sich meine Primär-Instanz nun in einer anderen Availability Zone als meine anderen AWS-Ressourcen (z. B. EC2-Instanzen). Muss ich mir Sorgen um Latenzen machen?

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen zu anderen Availability Zones derselben Region bereitzustellen. Zusätzlich empfiehlt es sich eventuell, die Architektur Ihrer Anwendung und anderer AWS-Architekturen mit Redundanzen über mehrere Availability Zones anzulegen, damit Ihre Anwendung bei einem Ausfall einer einzelnen Availability Zone geschützt ist. Bei Multi-AZ-Bereitstellungen ist dies auf Datenbankebene der Fall, ohne dass hierfür ein administratives Zutun Ihrerseits erforderlich ist.

F: Wie funktionieren DB Snapshots und automatisierte Backups im Zusammenhang mit meiner Multi-AZ-Bereitstellung?

Die Interaktion mit automatisierten Sicherungen und DB-Snapshot-Funktionalität ist bei Standardbereitstellungen in einer Single-AZ– oder Multi-AZ-Bereitstellung identisch. Wenn Sie eine Multi-AZ-Bereitstellung betreiben, werden automatisierte Sicherungen und DB-Snapshots mithilfe des Standby-Replikats erstellt, um eine E/A-Unterbrechung in der Primär-Instanz zu vermeiden. Beachten Sie, dass es bei Single-AZ– oder Multi-AZ-Bereitstellungen im Verlauf von Sicherungen zu einer erhöhten E-/A-Latenz (für gewöhnlich wenige Minuten) kommen kann.

Auch das Auslösen von Wiederherstellungsvorgängen (zeitpunktbezogene Wiederherstellung oder Wiederherstellung aus einem DB-Snapshot) erfolgt bei standardmäßigen Single-AZ– und Multi-AZ-Bereitstellungen gleich. Neue DB Instance-Bereitstellungen können mithilfe der APIs "RestoreDBInstanceFromSnapshot" oder "RestoreDBInstanceToPointInTime" erstellt werden. Diese neuen DB Instance-Bereitstellungen können entweder Standard– oder Multi-AZ-Bereitstellungen sein, unabhängig davon, ob das Quell-Backup von einer standardmäßigen oder einer Multi-AZ-Bereitstellung aus initiiert wurde.

MySQL

Read Replicas

F: Was bedeutet es, eine DB Instance als Read Replica zu betreiben?

Read Replicas sind die einfache Möglichkeit, die Vorteile der integrierten Replizierungsfunktionen von MySQL zu nutzen, um bei leseintensiven Datenbank-Arbeitslasten elastisch über die Kapazitätseinschränkungen einer einzelnen DB Instance hinaus zu skalieren. Read Replicas können mit wenigen Klicks in der AWS Management Console oder über die CreateDBInstanceReadReplica-API erstellt werden. Nach Erstellung der Read Replica werden Aktualisierungen an der Quell-DB-Instance unter Verwendung der nativen, asynchronen Replizierung von MySQL repliziert. Sie können mehrere Read Replicas für eine gegebene Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung darauf verteilen. Da Read Replicas die integrierte Replizierung von MySQL verwenden, unterliegen sie auch deren Stärken und Einschränkungen. Das bedeutet insbesondere, dass Updates in Ihren Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind, und die Verzögerung bei der Replizierung kann erheblichen Schwankungen unterliegen. Read Replicas können mit Multi-AZ-Bereitstellungen verbunden werden, um zusätzlich zu den Skalierungsvorteilen im Hinblick auf Lesevorgänge von der verbesserten Schreibverfügbarkeit der Datenbank und Datenbeständigkeit zu profitieren, die Multi-AZ-Bereitstellungen bieten.

F: Wann sollte ich die Verwendung einer Amazon RDS Read Replica in Erwägung ziehen?

Es gibt verschiedene Szenarios, in denen die Bereitstellung einer oder mehrerer Read Replicas für eine gegebene Quell-DB-Instance sinnvoll ist. Häufige Gründe für die Bereitstellung einer Read Replica:

Skalierung über die Rechen– oder E/A-Leistung einer einzelnen DB Instance bei Datenbank-Arbeitslasten mit umfassenden Lesevorgängen. Dieser zusätzliche Lesedatenverkehr kann an eine oder mehrere Read Replicas geleitet werden.
Unterstützung des Lesedatenverkehrs bei einer nicht verfügbaren Quell-DB-Instance. Wenn Ihre Quell-DB-Instance keine E/A-Anfragen bearbeiten kann (z. B. aufgrund von E/A-Einschränkungen für Backups oder geplante Wartungsarbeiten), können Sie den Lesedatenverkehr an Ihre Read Replica(s) leiten. Denken Sie in diesem Fall daran, dass die Daten in der Read Replica "veraltet" sein können, da die Quell-DB-Instance nicht verfügbar ist.
Berichterstattung in Unternehmen oder Data-Warehousing-Szenarios. Eventuell empfiehlt es sich, Anfragen zur geschäftlichen Berichterstattung über eine Read Replica und nicht über Ihre primäre DB Instance zur Produktion laufen zu lassen.

F: Welche Speicher-Engines werden zur Nutzung mit Read Replicas unterstützt?

Read Replicas erfordern eine Transaktions-Speicher-Engine und werden nur für die InnoDB-Speicher-Engine unterstützt.

Nicht-Transaktions-Engines, wie MyISAM, können verhindern, dass Read Replicas ordnungsgemäß funktionieren. Wenn Sie MyISAM dennoch gemeinsam mit Read Replicas einsetzen möchten, wird empfohlen, dass Sie die Amazon CloudWatch-Metrik "Replica Lag" sorgfältig überprüfen und die Read Replica erneut erstellen, wenn es aufgrund von Replikationsfehlern zu Verzögerungen kommt. (Die Metrik ist über die AWS Management Console oder über die Amazon CloudWatch-APIs verfügbar.) Dieselben Überlegungen treffen für die Verwendung von temporären Tabellen und anderen Nicht-Transaktions-Engines zu.

F: Wie stelle ich eine Read Replica für eine gegebene DB Instance bereit?

Read Replicas können binnen Minuten über die standardmäßige CreateDBInstanceReadReplica-API oder in wenigen Klicks mit der Amazon RDS Management Console erstellt werden. Beim Erstellen einer Read Replica können Sie sie durch Spezifizieren eines SourceDBInstanceIdentifier als Read Replica kennzeichnen. Der SourceDBInstanceIdentifier ist die DB Instance-Kennung der "Quell"-DB-Instance, aus der Sie Daten replizieren möchten. Wie bei einer standardmäßigen DB Instance können Sie auch die Availability Zone, DB Instance-Klasse und das bevorzugte Wartungsfenster festlegen. Die MySQL-Version (z. B. MySQL 5.1.50) und die Speicherzuweisung einer Read Replica werden aus der Quell-DB-Instance übernommen. Wenn Sie die Erstellung einer Read Replica anstoßen, fertigt Amazon RDS einen Snapshot Ihrer Quell-DB-Instance an und beginnt mit der Replizierung. Das hat eine kurze Aussetzung des E/A-Datenverkehrs Ihrer Quell-DB-Instance zur Folge. Diese Aussetzung dauert in der Regel nicht länger als eine Minute und kann vermieden werden, wenn es sich bei der DB Instance um eine Multi-AZ-Bereitstellung handelt (bei Multi-AZ-Bereitstellungen werden Snapshots von der Standby-Instanz angefertigt). Amazon RDS arbeitet derzeit auch an einer weiteren (in Kürze verfügbaren) Optimierung, mit der Sie mehrere Read Replicas innerhalb eines 30-minütigen Fensters erstellen können, wobei alle denselben Quell-Snapshot nutzen, um die E/A-Beeinträchtigung zu minimieren (die "Aufhol"-Replizierung für jede Read Replica beginnt dann nach der Erstellung).

Amazon RDS Read Replicas sind ebenso einfach zu löschen wie zu erstellen. Nutzen Sie hierfür einfach die Amazon RDS Management Console oder die DeleteDBInstance-API (wobei Sie den DBInstanceIdentifier für die Read Replica, die Sie löschen möchten, spezifizieren müssen).

Bei der Erstellungsanfrage für eine Read Replica müssen zusätzliche Faktoren berücksichtigt werden:

Wenn Sie eine nicht-transaktionale Engine wie beispielsweise MyISAM verwenden, müssen Sie folgende Schritte ausführen, um Ihre Read Replica korrekt zu erstellen. Diese Schritte sind unbedingt notwendig, damit sichergestellt ist, dass die Read Replica eine konsistente Kopie Ihrer Daten enthält. Beachten Sie, dass diese Schritte nicht erforderlich sind, wenn all Ihre Tabellen eine transaktionale Engine wie InnoDB nutzen. 1. Beenden Sie alle DML– und DDL-Vorgänge in nicht-transaktionalen Tabellen, und warten Sie, bis sie abgeschlossen sind. SELECT-Statements können weiter ausgeführt werden. 2. Leeren und sperren Sie diese Tabellen. 3. Erstellen Sie die Read Replica mithilfe der CreateDBInstanceReadReplica-API. 4. Überprüfen Sie den Fortschritt der Replica-Erstellung mithilfe der DescribeDBInstances-API. Sobald die Replica verfügbar ist, können Sie die Tabellen entsperren und den Datenbankbetrieb wieder aufnehmen.

Im Falle, dass es lang andauernde Transaktionen in Ihrer Quell-RDS-Instanz gibt, warten Sie, bis diese abgeschlossen sind, bevor Sie die Erstellung einer Read Replica aus dieser Quelle anfordern.

F: Wie stelle ich eine Verbindung zu meinen Read Replicas her?

Verbindungen mit einer Read Replica können wie mit einer Standard-DB-Instance über die DescribeDBInstance-API oder die AWS Management Console hergestellt werden, um den/die Endpunkt(e) für Ihre Read Replica(s) abzurufen. Wenn Sie mehrere Read Replicas nutzen, muss Ihre Anwendung bestimmen, wie der Lesedatenverkehr auf diese verteilt wird.

F: Wie viele Read Replicas kann ich für eine gegebene Quell-DB-Instance erstellen?

Derzeit bietet Amazon RDS Ihnen die Möglichkeit, bis zu fünf Read Replicas für eine gegebene Quell-DB-Instance zu erstellen.

F: Kann ich eine Read Replica nutzen, um die Datenbankverfügbarkeit für Schreibvorgänge zu erweitern oder Daten auf meiner Quell-DB-Instance gegen Ausfälle zu schützen?

Wenn Sie mithilfe von Replizierung die Schreibverfügbarkeit Ihrer Datenbank erhöhen und aktuelle Datenbank-Updates vor diversen Ausfallbedingungen schützen möchten, empfehlen wir Ihnen, Ihre DB Instance als Multi-AZ-Bereitstellung auszuführen. Mit Read Replicas und der nativen, asynchronen Replizierung von MySQL erfolgen die Schreibvorgänge in einer Read Replica erst, nachdem sie in der Quell-DB-Instance erfolgt sind, und diese Verzögerung bei der Replizierung kann erheblichen Schwankungen unterliegen. Im Gegensatz dazu erfolgt die Replizierung bei Multi-AZ-Bereitstellungen synchron, d. h., alle Datenbank-Schreibvorgänge erfolgen in der Primär– und der Standby-Instanz gleichzeitig. Damit sind Ihre aktuellsten Datenbank-Updates geschützt, da sie, falls ein Failover erforderlich wird, schon in der Standby-Instanz verfügbar sind. Darüber hinaus ist die Replizierung bei Multi-AZ-Bereitstellungen komplett verwaltet. Amazon RDS überwacht automatisch die DB Instance auf Ausfallbedingungen oder einen Ausfall der Availability Zone hin, und initiiert einen automatischen Failover zur Standby-Instanz, wenn es zu einem Ausfall kommt.

F: Kann ich eine Read Replica mit einer Multi-AZ-Bereitstellung einer DB Instance als Quelle erstellen?

Da Multi-AZ DB Instances auf andere Bedürfnisse als Read Replicas ausgelegt sind, ist es durchaus sinnvoll, beide Komponenten kombiniert für Produktionsbereitstellungen zu nutzen und einer Multi-AZ DB Instance-Bereitstellung eine Read Replica zuzuweisen. Die Multi-AZ "Quell"-DB-Instance bietet Ihnen eine erhöhte Schreibverfügbarkeit und eine höhere Datensicherheit, während die zugeordnete Read Replica die Skalierbarkeit des Lesedatenverkehrs verbessert.

F: Was geschieht im Fall eines Multi-AZ-Failovers, wenn meine Read Replica(s) eine Multi-AZ-Bereitstellung einer DB Instance als Quelle nutzt/nutzen?

Im Falle eines Multi-AZ-Failovers sollten alle zugeordneten und verfügbaren Read Replicas automatisch die Replizierung wiederaufnehmen, nachdem der Failover abgeschlossen wurde (d. h., sie beginnen mit dem Abrufen von Updates aus der neuen Primär-Instanz).

F: Meine Read Replica scheint nach einem Multi-AZ-Failover zu "hängen" und kann keine Updates von der Quell-DB-Instance abrufen oder anwenden. Was ist zu tun?

Gelegentlich kann es vorkommen, dass Ihre Read Replica(s) nach einem Multi-AZ-Failover keine Updates aus ihrer Multi-AZ Quell-DB-Instance empfangen oder anwenden kann/können. Das ist darauf zurückzuführen, dass einige MySQL-binlog-Ereignisse zum Zeitpunkt des Failovers nicht auf Festplatten verschoben wurden. Nach dem Failover kann es also sein, dass die Read Replica versucht, binlogs von der Quelle abzurufen, die dort nicht vorhanden sind. Weitere Informationen zu derartigen Verlusten von MySQL-binlogs bei einem Absturz finden Sie hier.

Besonders wichtig ist hierbei der Absatz am Seitenende, in dem der Sync-Binlog-Parameter von MySQL beschrieben wird. Dieser Parameter steuert, wie MySQL-binlogs auf Festplatten verschoben werden und wie bei einer Verwendung von InnoDB binlogs und InnoDB-Protokolle synchronisiert gehalten werden können.

Um das aktuelle Problem zu lösen, müssen Sie die Read Replica löschen und eine neue als Ersatz erstellen. Um das Problem in Zukunft zu vermeiden, lässt sich die Wahrscheinlichkeit, dass während eines Absturz– bzw. Failover-Szenarios MySQL-binlogs von der Read Replica benötigt werden, durch die Einstellung "sync-binlog=1" erheblich reduzieren. Wie auch in der Dokumentation zu MySQL erläutert wird, kann jedoch auch hierdurch das Problem nicht vollständig behoben werden. Um die Wahrscheinlichkeit noch weiter zu verringern, nehmen Sie die Einstellung "innodb_support_xa=1" vor. Beachten Sie, dass diese Variableneinstellungen Leistungseinbußen mit sich bringen können. Sowohl "sync_binlog" als auch "innodb_support_xa" sind dynamische Variablen. Sollten die Leistungseinbußen also zu hoch sein, können Sie sie ohne Ausfälle zurücksetzen.

Sie haben also letztendlich die Wahl zwischen mehr Leistung und einer Verbesserung der automatischen Resynchronisation von Read Replicas nach einem Quell-Multi-AZ-Failover. Einer der Vorteile von Amazon RDS Read Replicas ist, dass diese im Fall von Synchronisationsproblemen durch Löschen und Neuerstellen schnell erneut instanziiert werden können. So müssen Sie die Leistungseinbußen durch Einstellen von "sync-binlog" und/oder "innodb_support_xa" nicht hinnehmen, wenn Ihre Anforderungen auch durch manuelles Beseitigen und Neuerstellen von Read Replicas erfüllt sind.

F: Kann ich eine Read Replica einer anderen Read Replica erstellen?

Es ist nicht möglich, Read Replicas einer anderen Read Replica zu erstellen.

F: Können meine Read Replicas nur Lesevorgänge von Datenbanken akzeptieren?

Read Replicas sind darauf ausgelegt, Lesedatenverkehr zu unterstützen. Es kann allerdings auch Nutzungsszenarios geben, in denen fortgeschrittene Nutzer DDL-SQL-Statements (Data Definition Language) für eine Read Replica ausfüllen möchten. Beispiele hierfür wären das Hinzufügen eines Datenbank-Indexes zu einer für geschäftliche Berichterstattungen genutzten Read Replica, ohne dass derselbe Index zur korrespondierenden Quell-DB-Instance hinzugefügt wird. Wenn Sie andere Operationen als Lesevorgänge für eine gegebene Read Replica ermöglichen möchten, müssen Sie die aktive DB Parameter Group für die Read Replica modifizieren und den Parameter "read_only" auf "0" setzen.

F: Kann ich meine Read Replica zu einer "eigenständigen" DB-Instance hochstufen?

Ja. Weitere Informationen hierzu finden Sie im Amazon RDS User Guide.

F: Wird meine Read Replica mit ihrer Quell-DB-Instance auf dem neuesten Stand gehalten?

Updates an einer Quell-DB-Instance werden automatisch in allen zugeordneten Read Replicas repliziert. Bei der asynchronen Replizierungstechnologie von MySQL kann es jedoch aus verschiedenen Gründen dazu kommen, das eine Read Replica hinter ihrer Quell-DB-Instance "hinterher hängt". Typische Gründe hierfür sind:

Das Schreiben von E/A-Volumen auf die Quell-DB-Instance überschreitet die Rate, bei der Änderungen an der Read Replica vorgenommen werden können. Dieses Problem tritt insbesondere auf, wenn die Rechenleistung einer Read Replica geringer als die der Quell-DB-Instance ist.
Komplexe oder lange andauernde Transaktionen auf die Quell-DB-Instance beeinträchtigen die Replizierung auf die Read Replica.
Netzwerk-Partitionen oder Latenzen zwischen der Quell-DB-Instance und einer Read Replica

Read Replicas unterliegen den Stärken und Einschränkungen der MySQL-Replizierung. Wenn Sie Read Replicas verwenden, sollten Sie sich über die potenziellen Verzögerungen zwischen einer Read Replica und ihrer Quell-DB-Instance (die sogenannten "Inkonsistenzen") bewusst sein. Klicken Sie hier für Tipps zur Handhabung von Read Replicas, die deutlich hinter ihrer Quelle zurückliegen.

F: Wie erlange ich Einblick in aktive Read Replica(s)?

Sie können die Standard-API "DescribeDBInstances" nutzen, um eine Liste aller von Ihnen bereitgestellten DB Instances (inklusive Read Replicas) ausgeben zu lassen, oder einfach in der Amazon RDS Management Console auf die Registerkarte "DB Instances" klicken.

Mit Amazon RDS können Sie ermitteln, wie weit eine Read Replica hinter ihrer Quell-DB-Instance zurückgefallen ist, indem Sie den Standard-MySQL-Befehl "Show Slave Status" für die Read Replica ausgeben. Die von "Show Slave Status" ausgegebenen Daten ("Seconds_Behind_Master") werden auch als Amazon CloudWatch-Metrik ("Replica Lag") über die AWS Management Console oder Amazon CloudWatch-APIs ausgegeben.

F: Meine Read Replica liegt deutlich hinter ihrer Quell-DB-Instance zurück. Was soll ich tun?

Wie in den vorherigen Fragen erörtert, sind "Inkonsistenzen" oder Verzögerungen zwischen einer Read Replica und ihrer Quell-DB-Instance ein häufiges Problem bei der asynchronen Replizierung mit MySQL. Wenn eine bestehende Read Replica zu weit zurückgefallen ist, um Ihre Anforderungen zu erfüllen, können Sie sie löschen und eine neue mit demselben Endpunkt erstellen, indem Sie denselben DB Instance Identifier und Quell-DB-Instance-Identifier wie bei der gelöschten Read Replica verwenden. Denken Sie daran, dass der Neuerstellungsprozess bei geringfügigen Verzögerungen (z. B. weniger als fünf Minuten Verzögerung) kontraproduktiv ist und mit Bedacht genutzt werden sollte (d. h. nur, wenn die Read Replica deutlich hinter ihrer Quell-DB-Instance zurückliegt). Beachten Sie außerdem, dass Replica-Verzögerungen im Laufe der Zeit natürlich ab– und zunehmen können, abhängig vom jeweiligen Auslastungsmuster Ihrer Quell-DB-Instance.

Durch Skalieren der DB Instance-Klasse einer Read Replica können Verzögerungen in einigen Fällen verringert werden, insbesondere, wenn Ihre Quell-DB-Instance-Klasse höher als die Klasse Ihrer Read Replica DB Instance ist. Dennoch ist es nicht garantiert, dass Read Replicas in allen Fällen funktionieren. Es kann Szenarios und Nutzungsmuster geben, in denen eine Read Replica nach ihrer ersten Erstellung nie ganz zur Quelle aufholt oder zu weit hinter ihr zurückbleibt, um Ihre individuellen Anforderungen zu erfüllen.

F: Ich habe die Datenverarbeitungs– und/oder Speicherkapazität meiner Quell-DB-Instance skaliert. Soll ich auch die Ressourcen für die entsprechende(n) Read Replica(s) skalieren?

Für eine effektiv funktionierende Replizierung empfehlen wir, Read Replicas gleich viel oder mehr Rechen– und Speicherressourcen zuzuweisen wie ihren entsprechenden Quell-DB-Instances. Andernfalls ist es wahrscheinlich, dass es zu größeren Verzögerungen bei der Replizierung kommt oder dass ihre Read Replica nicht über genügend Speicherplatz zur Speicherung replizierter Updates verfügt.

F: Kann ich die Replizierung zwischen meiner Quell-DB-Instance und einer Read Replica zur Verwendung zeilenbasierter Replizierung konfigurieren?

Standardmäßig ist die Replizierung auf ein Mischformat (das sowohl zeilen– als auch Statement-basierte Replizierung beinhaltet) eingestellt, mit dem die Anforderungen der meisten Nutzungsszenarien erfüllt sein sollten. Wenn Sie jedoch ein fortgeschrittener Benutzer sind und festlegen möchten, dass eine zeilenbasierte Replizierung verwendet wird, können Sie dies sitzungsbasiert bestimmen, indem Sie das binlog_format für eine DB Instance mit einem SQL-Befehl auf "row" (Zeile) setzen. Weitere Informationen über den Unterschied zwischen einer Mischformat-Replizierung und der zeilenbasierten Replizierung finden Sie in der MySQL-Dokumentation

F: Kann ich DB Snapshots oder automatisierte Backups von Read Replicas anfertigen?

Nein. Wenn Sie die Schreibverfügbarkeit der Datenbank erhöhen möchten, indem Sie Backups von Ihrer Read Replica statt von der Quell-DB-Instance anfordern, können Sie dieses Ziel auch erreichen, indem Sie Ihre DB Instance als Multi-AZ-Bereitstellung ausführen. Backups werden dann von der Multi-AZ-Standby-Instanz initiiert, um die Beeinträchtigung der Verfügbarkeit zu minimieren.

F: Wie lösche ich eine Read Replica? Wird sie automatisch gelöscht, wenn die Quell-DB-Instance gelöscht wird?

Sie können eine Read Replica ganz einfach mit wenigen Klicks in der AWS Management Console oder durch Weitergabe ihres DB Instance Identifier an die DeleteDBInstance-API löschen. Eine Read Replica bleibt selbst dann aktiv und nimmt weiterhin Lesedatenverkehr entgegen, wenn ihre zugehörige Quell-DB-Instance gelöscht wurde. Wenn Sie die Read Replica zusätzlich zur Quell-DB-Instance löschen möchten, müssen Sie die Read Replica explizit über die DeleteDBInstance-API oder die AWS Management Console löschen.

F: Kann ich die binären Protokolle für meine Datenbank-Instanz direkt aufrufen, um meine eigene Replizierung zu verwalten?

Amazon RDS bietet derzeit keinen Zugriff auf die binären Protokolle für Ihre Datenbank-Instanz an.

F: Wie viel kosten Read Replicas? Wann beginnt und endet die Abrechnung?

Eine Read Replica wird als standardmäßige DB Instance zu denselben Tarifen abgerechnet. Klicken Sie hier, um die häufig gestellten Fragen zur Fakturierung von DB-Instances durchzugehen. Wie bei einer standardmäßigen DB Instance auch wird der Tarif pro "DB Instance-Stunde" für eine Read Replica durch die DB Instance-Klasse der Read Replica bestimmt – aktuelle Preisangaben finden Sie auf der Detailseite von Amazon RDS. Der bei der Replizierung von Daten zwischen Ihrer Quell-DB-Instance und der Read Replica anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt. Die Fakturierung für eine Read Replica beginnt, sobald diese erfolgreich erstellt wurde (d. h., wenn ihr Status als "aktiv" gelistet ist). Die Read Replica wird so lange nach standardmäßigen DB Instance-Stundensätzen von Amazon RDS abgerechnet, bis Sie den Befehl ausgeben, sie zu löschen.

Versionsmanagement für DB Engines

F: Kann ich steuern, ob und wann die der Amazon RDS DB Instance zugrunde liegende MySQL-Version auf neue unterstützte Versionen aktualisiert wird?

Mit Amazon RDS können Sie steuern, ob und wann die Ihrer DB Instance zugrunde liegende relationale Datenbanksoftware (z. B. MySQL) auf neue, von Amazon RDS unterstützte Versionen aktualisiert wird. Damit bleiben Sie flexibel – Sie können die Kompatibilität mit spezifischen MySQL-Versionen sicherstellen, neue Versionen mit Ihrer Anwendung testen, bevor Sie sie in der Produktionsumgebung bereitstellen, und Versions-Upgrades nach Ihren eigenen Vorstellungen und Zeitplänen durchführen.

Sofern nicht anders von Ihnen festgelegt, wird Ihre DB Instance automatisch auf kleinere neue MySQL-Versionen aktualisiert, wenn diese durch Amazon RDS unterstützt werden. Diese Patches werden während Ihres geplanten Aktualisierungsfensters vorgenommen und vorher im Amazon RDS-Forum angekündigt. Wenn Sie automatische Versions-Upgrades deaktivieren möchten, setzen Sie den Parameter "AutoMinorVersionUpgrade" auf "false". Da größere Versions-Upgrades einige Kompatibilitätsrisiken mit sich bringen, werden sie nicht automatisch durchgeführt, sondern müssen von Ihnen initiiert werden.

Mit diesem Ansatz für Datenbanksoftware-Patches behalten Sie die Kontrolle über Versions-Upgrades und übertragen gleichzeitig die mit Patches verbundene Arbeit an Amazon RDS. Weitere Informationen über das Versionsmanagement erhalten Sie unter den folgenden, häufig gestellten Fragen. Alternativ finden Sie auch im Entwicklerhandbuch mehr zu diesem Thema.

Während die Versionsmanagement-Funktion für DB Engines Ihnen die größtmögliche Kontrolle über Patch-Vorgänge geben soll, behält sich Amazon RDS das Recht vor, Ihre DB Instance in Ihrem Namen zu patchen, sollte es zu kritischen Sicherheitsschwachstellen in der Datenbanksoftware kommen.

F: Wie kann ich festlegen, welche unterstützte MySQL-Version ich zur Ausführung meiner DB Instance nutzen möchte?

Beim Erstellen einer neuen DB Instance über die CreateDBInstance-API können Sie jede beliebige Version angeben, die derzeit unterstützt wird (kleinere und/oder größere). Bei der Erstellung halten Sie hierfür die gewünschte Version einfach im EngineVersion-Parameter fest. Wenn keine Version spezifiziert wird, wählt Amazon RDS standardmäßig eine unterstützte Version, üblicherweise die aktuellste. Wenn eine größere Version (z. B. MySQL 5.1), aber keine kleinere spezifiziert wird, verwendet Amazon RDS standardmäßig eine aktuelle Veröffentlichung der größeren Version, die Sie angegeben haben. Eine Liste aller unterstützten Versionen sowie der Standardversionen für neu erstellte DB Instances können Sie einfach über die DescribeDBEngineVersions-API aufrufen.

Wenn Sie automatisch geplante Upgrades durch Setzen des Parameters "AutoMinorVersionUpgrade" auf "false" deaktiviert haben, aber manuell ein unterstütztes, größeres oder kleineres Versions-Upgrade initiieren möchten, können Sie dies mithilfe der ModifyDBInstance-API tun. Geben Sie einfach die Version, auf die Sie upgraden möchten, über den EngineVersion-Parameter an. Das Upgrade wird dann in Ihrem Namen entweder sofort (sofern der Schalter "ApplyImmediately" auf "true" gesetzt wurde) oder während des nächsten geplanten Wartungsfensters für Ihre DB Instance ausgeführt.

F: Kann ich neue Versionen für meine DB Instance testen, bevor ich ein Upgrade durchführe?

Ja. Erstellen Sie hierfür einen DB Snapshot Ihrer bestehenden DB Instance, stellen Sie aus dem DB Snapshot eine neue DB Instance her und initiieren Sie dann ein Versions-Upgrade für die neue DB Instance. Nun können Sie ungefährdet mit dem aktualisierten "Klon" ihrer DB Instance experimentieren, bevor Sie entscheiden, ob Sie Ihre ursprüngliche DB Instance upgraden möchten.

F: Wie unterscheidet Amazon RDS zwischen "größeren" und "kleineren" Versions-Updates?

Im Kontext von MySQL lauten Versionsnummern wie folgt:

MySQL-Version = X.Y.Z

X = größere Version, Y = Veröffentlichungsstufe, Z = Versionsnummer innerhalb einer Veröffentlichungsstufe.

Aus Sicht von Amazon RDS wird eine Versionsänderung als groß angesehen, wenn sich entweder die Hauptversion oder Veröffentlichungsstufe ändert. Beispiel: Wechsel von 5.1.X auf 5.5.x. Als kleiner wird eine Versionsänderung angesehen, wenn sich nur die Versionsnummer innerhalb der Veröffentlichung ändert. Beispiel: Wechsel von 5.1.45 auf 5.1.49.

Ab sofort unterstützt Amazon RDS die größeren Versionen MySQL 5.1 und MySQL 5.5. Künftig kommen weitere größere MySQL-Versionen hinzu.

F: Stellt Amazon RDS Richtlinien zur Unterstützung neuer MySQL-Versions-Updates und/oder zur Ablehnung aktuell unterstützter MySQL-Versionen bereit?

Wir planen, im weiteren Verlauf zusätzliche MySQL-Versionen für Amazon RDS zu unterstützen, sowohl größere als auch kleinere. Die Anzahl der in einem bestimmten Jahr unterstützten neuen Versions-Updates wird von der Häufigkeit und den Inhalten der veröffentlichten MySQL-Versions-Updates abhängen, und selbstverständlich wird jede neue Version eingehend von unseren Datenbanktechnikern geprüft, bevor eine Unterstützung erfolgt. Als allgemeine Leitlinie können wir aber sagen, dass wir versuchen, neue MySQL-Versionen innerhalb von 3-5 Monaten nach ihrer allgemeinen Einführung zu unterstützen.

Im Hinblick auf veraltete Versionen gilt:

Wir versuchen, größere MySQL-Versionen, darunter MySQL 5.1, über einen Zeitraum von drei Jahren ab der ersten Einführung für Amazon RDS zu unterstützen.
Kleinere MySQL-Versionen (z. B. MySQL 5.1.45) sollen nach ihrer ersten Einführung für Amazon RDS mindestens ein Jahr unterstützt werden.
Nachdem eine größere oder kleinere MySQL-Version als "veraltet" eingestuft wurde, werden wir voraussichtlich einen dreimonatigen Übergangszeitraum einräumen, in dem Sie selbst ein Upgrade auf eine unterstützte Version ausführen können, bevor ein automatisches Upgrade während Ihres geplanten Wartungsfensters vorgenommen wird.

F: Wie erstelle ich eine MySQL 5.5 DB Instance oder wie kann ich meine vorhandene MySQL 5.1 DB Instance auf MySQL 5.5 aktualisieren?

Zu Erstellung einer neuen MySQL 5.5 DB Instance verwenden Sie den "Launch DB Instance Wizard" (Assistent zur Erstellung von DB Instances) in der AWS Management Console. Wählen Sie dabei eine Version aus, die MySQL 5.5 entspricht, oder benennen Sie die API "CreateDBInstance" mit dem Versionsparameter der Engine, also "5.5".

Derzeit wird ein direktes Upgrade von MySQL 5.1 auf MySQL 5.5 nicht unterstützt. Wir bemühen uns jedoch, diese Funktion künftig bereitzustellen. Wenn Sie Ihre vorhandene MySQL 5.1-Datenbank in MySQL 5.5 ändern möchten, können Sie mysqldump verwenden, um Ihre Datenbank von Ihrer vorhandenen MySQL 5.1 DB Instance zu exportieren und in eine neue MySQL 5.5 DB Instance zu importieren.

Oracle

Lizenzierung und Support

F: Welche Lizenzierungsarten stehen für Amazon for Oracle zur Verfügung?

Es stehen zwei Arten an Lizenzierungsoptionen zur Verwendung von Amazon RDS für Oracle zur Verfügung:

Bring Your Own License (BYOL): Bei diesem Lizenzmodell können Sie Ihre bestehenden Oracle Database-Lizenzen verwenden, um Oracle-Bereitstellungen auf Amazon RDS zu verwenden. Um eine DB Instance unter dem BYOL-Dienstmodell (Verwendung Ihrer eigenen Lizenz) auszuführen, müssen Sie die entsprechende Oracle Datenbanklizenz (mit Software-Aktualisierungslizenz und Support) für die DB Instance-Klasse und Oracle Datenbankedition besitzen, die Sie ausführen möchten. Außerdem müssen Sie die Oracle-Richtlinien für die Lizenzierung von Oracle Database Software in der Cloud Computing-Umgebung befolgen. DB-Instances befinden sich in der Amazon EC2-Umgebung, und die Oracle-Lizenzierungsrichtlinie für Amazon EC2 befindet sich hier.
Lizenz eingeschlossen: Unter dem Dienstmodell "Lizenz eingeschlossen" benötigen Sie keine getrennt erworbenen Oracle-Lizenzen. Die Oracle Datenbank-Software wurde von AWS lizenziert. Preise für "Lizenz eingeschlossen" gelten für Software, zugrunde liegende Hardware-Ressourcen sowie Amazon RDS-Verwaltungsfunktionen.

F: Welche Oracle Database Editionen stehen mit Amazon RDS für Oracle zur Verfügung?

Amazon RDS unterstützt derzeit die folgenden Oracle Database Editionen unter den folgenden untenstehenden Lizenzmodellen:

BYOL: Standard Edition One (SE1), Standard Edition (SE) und Enterprise Edition (EE)
Lizenz eingeschlossen: Standard Edition One (SE1)

F: Wie lauten die Lizenzierungsbedingungen für die Verwendung von Amazon RDS für Oracle?

BYOL:Um eine DB Instance unter dem BYOL-Dienstmodell (Verwendung Ihrer eigenen Lizenz) auszuführen, müssen Sie die entsprechende Oracle Datenbanklizenz (mit Software-Aktualisierungslizenz und Support) für die DB Instance-Klasse und Oracle Datenbankedition besitzen, die Sie ausführen möchten. Sie müssen die Oracle-Richtlinien für die Lizenzierung von Oracle Database Software in der Cloud Computing-Umgebung befolgen. DB Instances befinden sich in der Amazon EC2-Umgebung und die Oracle-Lizenzrichtlinie für Amazon EC2 befindet sich hier.
Lizenz eingeschlossen: Unter dem Dienstmodell "Lizenz eingeschlossen" benötigen Sie keine getrennt erworbenen Oracle-Lizenzen. Die Oracle Datenbank-Software wurde von AWS lizenziert.

F: Wie wird Amazon RDS für Oracle unterstützt?

BYOL: Unter diesem Modell werden Sie Ihr aktives Oracle-Supportkonto weiter verwenden und für spezifische Oracle Database Serviceanfragen Oracle direkt kontaktieren. Falls Sie über ein aktives AWS Premium Support-Konto verfügen, können Sie AWS Premium Support für spezifische Amazon RDS-Anfragen kontaktieren. Amazon Web Services und Oracle verfügen über einen Support durch mehrere Anbieter für Fälle in denen die Unterstützung von beiden Unternehmen notwendig ist.
Lizenz eingeschlossen: In diesem Modell sollten Sie, wenn Sie über ein AWS Premium Support-Konto verfügen, AWS Premium Support bei spezifischen Serviceanfragen sowohl für Amazon RDS als auch für Oracle Database kontaktieren.

F: Kann ich die Lizenzoption für meine DB Instance ändern (z. B. von "BYOL" zu "Lizenz eingeschlossen")?

Ja, Sie können Ihre Lizenzoption ändern. Sie müssen allerdings Ihre aktuelle DB Instance mit einem letzten Snapshot löschen und von diesem Snapshot aus eine neue DB Instance erstellen, wobei die neue Lizenzoption festgelegt werden muss, die Sie brauchen.

Versionsmanagement für DB-Engines

F: Was sind Amazon RDS DB Engine Versionen für Oracle und in welcher Beziehung stehen Sie zu den Oracle Patch Sets?

Im Kontext von Oracle sind die Amazon RDS DB Engine Versionen wie folgt organisiert:

DB Engine Versions for Oracle = X.Y.Z

X = Hauptversion (z. B.: 11.2), Y = Release Level (z. B.: 0.2), Z = Versionsnummer innerhalb der Release Serie (z. B.: v2). Zum Beispiel, ein DB Engine-Version für Oracle könnte lauten 11.2.0.2.v2.

Oracle veröffentlicht Database Patch Set Updates (PSU) für unterstützte Release Levels auf vierteljährlicher Basis. (z. B. 11.2.0.2.1). Zu den PSUs gehören Sicherheitsaktualisierungen und zusätzliche, nicht sicherheitsrelevante Aktualisierungen, die von Oracle empfohlen werden.

Die Amazon RDS DB Engine Versionen werden mit einem gegebenen PSU als Baseline ausgestattet und enthalten zusätzliche Aktualisierungen, die darüber hinausgehen.

Aus Sicht von Amazon RDS wird eine Versionsänderung als groß angesehen, wenn sich entweder die größere Version oder die Veröffentlichungsstufe ändert. Beispiel: Wechsel von 11.2.0.2.Z auf 11.2.0.4.Z. Als kleiner wird eine Versionsänderung angesehen, wenn sich nur die Versionsnummer innerhalb der Veröffentlichung ändert. Beispiel: ein Wechsel von 11.2.0.2.v2 auf 11.2.0.2.v3.

Ab heute unterstützt Amazon RDS die größere Version 11.2 (11g Release 2). Wir planen, dass zukünftig zusätzliche größere Versionen unterstützt werden.

F: Wie lautet die Patchset-Komposition von my DB Engine-Version für Oracle?

Informationen zur Zusammenstellung des Patch-Sets der einzelnen DB-Engine-Versionen von Oracle finden Sie im Amazon RDS-Benutzerhandbuch.

F: Kann ich kontrollieren, wann meine DB Instance auf eine neue DB Engine-Version für Oracle aktualisiert werden könnte?

Mit Amazon RDS können Sie steuern, ob und wann die Ihrer DB Instance zugrunde liegende relationale Datenbanksoftware auf neue, von Amazon RDS unterstützte Versionen aktualisiert wird. Damit bleiben Sie flexibel – Sie können die Kompatibilität mit spezifischen Oracle Database-Versionen sicherstellen, neue Versionen mit Ihrer Anwendung testen, bevor Sie sie in der Produktionsumgebung bereitstellen, und Versions-Upgrades nach Ihren eigenen Vorstellungen und Zeitplänen durchführen.

Sofern nicht anders von Ihnen festgelegt, wird Ihre DB Instance automatisch auf kleinere neue DB Engine-Versionen aktualisiert, wenn diese durch Amazon RDS unterstützt werden. Diese Patches werden während Ihres geplanten Wartungsfensters vorgenommen und vorher im Amazon RDS-Forum angekündigt. Falls Sie die automatische Versionsaktualisierung lieber ausstellen, können Sie dies tun, indem Sie das Feld "Auto Minor Version Upgrade" auf "No" stellen. Da größere Versions-Upgrades einige Kompatibilitätsrisiken mit sich bringen, werden sie nicht automatisch durchgeführt, sondern müssen von Ihnen initiiert werden.

Während die Versionsmanagement-Funktion für DB Engines Ihnen die größtmögliche Kontrolle über Patch-Vorgänge geben soll, kann Amazon RDS Ihre DB Instance in Ihrem Namen patchen, sollte es zu kritischen Sicherheitsschwachstellen in der Datenbanksoftware kommen.

Im Modell "Lizenz eingeschlossen" sind die Kosten für eine "Softwareaktualisierungslizenz" im Stundenpreis mit eingeschlossen, wodurch der Zugriff auf die Oracle Database-Softwareaktualisierungen möglich ist. Unter dem BYOL-Modell sollten Sie über die "Lizenz & Support für ein Software-Update" von Oracle verfügen, um die Amazon RDS für Oracle Database nutzen zu können.

F: Wie kann ich festlegen, welche unterstützte DB Engine-Version ich zur Ausführung meiner DB Instance nutzen möchte?

Sie können alle aktuell unterstützten Versionen klein und/oder groß festlegen, wenn Sie eine neue DB Instance über die Option "Launch DB Instance" in der AWS Management Console oder der CreateDBInstance API erstellen.

Wenn Sie automatisch geplante Upgrades durch Setzen des Parameters "AutoMinorVersionUpgrade" auf "false" deaktiviert haben, aber manuell ein unterstütztes, größeres oder kleineres Versions-Upgrade initiieren möchten, können Sie dies mithilfe der ModifyDBInstance-API tun. Geben Sie einfach die Version, auf die Sie upgraden möchten, über den EngineVersion-Parameter an. Das Upgrade wird dann in Ihrem Namen entweder sofort (sofern der Schalter "ApplyImmediately" gesetzt wurde) oder während des nächsten geplanten Wartungsfensters für Ihre DB Instance ausgeführt.

F: Kann ich neue Versionen für meine DB Instance testen, bevor ich ein Upgrade durchführe?

F: Stellt Amazon RDS Richtlinien zur Unterstützung der neuen DB Engine-Versionen für Oracle zur Verfügung und/oder der veralteten DB Engine-Versionen für Oracle, die derzeit unterstützt werden?

Wir planen, im weiteren Verlauf zusätzliche Oracle Database-Versionen für Amazon RDS zu unterstützen, sowohl größere als auch kleinere.. Die Anzahl der in einem bestimmten Jahr unterstützten neuen Versions-Updates wird von der Häufigkeit und den Inhalten der veröffentlichten Oracle Patch Set Updates (PSUs) abhängen, und selbstverständlich wird jede neue Version eingehend von unseren Datenbanktechnikern geprüft, bevor eine Unterstützung erfolgt. Als allgemeine Leitlinie können wir aber sagen, dass wir versuchen, neue Oracle Database-Versionen innerhalb von 3-5 Monaten nach ihrer allgemeinen Einführung zu unterstützen.

Im Hinblick auf veraltete Versionen gilt:

Wir versuchen, größere Versionen über einen Zeitraum von drei Jahren ab der ersten Einführung für Amazon RDS zu unterstützen.
Kleinere Oracle Database-Versionen (z. B. 11.2.0.2.v2) sollen nach ihrer ersten Einführung für Amazon RDS mindestens ein Jahr unterstützt werden.
Nachdem eine größere oder kleinere Version als "veraltet" eingestuft wurde, werden wir voraussichtlich einen dreimonatigen Übergangszeitraum einräumen, in dem Sie selbst ein Upgrade auf eine unterstützte Version ausführen können, bevor ein automatisches Upgrade während Ihres geplanten Wartungsfensters vorgenommen wird.

Skalierung

F: Kann ich meine DB Instance skalieren?

Für das BYOL-Modell gilt, dass Sie Ihre DB Instance in Einhaltung der Geschäftsbedingungen Ihrer Oracle Lizenz(en) skalieren können.

Für das Modell "Lizenz eingeschlossen" gilt, dass auf Oracle laufende DB Instances zu jeder Zeit nach oben oder nach unten skaliert werden können, abhängig von den gegebenen Stundenpreis für jede DB Instance-Klasse.

Für weitere Informationen zu den Auswirkungen des Skalierens von Reservierten DB Instances, lesen Sie unsere FAQs zu Reservierten DB Instances.

F: Kann ich die Oracle Edition, die bei mir läuft, zu einer DB Instance ändern (z. B. von Oracle 11g R2 SE1 zu EE)?

Für das BYOL-Modell können Sie von einer Oracle Softwareedition zu einer anderen migrieren, solange Sie eine noch nicht verwendete Oracle Lizenz besitzen, die Ihrer Edition und Klasse der DB Instance entspricht, die Sie laufen lassen wollen. Um die Edition zu wechseln und um Ihre Daten zu behalten, sollten Sie einen Snapshot Ihrer laufenden DB Instance machen und dann eine neue DB Instance Ihrer gewünschten Edition von diesem Snapshot aus erstellen. Sie sollten dann die alte DB Instance löschen, außer Sie wollen diese gerne weiter laufen lassen und verfügen über die entsprechende Oracle Database-Lizenzen.

Für das Modell "Lizenz eingeschlossen" wird derzeit nur die Oracle Standard Edition One unterstützt.

Optionen/Funktionen

F: Welche Replizierungsarten unterstützt Amazon RDS für Oracle?

Amazon RDS für Oracle unterstützt Multi-AZ-Bereitstellungen für die Lizenzierungsmodelle "License Included" (Lizenz eingeschlossen) und "Bring Your Own License (BYOL)" (Verwendung der eigenen Lizenz).

F: Verwendet Amazon RDS Oracle Data Guard für Multi-AZ-Bereitstellungen?

Die Funktion Oracle Data Guard gewährleistet eine hohe Verfügbarkeit der Enterprise Edition einer Oracle-Datenbank. Amazon RDS verwendet derzeit eine andere Technologie der synchronen Replikation und eine andere Funktion für den automatischen Failover für Multi-AZ-Bereitstellungen für Oracle DB-Instances. Multi-AZ-Bereitstellungen sind für alle von Amazon RDS unterstützten Oracle-Datenbank-Editions verfügbar.

F: Benötige ich eine/mehrere zusätzliche Lizenz(en), wenn ich Multi-AZ-Bereitstellungen für meine Oracle DB-Instances unter dem Lizenzmodell "BYOL" verwende?

Ja, wir gehen davon aus, dass Sie aufgrund der Standby-DB-Instance für Multi-AZ-Bereitstellungen etwa doppelt so viele Lizenzen wie für entsprechende Single-AZ-Bereitstellungen benötigen. Sie sollten jedoch Ihre Oracle Software-Lizenzvereinbarung lesen und die Lizenzrichtlinien von Oracle erfüllen.

F: Wird Oracle RAC auf Amazon RDS unterstützt?

Nein, RAC wird derzeit nicht unterstützt.

F: Welche Enterprise Edition Optionen werden auf Amazon RDS unterstützt?

Die folgenden Enterprise Edition-Optionen werden derzeit unter dem BYOL-Modell unterstützt:

Advanced Security (Transparent Data Encryption, Native Network Encryption)
Partitioning
Management Packs (Diagnostic, Tuning)
Advanced Compression
Total Recall

F: Welche Zeichensätze werden von Amazon RDS für Oracle unterstützt?

Amazon RDS unterstützt die 30 Zeichensätze in der Liste der von Oracle empfohlenen ASCII-Zeichensätze für Datenbanken. Beim Erstellen einer neuen DB-Instance können Sie Ihren bevorzugten Zeichensatz festlegen. Dieser Schritt ist optional. Der Standardzeichensatz ist AL32UTF8. Weitere Informationen finden Sie in der Dokumentation zu Amazon RDS.

F: Wer verwaltet Oracle Wallet und Master Encryption Key bei Verwenden der Transparent Data Encryption für Amazon RDS?

Amazon RDS verwaltet Oracle Wallet und Master Encryption Key für die DB-Instance.

F: Woher weiß ich, ob Amazon RDS eine bestimmte Oracle Datenbankfunktion unterstützt?

Oracle Database unterstützt eine Reihe von Funktionen, die von der Edition der Oracle Datenbank abhängen, die Sie verwenden. Bitte lesen Sie das Amazon RDS User Guide, um mehr über die Oracle Funktionen zu erfahren, die Amazon RDS derzeit unterstützt.

↑ Seitenanfang

Produkte und Dienstleistungen

Amazon RDS

Unterstützte DB Engines

Funktionen

Entwicklerressourcen

Unsere Kunden

Kosteneinsparungen

Erfahren Sie, wie mit Amazon RDS im Vergleich zu Optionen, bei denen Datenbanken in einem Rechenzentrum (Colocation) oder vor Ort untergebracht sind, Kosten eingespart werden können.

› Amazon RDS Kostenvergleichsrechner herunterladen

Datenbanken in der Cloud

Erfahren Sie, wie Sie die Vorteile der Cloud auf die Datenbank ausweiten können.

Weitere Informationen

Datenbankoptionen

Erfahren Sie, welche Alternativen Sie beim Ausführen von Datenbanken in AWS haben.

Weitere Informationen

Das Amazon RDS Datenblatt erhalten

Ein Überblick über die Hauptfunktionen von Amazon RDS

> PDF herunterladen

Amazon RDS – Häufig gestellte Fragen

Allgemeines

Das Wesentliche

Fakturierung

Reserved Instances

Hardware und Skalierung

Automatische Backups und Datenbank-Snapshots

Sicherheit

DB Parameter Groups

Replizierung

Multi-AZ-Bereitstellungen

MySQL

Read Replicas

Versionsmanagement für DB-Engines

Oracle

Lizenzierung und Support

Versionsmanagement für DB-Engines

Scaling

Funktionen

SQL Server

Allgemeines

Das Wesentliche

Fakturierung

Reserved Instances

Hardware und Skalierung

Automatische Backups und Datenbank-Snapshots

Sicherheit

DB-Parametergruppen

Replikation

Multi-AZ-Bereitstellungen

MySQL

Read Replicas

Versionsmanagement für DB Engines

Oracle

Lizenzierung und Support

Versionsmanagement für DB-Engines

Skalierung

Optionen/Funktionen

Datenverarbeitung

Bereitstellung von Inhalten

Datenbank

Bereitstellung und Verwaltung

E-Commerce

Messaging

Überwachung

Netzwerk

Zahlungen und Rechnungsstellung

Speicherung

Support

Web-Datenverkehr

Arbeitskräfte

Amazon RDS

Unterstützte DB Engines

Funktionen

Entwicklerressourcen

Das Amazon RDS Datenblatt erhalten