Kostenlos bei AWS einsteigen

Kostenloses Konto erstellen
oder bei der Konsole anmelden

Das kostenlose Nutzungskontingent für AWS umfasst für Amazon Relational Database Service (RDS) ein Jahr lang jeden Monat 750 Micro-DB-Instance-Stunden, 20 GB Speicher und 20 GB für Sicherungen.

Details zum kostenlosen Kontingent für AWS anzeigen »

Im Amazon RDS User Guide finden Sie häufig gestellte Fragen zu SQL Server und PostgreSQL.



F: Was ist Amazon RDS?

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-, SQL-Server- oder PostgreSQL-Datenbank. Das bedeutet, dass der Code, die Anwendungen und die Tools, die Sie heute mit Ihren bestehenden Datenbanken nutzen, nahtlos mit 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 der Replikation (derzeit nur für die Datenbank-Engines MySQL und Oracle unterstützt) die Datenbankverfügbarkeit und Datenbeständigkeit verbessern oder über die Kapazitätsgrenzen einer einzelnen Datenbank-Instance hinaus skalieren, wenn Sie Datenbankverarbeitungslasten 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 Datenbank-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. Sie können eine oder mehrere DB-Instances ausführen. Jede DB-Instance kann je nach Engine-Typ ein(e) oder mehrere Datenbanken- bzw. Datenbankschemas unterstützen.

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: Was sind die ersten Schritte mit Amazon RDS?

Um sich für Amazon RDS zu registrieren, klicken Sie auf der Seite zu Amazon RDS auf die Schaltfläche " Kostenloses Konto erstellen" und führen dann 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 Kunden über bis zu 40 Amazon RDS DB-Instances verfügen. Von diesen 40 können bis zu 10 Oracle- oder SQL Server DB-Instances unter dem Modell "License Included" (Lizenz eingeschlossen) sein. Alle 40 können für MySQL, Oracle, SQL Server oder PostgreSQL gemäß dem "BYOL"-Modell (Verwendung der eigenen Lizenz) genutzt werden. Wenn Sie für Ihre Anwendung mehr DB-Instances benötigen, können Sie über dieses Formular weitere DB-Instances beantragen.

F: Wie viele Datenbanken oder Schemas kann ich in einer DB-Instance ausführen?

  • RDS für MySQL: Kein von der Software auferlegter Grenzwert
  • RDS für Oracle: 1 Datenbank pro Instance. Kein von der Software auferlegter Grenzwert für die Anzahl der Schemas pro Datenbank
  • RDS für SQL Server: 30 Datenbanken pro Instance
  • RDS für PostgreSQL: Kein von der Software auferlegter Grenzwert

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, den Import/Export-Assistenten und das Massenkopierprogramm (BCP) für SQL Server oder pg_dump für PostgreSQL. Weitere Informationen zum Im- und Exportieren von Daten finden Sie im Data Import Guide for MySQL, Data Import Guide for Oracle, Data Import Guide for SQL Server oder Data Import Guide for PostgreSQL.

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

Amazon RDS unterstützt die Datenbank-Engines MySQL, Oracle, SQL Server und PostgreSQL.

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

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 Wartungs- bzw. 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.

F: Warum sind die Gebühren für die einzelnen RDS-Datenbank-Engines unterschiedlich?

Die Gebühren für die einzelnen Datenbank-Engines von RDS sind unterschiedlich, da unsere Kosten jeweils unterschiedlich sind. In diese Kosten fließen über die Softwarelizenzierung hinaus viele Betriebskomponenten ein. Wie in der Vergangenheit durch signifikante Preissenkungen demonstriert, arbeiten wir hart an Kostensenkungen und lassen unsere Kunden in den Genuss dieser Einsparungen kommen. Wir sind bestrebt, dies auch künftig bei unseren neueren Datenbank-Engines wie PostgreSQL zu tun.

 

 


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-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen.
  • Bereitgestellte E/A\Sek. – Ihnen werden die E/A\Sek. 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 abrechenbare Amazon RDS-Instance-Stunden 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 zusätzlicher Reservespeicher 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-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen. Bei Multi-AZ-Bereitstellungen werden mehr E/A-Anforderungen 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 bereits in den Preisen enthalten?

Falls nicht anders angegeben, gelten unsere Preise zuzüglich geltender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechungsadresse unterliegt die Nutzung der Region Asien-Pazifik (Tokio) der japanischen Verbrauchssteuer. Weitere Informationen.

 


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 (mit geringer, mittlerer und hoher Auslastung), die Ihnen die Möglichkeit bieten, den Vorauszahlungsbetrag 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 Reserved Instances erwerben und erstellen?

Sie können die Option "Purchase Reserved DB-Instance" 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 40 reservierte DB-Instances erwerben. Wenn Sie mehr als 40 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 Reserved 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 Reserved Instance registriere? Was geschieht mit meiner DB-Instance nach Ablauf des Zeitraums?

Preisänderungen für Reserved Instances werden aktiviert, sobald Ihr Antrag 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 DB-Instances nach dem Tarif für Reserved 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: Was geschieht mit meiner Reservierung, wenn ich meine ich meine Reserved Instance erweitere oder verkleinere?

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 aus 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 Reserved 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 Reserved 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?

Nein. Sie können Ihre Reserved DB-Instance nicht kündigen und die Einmalzahlung wird nicht rückerstattet. Sie können sich jedoch bei Verwenden einer Reserved DB-Instance mit niedriger oder mittlerer Auslastung jederzeit dafür entscheiden, Ihre Instance nicht auszuführen oder die Nutzung vollständig einzustellen. Ab diesem Zeitpunkt fallen keine weiteren nutzungsabhängigen Gebühren an. Wenn Sie eine Reserved DB-Instance mit hoher Auslastung nutzen, zahlen Sie weiter für jede Stunde Ihrer Vertragslaufzeit für die Reserved DB-Instance unabhängig von der tatsächlichen Nutzung.

F: Kann ich meine vorhandenen Reserved Instances gegen die günstigeren Reserved Instances vom 11. Juni 2013 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.


F: Wie bestimme ich, welche DB-Instance-Klasse und 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 Amazon RDS-Datenbank-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 Hardwarekonfiguration ist für Amazon RDS-Standardspeicher 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 größte DB-Instance-Klasse und maximale 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 E/A\Sek. 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 E/A\Sek. statt RDS-Standardspeicher 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.


F: Was ist der Unterschied zwischen automatischen Sicherungen 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 Sicherungen 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 Sicherungsfenster 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 Sicherungsfensters werden E/A-Speichervorgänge während der Durchführung der Datensicherung möglicherweise vorübergehend unterbrochen und es kann zu erhöhter Latenz kommen. Die E/A-Unterbrechung dauert meist für die Dauer der Snapshot-Erstellung an. Mit Multi-AZ DB-Bereitstellungen lassen sich diese Unterbrechungen verkürzen, da die Sicherung von der Standby-Instanz angefertigt wird. Doch im Verlauf des Sicherungsvorgangs kann es zu Latenz kommen.

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 Sicherungen 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.


F: Was ist Amazon Virtual Private Cloud (VPC) und warum sollte ich sie 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 auf der EC2-Classic-Plattform (ohne VPC)?

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). Sie können eine VPC so konfigurieren, dass eine Amazon RDS-DB-Instance in dieser VPC öffentlich zugänglich ist. Weitere Informationen finden Sie in der VPC-Dokumentation. Weitere Informationen zu den Unterschieden zwischen EC2-Classic und EC2-VPC finden Sie in der EC2-Dokumentation.

F: Was ist eine DB-Subnetzgruppe und warum benötige ich eine?

Eine DB-Subnetzgruppe ist eine Sammlung von Subnetzen, die Sie für Ihre RDS-DB-Instances in einer VPC verwenden könnten. Jede DB-Subnetzgruppe 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-Subnetzgruppe auswählen. Amazon RDS verwendet diese DB-Subnetzgruppe 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-Sicherheitsgruppe 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-Instances?

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

F: Wie schütze 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 ausgedehnt 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-Subnetzgruppe meiner DB-Instance ändern?

Eine vorhandene DB-Subnetzgruppe 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 Entfernen von Subnetzen aus einer vorhandenen DB-Subnetzgruppe kann eine Nichtverfügbarkeit für Instances bewirken, wenn diese in einer bestimmten Availability Zone ausgeführt werden, die aus der Subnetzgruppe entfernt wird.

Derzeit wird bei Aktualisierung einer vorhandenen DB-Subnetzgruppe nicht das aktuelle Subnetz der bereitgestellten DB-Instance geändert. Eine Skalierung des Instance-Typs ist erforderlich. Das explizite Ändern der DB-Subnetzgruppe einer bereitgestellten DB-Instance ist derzeit nicht zulässig.

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 erteilt?

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-, SQL Server- und PostgreSQL-Engines unterstützt.

Amazon RDS generiert für jede DB-Instance ein SSL-Zertifikat. Nach dem Herstellen einer verschlüsselten Verbindung werden Daten zwischen der Datenbank-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.

Einzelheiten zum Einrichten einer verschlüsselten Verbindung mit Amazon RDS finden Sie im MySQL User Guide, SQL Server User Guide und PostgreSQL User Guide für Amazon RDS. Weitere Informationen zur Funktionsweise von SSL mit diesen Engines finden Sie in der MySQL-Dokumentation, MSDN SQL Server-Dokumentation und PostgreSQL-Dokumentation.

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

F: Wie kontrolliere ich die Aktionen, die meine Systeme und Benutzer auf bestimmte RDS-Ressourcen anwenden können?

Sie können die Aktionen kontrollieren, die Ihre AWS IAM-Benutzer und -Gruppen auf bestimmte RDS-Ressourcen anwenden können. Dies erfolgt über Verweise auf die RDS-Ressourcen in den AWS IAM-Richtlinien, die Sie Benutzern und Gruppen zuweisen können. RDS-Ressourcen, die auf in einer AWS IAM-Richtlinie verwiesen werden kann, sind DB-Instances, DB-Snapshots, Read Replicas, DB-Sicherheitsgruppen, DB-Optionsgruppen, DB-Parametergruppen, Ereignisabonnements und DB-Subnetzgruppen. Darüber hinaus können Sie diese Ressourcen mit Kategorien versehen, um ihnen weitere Metadaten hinzuzufügen. Sie können Ihre Ressourcen Kategorien zuweisen (z.B. DB-Instances "Entwicklung", DB-Instances "Produktion", DB-Instances "Test" usw.) und AWS IAM-Richtlinien festlegen, in denen die Berechtigungen für die Aktionen aufgeführt sind, die auf Ressourcen der jeweiligen Kategorie angewendet werden dürfen. Weitere Informationen finden Sie unter Managing Access to Your Amazon RDS Resources and Databases und Tagging Amazon RDS Resources

F: Ich möchte für meine RDS-Bereitstellung eine Sicherheitsanalyse oder Behebung von Betriebsproblemen durchführen. Kann ich einen Verlauf aller RDS-API-Aufrufe abrufen, die für mein Konto erfolgt sind?

Ja. AWS CloudTrail ist ein Web-Service, der Aufrufe von AWS-APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Der AWS-API-Aufrufverlauf, der von CloudTrail generiert wird, ermöglicht eine Sicherheitsanalyse, Nachverfolgung von Ressourcenänderungen und Überwachung der Einhaltung von Vorschriften. Weitere Informationen zu CloudTrail finden Sie auf der Detailseite zu AWS CloudTrail. Auf der CloudTrail-Startseite in der AWS Management Console können Sie CloudTrail aktivieren.

 


F: Wie wähle ich die passenden Konfigurationsparameter für meine DB-Instances 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-Parametergruppen? Wofür sind sie nützlich?

Eine Database Parameter Group (DB-Parametergruppe) 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-Parametergruppe zu erstellen, wird eine DB-Parametergruppe 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-Parametergruppe erstellen, die betreffenden Parameter ändern und festlegen, dass die DB-Instance die neue DB-Parametergruppe verwendet. Nach der Zuordnung der einzelnen DB-Instances zu bestimmten DB-Parametergruppe werden alle DB-Instances mit den Parametern der jeweiligen DB-Parametergruppe aktualisiert. Weitere Informationen zur Konfiguration von DB-Parametergruppen finden Sie im DB-Bereitstellungsleitfaden für Parametergruppe.

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

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


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

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 zu Multi-AZ-Bereitstellungen finden Sie in diesem Abschnitt mit häufig gestellten Fragen.

Multi-AZ-Bereitstellungen werden für die Datenbank-Engines MySQL, Oracle, PostgreSQL und SQL Server unterstützt. Multi-AZ-Bereitstellungen für SQL Server sind derzeit in den AWS-Regionen USA West (Oregon) und EU (Dublin) und in Kürze in der AWS-Region USA Ost (Nord-Virginia) verfügbar.

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.


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äre Replika für Schreib- und Lesevorgänge 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. Bei einem Ausfall einer Availability Zone oder DB-Instance wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, der für das automatische Failover benötigt wird. 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 in Ihrem Auftrag 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 Leseanforderungen 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-Bereitstellung einer DB-Instance 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 veranlassen Amazon RDS zu einem Failover auf die Standby-Replika?

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 Vorgang 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 auf Anwendungsebene die Wiederherstellung der Datenbankverbindung zu implementieren.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der primären Instance und Fortsetzung von Transaktionen auf der Standby-Instance in der Regel binnen 1-2 Minuten. Die Dauer des Failovers kann auch davon abhängen, ob umfassende Transaktionen ohne Datenbank-Commit wiederhergestellt werden müssen. Für optimale Ergebnisse wird der Einsatz ausreichend großer Instance-Typen für Multi-AZ-Bereitstellungen empfohlen. AWS empfiehlt auch die Nutzung von bereitgestellten E/A-Sek.-Vorgängen mit Multi-AZ-Instances zum Sicherstellen einer schnellen, berechenbaren und einheitlichen Durchsatzleistung.

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 Parameter "Multi-AZ" auf "true". Die Erstellung der synchronen Standby-Replikation und das Failover 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 auch nicht für das Akzeptieren von Datenbankleseaktivität konfiguriert werden. Weitere Informationen zu Multi-AZ-Konfigurationen.

F: Befindet sich meine Standby-Replika in derselben Region wie die primäre Replika?

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 mein Primärknoten 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äre Replika nun in einer anderen Availability Zone als meine anderen AWS-Ressourcen (z. B. EC2-Instances). 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 Sicherungen 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.


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-Anforderungen 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, Anforderungen 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 vorhandene 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 Erstellungsanforderung 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 vorhandene Quell-DB-Instance erstellen?

Derzeit bietet Amazon RDS Ihnen die Möglichkeit, bis zu fünf (5) Read Replicas für eine 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 Replicas eine Multi-AZ-Bereitstellung einer DB-Instance als Quelle nutzen?

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

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 soll ich tun?

Gelegentlich kann es vorkommen, dass Ihre Read Replicas nach einem Multi-AZ-Failover keine Updates aus ihrer Multi-AZ-Quell-DB-Instance empfangen bzw. einspielen 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?

Sie können anhand einer vorhandenen primären Read Replica eine sekundäre Read Replica erstellen. Durch Erstellen einer sekundären Read Replica können Sie ggf. einen Teil der Replikationslast von einer Master-Datenbank-Instance zu einer primären Read Replica verlagern. Beachten Sie, dass eine sekundäre Read Replica ggf. länger hinter der Master-DB-Instance zurückbleibt, da es zu weiterer Replikationslatenz kommt, wenn Transaktionen von der Master-DB-Instance in die primäre Read Replica und anschließend in die sekundäre Read Replica repliziert werden.

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-Parametergruppen 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 Replicas?

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.

Amazon RDS überwacht den Replizierungsstatus Ihrer Read Replicas und aktualisiert das Feld Replication State mit der Meldung Error, wenn die Replizierung aus einem beliebigen Grund unterbrochen wird. (Beispielweise kann die Ausführung von DML-Anfragen auf Ihre Replik, die mit den an der Master-Datenbank-Instance vorgenommenen Updates in Konflikt stehen, zu einem Replizierungsfehler führen.) Die Details zu dem von der MySQL-Datenbank-Engine ausgeworfenen Fehler können Sie im Feld Replication Error sehen und somit anschließend entsprechende Abhilfemaßnahmen ergreifen. Weitere Informationen zur Fehlerbehebung bei Replizierungsproblemen finden Sie im Abschnitt Fehlerbehebung bei Read Replica-Problemen des Amazon RDS-Benutzerhandbuchs. Wird ein Replizierungsfehler behoben, ändert sich das Feld Replication State zu Replicating.

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. Muss ich auch die Ressourcen für die dazugehörigen Read Replicas 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 Replikation zwischen meiner Quell-DB-Instance und einer Read Replica als zeilenbasierte Replikation konfigurieren?

Standardmäßig ist die Replikation auf ein Mischformat (das sowohl die zeilen- als auch anweisungsbasierte Replikation umfasst) festgelegt, mit dem die Anforderungen der meisten Anwendungsfälle erfüllt werden sollten. Amazon RDS unterstützt derzeit nicht einen expliziten Wechsel zur zeilenbasierten Replikation. Die MySQL-Dokumentation bietet weitere Informationen zum Unterschied zwischen der Mischformat- und zeilenbasierten Replikation.

F: Kann ich DB-Snapshots oder automatisierte Sicherungen 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ärprotokolle für meine Datenbank-Instance direkt aufrufen, um meine eigene Replikation zu verwalten?

Amazon RDS bietet derzeit keinen Zugriff auf die Binärprotokolle für Ihre Datenbank-Instance.

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

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 Replikation 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.

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 Haupt- und Nebenversionen?

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 MySQL-Hauptversionen 5.1, 5.5 und 5.6. Künftig kommen weitere MySQL-Hauptversionen 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 kann ich einen Upgrade von einer Hauptversion von MySQL auf eine andere Version durchführen?

Lesen Sie den Abschnitt Upgrading a DB-Instance im Benutzerhandbuch zu Amazon RDS, um mehr zu erfahren.


F: Welche Lizenzierungsoptionen stehen für Amazon RDS für 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-Datenbankversionen 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 Lizenzierungsrichtlinien 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 Support für Amazon RDS für Oracle geboten?

  • 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 "Verwendung der eigenen Lizenz" zu "Lizenz enthalten")?

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.

F: Was sind Amazon RDS-DB-Engine-Versionen für Oracle und in welcher Beziehung stehen Sie zu 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 Patch-Set-Zusammensetzung meiner DB-Engine-Version für Oracle?

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

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 neue DB Engine-Versionen aktualisiert, wenn kleinere Upgrades durch Amazon RDS geplant sind. 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.

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, 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?

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: Stellt Amazon RDS Richtlinien zur Unterstützung der neuen DB Engine-Versionen für Oracle und/oder der veralteten DB Engine-Versionen für Oracle zur Verfügung, 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.

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-Version einer von mir ausgeführten DB-Instance ändern (z. B. von Oracle 11g R2 SE1 in 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.

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

Amazon RDS für Oracle unterstützt Multi-AZ-Bereitstellungen für die Lizenzierungsmodelle "License Included" (Lizenz enthalten) 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 zusätzliche Lizenzen, 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 für Amazon RDS unterstützt?

Nein, RAC wird derzeit nicht unterstützt.

F: Welche Enterprise Edition-Optionen werden für 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.

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.