Définition des autorisations pour planifier une requête Authentification d’une requête planifiée Configuration d'autorisations pour consulter l'historique des requêtes planifiées Surveillance de la requête planifiée Résolution des problèmes liés à la planification d'une requête Trouver des informations sur les requêtes planifiées avec AWS CloudShell Vidéo de démonstration

Planification d'une requête avec l'éditeur de requête v2

Vous pouvez créer une planification en vue d'exécuter une instruction SQL avec l'éditeur de requête Amazon Redshift v2. La création d'une planification vise à exécuter l'instruction SQL aux périodes qui correspondent aux besoins de votre activité. Au moment de l'exécution de la requête planifiée, celle-ci est lancée par Amazon EventBridge et utilise l'API Amazon Redshift Data.

Pour créer une planification afin d’exécuter une instruction SQL

Dans la vue Éditeur , choisissez Planification pour créer une planification en vue d'exécuter une instruction SQL.
Lorsque vous définissez la planification, vous fournissez les informations suivantes.
- Le rôle IAM qui prend les autorisations nécessaires pour exécuter la requête. Ce rôle IAM est également attaché à votre cluster ou groupe de travail.
- Les valeurs d'authentification pour l'une AWS Secrets Manager ou l'autre des informations d'identification temporaires permettant d'autoriser l'accès à votre cluster ou groupe de travail. Ces méthodes d'authentification sont prises en charge par l'API de données. Pour plus d’informations, consultez Authentification d'une requête planifiée.
- Le cluster ou le groupe de travail dans lequel réside votre base de données.
- Le nom de la table de base de données qui contient les données à interroger.
- Nom de la requête planifiée et sa description. L'éditeur de requête v2 ajoute le préfixe « QS2- » au nom de la requête planifiée que vous indiquez. L'éditeur de requête v1 ajoute le préfixe « QS- » aux noms de ses requêtes planifiées.
- L'instruction SQL à exécuter selon la planification.
- Les options de fréquence et de répétition de la planification ou une valeur au format cron qui définit la planification. Pour plus d'informations, consultez la section Cron Expressions dans le guide de l'utilisateur Amazon CloudWatch Events.
- Si nécessaire, vous pouvez activer des notifications Amazon SNS standard pour surveiller la requête planifiée. Vous serez peut-être amené à confirmer l'adresse e-mail que vous avez fournie à la notification Amazon SNS. Vérifiez dans votre e-mail s'il existe un lien destiné à confirmer l'adresse e-mail pour la notification Amazon SNS. Pour en savoir plus, consultez Notifications par e-mail dans le Guide du développeur Amazon Simple Notification Service. Si votre requête est en cours d'exécution mais que vous ne voyez aucun message publié dans votre rubrique SNS, consultez Ma règle s'exécute, mais je ne vois aucun message publié dans ma rubrique Amazon SNS dans le guide de l'utilisateur EventBridge Amazon.
Choisissez Planifier une requête pour enregistrer et activer la planification et ajouter celle-ci à la liste des requêtes dans la vue Requêtes planifiées.

La vue Requêtes planifiées liste toutes les requêtes planifiées pour vos clusters et groupes de travail. Cette vue vous permet d'afficher les détails de la requête planifiée, d'activer ou de désactiver la planification, de modifier la planification et de supprimer la requête planifiée. Lorsque vous examinez les détails d'une requête, vous pouvez aussi consulter l'historique de ses exécutions dans le cadre de la planification.

Note

Une exécution de requête planifiée ne reste disponible dans la liste Historique de planification que 24 heures. Les requêtes qui s'exécutent selon une planification ne figurent pas dans la vue Historique des requêtes de l'éditeur de requête v2

Configuration des autorisations pour planifier une requête

Pour planifier des requêtes, l'utilisateur AWS Identity and Access Management (IAM) qui définit le calendrier et le rôle IAM associé au calendrier doit être configuré avec les autorisations IAM pour utiliser Amazon et l'API Amazon EventBridge Redshift Data. Pour recevoir des e-mails des requêtes planifiées, la notification Amazon SNS que vous spécifiez éventuellement doit également être configurée.

Ce qui suit décrit les tâches liées à l'utilisation de politiques AWS gérées pour fournir des autorisations, mais en fonction de votre environnement, vous souhaiterez peut-être limiter les autorisations autorisées.

Pour modifier l'utilisateur IAM connecté à l'éditeur de requête v2, utilisez la console IAM (https://console.aws.amazon.com/iam/).

Outre les autorisations nécessaires pour exécuter les opérations Amazon Redshift et Query Editor v2, associez AmazonEventBridgeFullAccess les politiques AmazonRedshiftDataFullAccess AWS gérées à un utilisateur IAM.
Vous pouvez également attribuer les autorisations à un rôle et attribuer le rôle à l'utilisateur.

Attachez une politique qui accorde l'autorisation sts:AssumeRole à l'ARN de ressource du rôle IAM que vous spécifiez lors de la définition de la requête planifiée. Pour en savoir plus sur l'endossement de rôles, consultez Octroi d'autorisations à un utilisateur pour endosser un rôle dans le Guide de l'utilisateur IAM.

L'exemple suivant illustre une politique d'autorisation qui endosse le rôle IAM myRedshiftRole dans le compte 123456789012. Le rôle IAM myRedshiftRole est également le rôle IAM qui est attaché au cluster ou au groupe de travail où s'exécute la requête planifiée.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AssumeIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::123456789012:role/myRedshiftRole"
            ]
        }
    ]
}
```
Mettez à jour la politique d'approbation du rôle IAM utilisé pour planifier la requête afin de permettre à l'utilisateur IAM de l'endosser.
```
{
            "Sid": "AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/myIAMusername"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
```

Pour modifier le rôle IAM que vous spécifiez pour autoriser la requête planifiée à s'exécuter, utilisez la console IAM (https://console.aws.amazon.com/iam/).

Associez AmazonRedshiftDataFullAccess les politiques AmazonEventBridgeFullAccess AWS gérées au rôle IAM. La politique gérée AmazonRedshiftDataFullAccess accepte uniquement l'autorisation redshift-serverless:GetCredentials pour les groupes de travail Redshift sans serveur balisés avec la clé RedshiftDataFullAccess.

Authentification d'une requête planifiée

Lorsque vous planifiez une requête, vous utilisez l'une des méthodes d'authentification suivantes lors de l'exécution SQL. Les entrées à effectuer dans l'éditeur de requête v2 varient en fonction de la méthode utilisée. Ces méthodes d'authentification sont prises en charge par l'API de données utilisée pour exécuter vos instructions SQL.

L'utilisateur ou le rôle de base de données utilisé pour exécuter la requête doit disposer des privilèges de base de données nécessaires. Par exemple, pour accorder des privilèges IAMR:MyRedshiftQEv2Scheduler à la table mytable, exécutez la commande SQL suivante.


GRANT all ON TABLE mytable TO "IAMR:MyRedshiftQEv2Scheduler";

Pour afficher la liste des utilisateurs de base de données de votre cluster ou groupe de travail, interrogez la vue système PG_USER_INFO.

Note

Tout groupe de travail Redshift Serverless pour lequel vous planifiez des requêtes doit être marqué avec la clé. RedshiftDataFullAccess Pour plus d’informations, consultez Autorisation de l’accès à l’API de données Amazon Redshift.

Au lieu de baliser le groupe de travail, vous pouvez également ajouter une politique en ligne au rôle IAM (spécifié avec la planification) qui autorise redshift-serverless:GetCredentials. Par exemple :


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "UseTemporaryCredentialsForAllServerlessWorkgroups",
            "Effect": "Allow",
            "Action": "redshift-serverless:GetCredentials",
            "Resource": [
                "arn:aws:redshift-serverless:*:*:workgroup/*"
            ]
        }
    ]
}

AWS Secrets Manager

Avec cette méthode, fournissez une valeur secrète pour le paramètre secret-arn qui est stocké dans AWS Secrets Manager. Ce secret contient des informations d’identification pour vous connecter à votre base de données. Vous avez peut-être créé un secret avec les informations d'identification appropriées lorsque vous avez créé votre cluster ou votre groupe de travail. Le secret doit être étiqueté avec la clé RedshiftDataFullAccess. Si la clé de balise n'est pas déjà présente, utilisez la AWS Secrets Manager console pour l'ajouter. Pour plus d'informations sur la création d'un secret, consultezCréation d'un secret pour les informations de connexion à la base de données.

Pour plus d’informations sur les autorisations minimales, consultez Création et gestion des secrets avec AWS Secrets Manager dans le Guide de l’utilisateur AWS Secrets Manager .

Informations d’identification temporaires

Avec cette méthode, indiquez le Nom de la base de données et l'Utilisateur de la base de données pour vous connecter à une base de données située dans un cluster. Vous devez simplement indiquer le Nom de la base de données au moment de vous connecter à une base de données d'un groupe de travail.

Lorsque vous vous connectez à un cluster, la politique AmazonRedshiftDataFullAccess accorde à l'utilisateur de base de données nommé redshift_data_api_user une autorisation pour redshift:GetClusterCredentials. Si vous souhaitez utiliser un autre utilisateur de base de données pour exécuter l'instruction SQL, ajoutez une politique au rôle IAM attaché à votre cluster pour autoriser redshift:GetClusterCredentials. L’exemple de stratégie suivant autorise les utilisateurs de base de données awsuser et myuser.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "UseTemporaryCredentialsForAllDbUsers",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentials",
            "Resource": [
                "arn:aws:redshift:*:*:dbuser:*/awsuser",
                "arn:aws:redshift:*:*:dbuser:*/myuser"
            ]
        }
    ]
}

Configuration d'autorisations pour consulter l'historique des requêtes planifiées

Pour permettre aux utilisateurs de consulter l'historique des requêtes planifiées, modifiez le rôle IAM (spécifié avec la planification) Relations d'approbation pour ajouter les autorisations.

L'exemple de politique d'approbation suivant s'applique à un rôle IAM qui autorise l'utilisateur IAM myIAMusername à consulter l'historique des requêtes planifiées. Au lieu d'accorder à un utilisateur IAM l'autorisation sts:AssumeRole, vous pouvez choisir d'accorder à un rôle IAM cette autorisation.



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "redshift.amazonaws.com",
                    "redshift-serverless.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Sid": "AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/myIAMusername"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Surveillance de la requête planifiée

Pour la rubrique Amazon SNS que vous spécifiez pour l'envoi de notifications par e-mail, créez la rubrique Amazon SNS à l'aide de l'éditeur de requête v2 en accédant à la section Notifications SNS, choisissez Activer pour la surveillance, puis créez la rubrique avec Créer une rubrique SNS. L'éditeur de requêtes v2 crée la rubrique Amazon SNS et ajoute un principal de service à la politique d'accès d'Amazon. EventBridge Voici un exemple de Statégie d'accès qui est créé dans la rubrique Amazon SNS. Dans l'exemple, les rubriques Région AWS us-west-2, Compte AWS 123456789012 et Amazon SNS sont utilisées. select-version-pdx-testunload


{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "Allow_Publish_Events",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-west-2:123456789012:select-version-pdx-testunload"
    }
  ]
}

Lorsque la requête planifiée est exécutée, Amazon SNS envoie des e-mails de AWS notification. L'exemple suivant montre un e-mail envoyé à myemail@example.com pour la requête planifiée QS2-May25a qui s'est exécutée sur Région AWS eu-north-1 au Compte AWS 123456789012 à l'aide de la rubrique de notification Amazon SNS May25a-SNS.


{"version":"0","id":"8e4323ec-5258-7138-181b-91290e30ff9b","detail-type":"Scheduled Event","source":"aws.events","account":"123456789012","time":"2023-05-25T15:22:00Z",
                    "region":"eu-north-1","resources":["arn:aws:events:eu-north-1:123456789012:rule/QS2-may25a"],"detail":{}}

--
If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe:
https://sns.eu-north-1.amazonaws.com/unsubscribe.html?SubscriptionArn=arn:aws:sns:eu-north-1:123456789012:may25a-SNS:0c1a3d05-39c2-4507-bc3d-47250513d7b0&Endpoint=myemail@example.com

Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support

Résolution des problèmes liés à la configuration de la planification d'une requête

Si vous rencontrez des problèmes pour planifier une requête, tenez compte des points suivants.

Les requêtes ne s'exécutent pas

Vérifiez que le rôle IAM utilisé dans la planification est autorisé à obtenir les informations d'identification temporaires du cluster. L'autorisation pour les clusters provisionnés est redshift:GetClusterCredentialsWithIAM. L'autorisation pour les groupes de travail Redshift sans serveur est redshift-serverless:GetCredentials.

L'historique planifié ne s'affiche pas

L'utilisateur IAM ou le rôle IAM utilisé pour se connecter à la AWS console n'a pas été ajouté à la politique de confiance du rôle IAM utilisé pour planifier la requête.

Lors de l'utilisation AWS Secrets Manager de la requête planifiée pour se connecter, vérifiez que le secret est marqué avec la cléRedshiftDataFullAccess.

Si la requête planifiée utilise une AWS Secrets Manager connexion, le rôle IAM utilisé pour planifier la requête doit avoir l'équivalent d'une politique gérée SecretsManagerReadWrite attachée au rôle.

L'état de l'historique des requêtes est Failed

Consultez la vue système SYS_QUERY_HISTORY pour obtenir des détails sur les raisons de l'échec de la requête. Il est possible que l'utilisateur ou le rôle de base de données ayant servi à exécuter la requête ne disposait pas des privilèges nécessaires pour exécuter la requête SQL. Pour plus d’informations, consultez Authentification d'une requête planifiée.

Les requêtes SQL suivantes interrogent la vue SYS_QUERY_HISTORY pour renvoyer les requêtes ayant échoué.


SELECT user_id, query_id, transaction_id, session_id, database_name, query_type, status, error_message, query_text 
FROM sys_query_history
WHERE status = 'failed';

Pour rechercher des informations à propos de l'échec d'une requête planifiée spécifique, consultez Trouver des informations sur les requêtes planifiées avec AWS CloudShell.

Trouver des informations sur les requêtes planifiées avec AWS CloudShell

Vous pouvez l'utiliser AWS CloudShell pour obtenir des informations sur une requête de planification. Vous devez disposer des autorisations appropriées pour exécuter les AWS CLI commandes indiquées dans la procédure suivante.

Pour afficher les résultats d'une requête planifiée

Sur la AWS console, ouvrez l'invite de AWS CloudShell commande. Pour plus d'informations AWS CloudShell, voir Contenu du guide AWS CloudShell de l'AWS CloudShell utilisateur.

Endossez le rôle IAM de la requête planifiée. Pour assumer ce rôle, recherchez le rôle IAM associé à la requête planifiée dans l'éditeur de requêtes v2 et utilisez-le dans la AWS CLI commande dans AWS CloudShell. Par exemple, pour le rôle, scheduler entrez une AWS STS commande pour assumer le rôle utilisé par la requête planifiée.


aws sts assume-role —role-arn "arn:aws:iam::123456789012:role/scheduler" —role-session-name "scheduler-test"

Les informations d'identification renvoyées se présentent comme suit.


"Credentials": {
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...",        
"Expiration": "2023-08-18T18:19:44+00:00"
},
"AssumedRoleUser": {
"AssumedRoleId": "AROA35B2NH6WBTP7ONL4E:scheduler-test",
"Arn": "arn:aws:sts::123456789012:assumed-role/scheduler/scheduler-test"
}
}

Créez des variables environnementales en AWS CLI utilisant les informations d'identification affichées lorsque vous assumez le rôle IAM. Vous devez utiliser ces jetons avant qu'ils n'arrivent à expiration. Par exemple, vous entrez ce qui suit dans AWS CloudShell.
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...
```

Pour voir l'erreur d'une requête ayant échoué, exécutez la AWS CLI commande pour décrire une instruction. L'ID de l'instruction SQL est tiré du champ ID figurant dans l'Historique de planification d'une requête planifiée dans l'éditeur de requête v2.


aws redshift-data describe-statement —id 130d2620-05d2-439c-b7cf-815d9767f513

Dans cet exemple, la requête SQL planifiée select * from users limit 100 génère une erreur SQL indiquant que la table users n'existe pas.


{
"CreatedAt": "2023-08-18T17:39:15.563000+00:00",
"Duration": -1,
"Error": "ERROR: relation \"users\" does not exist",
"HasResultSet": false,
"Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"QueryString": "select * from users limit 100\n—RequestID=a1b2c3d4-5678-90ab-cdef-EXAMPLE22222; TraceID=1-633c5642-4039308d03f3a0ba53dbdf6f",
"RedshiftPid": 1073766651,
"RedshiftQueryId": 0,
"ResultRows": -1,
"ResultSize": -1,
"Status": "FAILED",
"UpdatedAt": "2023-08-18T17:39:16.116000+00:00",
"WorkgroupName": "default"
}

Démonstration de la planification d'une requête

Pour une démonstration de la planification d'une requête, regardez la vidéo suivante.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Utilisation des unités de partage des données

Visualisation des résultats