Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comparaison des comportements de l’API de données Amazon RDS entre Aurora Serverless v2 et les clusters provisionnés avec les clusters Aurora Serverless v1

Les dernières améliorations apportées aux API de données Amazon RDS les rendent compatibles avec les clusters fonctionnant sur les versions récentes des moteurs PostgreSQL ou MySQL. Ces clusters peuvent être configurés pour utiliser Aurora Serverless v2 ou provisionner des classes d’instance telles que db.r6g ou db.r6i.

Les sections suivantes décrivent les différences de l’API de données Amazon RDS entre Aurora Serverless v2 et les clusters de bases de données provisionnés, ainsi que les clusters de bases de données Aurora Serverless v1. Les clusters de bases de données Aurora Serverless v1 utilisent le mode moteur serverless. Les clusters de bases de données provisionnés utilisent le mode moteur provisioned. Un cluster de bases de données Aurora Serverless v2 utilise le mode moteur provisioned et contient une ou plusieurs instances de base de données Aurora Serverless v2 avec la classe d’instance db.serverless.

Nombre maximal de demandes par seconde

Aurora Serverless v1

Les API de données peuvent traiter jusqu’à 1 000 demandes par seconde.

Aurora Serverless v2

Les API de données peuvent traiter un nombre illimité de demandes par seconde.

Activation ou désactivation de l’API de données Amazon RDS sur une base de données existante

Événements CloudTrail

Aurora Serverless v1

Les événements provenant des appels de l’API de données sont des événements de gestion. Par défaut, ces événements sont consignés automatiquement dans un journal d’activité. Pour plus d’informations, consultez Exclusion d’événements d’API de données d’un journal d’activité AWS CloudTrail (Aurora Serverless v1 uniquement).

Aurora Serverless v2

Les événements provenant des appels de l’API de données sont des événements de données. Par défaut, ces événements sont automatiquement exclus du journal d’activité. Pour plus d’informations, consultez Inclusion d’événements d’API de données dans un journal d’activité AWS CloudTrail.

Prise en charge d’instructions multiples

Aurora Serverless v2

Les instructions multiples ne sont pas prises en charge. Toute tentative d’exécution d’instructions multiples dans un seul appel d’API renvoie “An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.”. Pour exécuter des instructions multiples, effectuez des appels d’API ExecuteStatement distincts ou utilisez BatchExecuteStatement pour le traitement par lots.

L’exemple suivant illustre le message d’erreur renvoyé par un appel d’API qui tente d’exécuter une instruction multiple.

 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.

L’exemple suivant exécute des instructions multiples avec des appels d’API ExecuteStatement distincts.

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;"

Demandes simultanées pour le même ID de transaction

Aurora Serverless v1

Les demandes suivantes sont mises en attente jusqu’à ce que la demande en cours soit achevée. Votre application doit traiter les erreurs de délai d’expiration en cas d’attente prolongée.

Aurora Serverless v2

Lorsque l’API de données reçoit plusieurs demandes avec le même ID de transaction, elle renvoie immédiatement cette erreur :

DatabaseErrorException: Transaction is still running a query

Cette erreur se produit dans deux situations :

L’exemple suivant illustre toutes les demandes exécutées en parallèle avec promise.all().

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);

Pour résoudre cette erreur, attendez que la demande en cours se termine avant d’envoyer une autre demande avec le même ID de transaction, ou supprimez l’ID de transaction afin d’autoriser les demandes parallèles.

L’exemple suivant illustre un appel d’API qui utilise une exécution séquentielle avec le même ID de transaction.

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

Comportement de l’instruction BatchExecuteStatement

Pour plus d’informations sur l’instruction BatchExecuteStatement, consultez BatchExecuteStatement.

Aurora Serverless v1

L’objet des champs générés dans le résultat de la mise à jour inclut les valeurs insérées.

Comportement de l’instruction ExecuteSQL

Pour plus d’informations sur l’instruction ExecuteSQL, consultez ExecuteSQL.

Aurora Serverless v1

L’opération ExecuteSQL est obsolète.

Aurora Serverless v2

L’opération ExecuteSQL n’est pas prise en charge.

Comportement de l’instruction ExecuteStatement

Pour plus d’informations sur l’instruction ExecuteStatement, consultez ExecuteStatement.

Aurora Serverless v1

Le paramètre ExecuteStatement prend en charge la récupération de colonnes de tableaux multidimensionnels ainsi que de tous les types de données avancés.

Aurora Serverless v2

Le paramètre ExecuteStatement ne prend pas en charge les colonnes de tableaux multidimensionnels. Certains types de données PostgreSQL ne sont également pas pris en charge, en particulier les types géométriques et les types monétaires. Lorsqu’une API de données rencontre un type de données non pris en charge, elle renvoie cette erreur : UnsupportedResultException: The result contains the unsupported data type data_type.

Pour contourner ce problème, convertissez le type de données non pris en charge en TEXT. L’exemple suivant convertit un type de données non pris en charge en TEXT.

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

Pour obtenir la liste des types de données pris en charge pour chaque moteur de base de données Aurora, consultez Référence des opérations de l’API de données.

Comportement des paramètres de schéma

Aurora Serverless v1

Le paramètre Schema n’est pas pris en charge. Si le paramètre Schema est inclus dans un appel d’API, il est ignoré par l’API de données.

Aurora Serverless v2

Le paramètre Schema est obsolète. Si le paramètre Schema est inclus dans un appel d’API, l’API de données renvoie l’erreur suivante : ValidationException: The schema parameter isn't supported. L’exemple suivant illustre un appel de l’API de données qui renvoie l’erreur ValidationException.

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"
                

Pour résoudre ce problème, supprimez le paramètre Schema de votre appel d’API.

L’exemple suivant illustre un appel de l’API de données où le paramètre Schema a été supprimé.

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"