Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Vergleich des Verhaltens der Amazon RDS Data API für Aurora Serverless v2 und bereitgestellte Cluster mit Aurora Serverless v1 Clustern

Die neuesten Verbesserungen der Amazon RDS-Daten APIs machen Daten für Cluster APIs verfügbar, die aktuelle Versionen von PostgreSQL- oder MySQL-Engines verwenden. Diese Cluster können so konfiguriert werden, dass sie Instance-Klassen wie Aurora Serverless v2 oder verwenden oder bereitstellen. db.r6g db.r6i

In den folgenden Abschnitten werden die Unterschiede der Amazon RDS-Daten-API zwischen Aurora Serverless v2 bereitgestellten DB-Clustern und Aurora Serverless v1 DB-Clustern beschrieben. Aurora Serverless v1 DB-Cluster verwenden den serverless Engine-Modus. Bereitgestellte DB-Cluster verwenden den provisioned Engine-Modus. Ein Aurora Serverless v2 DB-Cluster verwendet auch den provisioned Engine-Modus und enthält eine oder mehrere Aurora Serverless v2 DB-Instances mit der db.serverless Instance-Klasse.

Maximale Anzahl von Anfragen pro Sekunde

Aurora Serverless v1

Daten APIs können bis zu 1.000 Anfragen pro Sekunde stellen.

Aurora Serverless v2

Daten APIs können eine unbegrenzte Anzahl von Anfragen pro Sekunde stellen.

Aktivierung oder Deaktivierung der Amazon RDS-Daten-API in einer vorhandenen Datenbank

CloudTrail Ereignisse

Aurora Serverless v1

Ereignisse aus Daten-API-Aufrufen sind Verwaltungsereignisse. Diese Ereignisse werden standardmäßig automatisch in einem Trail enthalten. Weitere Informationen finden Sie unter Daten-API-Ereignisse von einem AWS CloudTrail Trail ausschließen (Aurora Serverless v1nur).

Aurora Serverless v2

Ereignisse aus Daten-API-Aufrufen sind Datenereignisse. Diese Ereignisse werden standardmäßig automatisch in einem Trail ausgeschlossen. Weitere Informationen finden Sie unter Einbeziehen von Daten-API-Ereignissen in einen Trail AWS CloudTrail.

Unterstützung mehrerer Anweisungen

Aurora Serverless v2

Multistatements werden nicht unterstützt. Der Versuch, mehrere Anweisungen in einem einzigen API-Aufruf auszuführen, wird zurückgegeben“An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.”. Um mehrere Anweisungen auszuführen, führen Sie separate ExecuteStatement API-Aufrufe durch oder verwenden Sie die BatchExecuteStatement für die Stapelverarbeitung.

Das folgende Beispiel zeigt die resultierende Fehlermeldung eines API-Aufrufs, bei dem versucht wird, eine Mehrfachanweisung auszuführen.

 aws rds-data execute-statement \    
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
    --database "your_database" \
    --sql "SELECT * FROM your_table; Select * FROM next_table;
                                
                                "An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.

Im folgenden Beispiel werden mehrere Anweisungen mit separaten ExecuteStatement API-Aufrufen ausgeführt.

aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM your_table;"

aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM next_table;"

Gleichzeitige Anfragen für dieselbe Transaktions-ID

Aurora Serverless v1

Nachfolgende Anfragen warten, bis die aktuelle Anfrage abgeschlossen ist. Ihre Anwendung muss Timeout-Fehler verarbeiten, wenn die Wartezeit zu lang ist.

Aurora Serverless v2

Wenn die Daten-API mehrere Anfragen mit derselben Transaktions-ID empfängt, gibt sie sofort diesen Fehler zurück:

DatabaseErrorException: Transaction is still running a query

Dieser Fehler tritt in zwei Situationen auf:

Das folgende Beispiel zeigt alle Anfragen, die parallel zu ausgeführt promise.all() werden.

const api_calls = [];
for (let i = 0; i < 10; i++) {
api_calls.push(
    client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    )
);
}
await Promise.all(api_calls);

Um diesen Fehler zu beheben, warten Sie, bis die aktuelle Anfrage abgeschlossen ist, bevor Sie eine weitere Anfrage mit derselben Transaktions-ID senden, oder entfernen Sie die Transaktions-ID, um parallel Anfragen zu ermöglichen.

Das folgende Beispiel zeigt einen API-Aufruf, der die sequentielle Ausführung mit derselben Transaktions-ID verwendet.

 for (let i = 0; i < 10; i++) {
    await client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    ).promise()
);
}

BatchExecuteStatement Verhalten

Mehr über BatchExecuteStatement erfahren Sie unter BatchExecuteStatement.

Aurora Serverless v1

Das generierte Feldobjekt im Aktualisierungsergebnis enthält eingefügte Werte.

Verhalten beim Ausführen von SQL

Weitere Hinweise finden Sie unter ExecuteSQLExecuteSQL.

Aurora Serverless v1

Der ExecuteSQL Vorgang ist veraltet.

Aurora Serverless v2

Der ExecuteSQL Vorgang wird nicht unterstützt.

ExecuteStatement Verhalten

Mehr über ExecuteStatement erfahren Sie unter ExecuteStatement.

Aurora Serverless v1

Der ExecuteStatement Parameter unterstützt das Abrufen von multidimensionalen Array-Spalten und allen erweiterten Datentypen.

Aurora Serverless v2

Der ExecuteStatement Parameter unterstützt keine multidimensionalen Array-Spalten. Es unterstützt auch nicht bestimmte PostgreSQL-Datentypen, einschließlich geometrischer und monetärer Typen. Wenn eine Daten-API auf einen nicht unterstützten Datentyp stößt, gibt sie diesen Fehler zurück—. UnsupportedResultException: The result contains the unsupported data type data_type

Um dieses Problem zu umgehen, wandeln Sie den nicht unterstützten Datentyp in um. TEXT Im folgenden Beispiel wird ein nicht unterstützter Datentyp in umgewandelt. TEXT

SELECT custom_type::TEXT FROM my_table;-- 
ORSELECT CAST(custom_type AS TEXT) FROM my_table;

Eine Liste der unterstützten Datentypen für jede Aurora-Datenbank-Engine finden Sie unter Data API Operations Reference.

Verhalten der Schemaparameter

Aurora Serverless v1

Der Schema Parameter wird nicht unterstützt. Wenn Sie den Schema Parameter in einen API-Aufruf aufnehmen, ignoriert die Daten-API den Parameter.

Aurora Serverless v2

Der Parameter Schema ist veraltet. Wenn Sie den Schema Parameter in einen API-Aufruf aufnehmen, gibt die Daten-API diesen Fehler zurück—ValidationException: The schema parameter isn't supported. Das folgende Beispiel zeigt einen Daten-API-Aufruf, der den ValidationException Fehler zurückgibt.

aws rds-data execute-statement \
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
--database "your_database" \
--schema "your_schema" \
--sql "SELECT * FROM your_table LIMIT 10"
                

Um dieses Problem zu lösen, entfernen Sie den Schema Parameter aus Ihrem API-Aufruf.

Das folgende Beispiel zeigt einen Daten-API-Aufruf, bei dem der Schema Parameter entfernt wurde.

aws rds-data execute-statement \   
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
--database "your_database" \    
--sql "SELECT * FROM your_table LIMIT 10"