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.
Utilisation de tables étrangères avec la base de données globale Aurora
Aurora Global Database prend en charge l'exécution de requêtes analytiques avec une configuration par région. Cette section explique comment configurer les requêtes analytiques entre les régions, quelles ressources se répliquent automatiquement et comment planifier des scénarios de reprise après sinistre.
Rubriques
Utilisation d'aurora_analytics avec une base de données globale
Une table étrangère est une définition de table PostgreSQL qui pointe vers vos données Apache Iceberg ou Parquet dans Amazon S3, Amazon S3 Tables ou le. AWS Glue Data Catalog Aucune donnée n'est copiée dans Aurora. Seuls les éléments suivants sont répliqués du cluster de base de données principal vers chaque cluster de base de données secondaire :
-
L'installation
aurora_analyticsde l'extension -
Définitions de tables étrangères (DDL)
Les éléments suivants ne se répliquent pas et doivent être provisionnés indépendamment dans chaque région contenant un cluster de base de données secondaire :
-
L'association du rôle IAM au cluster de base de données
-
La politique IAM octroyant l'accès à Amazon S3 ou aux tables Amazon S3 AWS Glue
-
Réseau VPC (points de terminaison ou NAT) utilisé pour accéder à ces services
Configuration sur une base de données globale
Étape 1 : Création de la politique et du rôle IAM dans chaque région
L'association de rôles IAM ne se réplique pas entre les clusters de base de données principal et secondaire. Vous devez créer et associer un rôle IAM avec le nom de la AuroraAnalytics fonctionnalité dans chaque région contenant un cluster de base de données principal ou secondaire.
-
Créez une politique IAM accordant un accès en lecture à vos données. Les autorisations requises dépendent du format de vos données. Pour plus d’informations, consultez Référence des politiques IAM.
-
Créez un rôle IAM approuvé par
rds.amazonaws.comet joignez-y la politique. -
Associez le rôle au cluster de base de données de cette région :
aws rds add-role-to-db-cluster \ --db-cluster-identifier <cluster-in-this-region> \ --role-arn arn:aws:iam::<account-id>:role/AuroraAnalyticsRole \ --feature-name AuroraAnalytics -
Patientez jusqu'à ce que le statut du rôle apparaisse comme Actif.
Note
Immédiatement après l'attachement d'un rôle (ou après le démarrage ou la promotion d'une instance), les requêtes portant sur des tables étrangères peuvent renvoyer brièvement l'erreur :credential to access AWS service is unavailable. Attendez que le statut du rôle soit actif avant d'exécuter des requêtes sur des tables étrangères.
Étape 2 : configurer le réseau dans chaque région
La configuration VPC ne se réplique pas non plus. Dans le VPC de chaque cluster de base de données (principal et secondaire), fournissez un chemin réseau vers les services requis afin que le cluster de base de données puisse accéder aux données de la table étrangère pour résoudre les requêtes. Assurez-vous que la configuration réseau du cluster de chaque secondaire permet d'atteindre la région de la table étrangère.
| Service | Type de point de terminaison | Nécessaire pour |
|---|---|---|
Amazon S3 (com.amazonaws.<region>.s3) |
Passerelle | Accès à toutes les données Amazon S3 et Amazon S3 Tables |
AWS Glue (com.amazonaws.<region>.glue) |
Interface | AWS Glue Data Catalog accès (tables Iceberg) |
AWS STS (com.amazonaws.<region>.sts) |
Interface | Récupération des informations d'identification des rôles IAM |
Pour les points de terminaison AWS Glue et de AWS STS l'interface, activez le DNS privé et autorisez le TCP 443 entrant depuis votre VPC CIDR.
Étape 3 : Installation de l'extension sur le serveur principal
Connectez-vous à l'instance de base de données Writer dans le cluster de base de données principal et installez l'extension dans chaque base de données dans laquelle vous souhaitez créer des tables étrangères :
CREATE EXTENSION aurora_analytics;
L'extension se réplique automatiquement sur chaque cluster de base de données secondaire.
Étape 4 : Création de tables étrangères sur le serveur principal
Sur l'instance de base de données Writer du cluster de base de données principal, créez des tables étrangères pointant vers vos données :
-- Parquet via S3 URI CREATE FOREIGN TABLE ft_orders () SERVER aurora_analytics_server OPTIONS (location 's3://my-bucket/orders/', format 'parquet', region 'us-east-1'); -- Iceberg via Glue ARN CREATE FOREIGN TABLE ft_transactions () SERVER aurora_analytics_server OPTIONS (location 'arn:aws:glue:us-east-1:123456789012:table/mydb/transactions', format 'iceberg');
Aurora réplique le DDL sur chaque cluster de base de données secondaire, où les tables étrangères sont disponibles pour les requêtes.
Étape 5 : Vérifiez sur le secondaire
Connectez-vous à un cluster de base de données secondaire et confirmez la réplication et l'accès en lecture :
SELECT extname, extversion FROM pg_extension WHERE extname = 'aurora_analytics'; SELECT count(*) FROM ft_orders;
Épinglage régional de tables étrangères
Lorsque vous créez une table étrangère, ses données location Region sont stockées dans la définition de la table et répliquées sur chaque cluster de base de données de la base de données globale. Chaque cluster de base de données lit depuis le même emplacement.
Cela implique :
-
Chaque cluster de base de données secondaire lit les données de table étrangères à partir de la région spécifiée dans la définition de la table.
-
Si cette région est différente de la région secondaire, les lectures sont interrégionales, ce qui augmente les coûts de transfert de données et la latence.
-
Le rôle IAM et le réseau de chaque secondaire permettent d'atteindre la région de la table étrangère.
Note
Les points Multi-Region d'accès Amazon S3 (MRAP) ne sont pas pris en charge en tant qu'emplacement de table étranger. Aurora PostgreSQL accepte s3:// uniquement les URI AWS Glue , les ARN de table et les ARN de tables Amazon S3 dans l'option. location Les ARN MRAP et les noms d'hôte MRAP ne sont pas valides pour cette option. location
Conseils généraux pour la préparation à la reprise après sinistre
Terminez la configuration par région dans les étapes 1 et 2 pour le cluster de base de données secondaire, puis décidez comment le cluster de base de données accédera aux données des tables étrangères :
-
Accepter les lectures interrégionales : cette approche ne convient que pour les scénarios de transition planifiés dans lesquels la région d'origine est saine.
-
Pre-stage une Region-local copie : utilisez Amazon S3 Cross-Region Replication pour que les requêtes analytiques puissent être lues localement même si la région d'origine n'est pas disponible. Préparez
ALTER FOREIGN TABLE ... OPTIONS (SET ...)des instructions pour mettre à jour les emplacements des tables étrangères afin qu'ils pointent vers la Region-local copie.
Note
Le cache de lecture sur disque n'est ni conservé ni transféré en cas de basculement ou de basculement. Les premières requêtes après l'événement lisent les données d'Amazon S3 et s'exécutent avec une latence plus élevée jusqu'à ce que le cache se réchauffe.
Gestion du basculement et du basculement
Lors d'un basculement ou d'un basculement d'une base de données globale Aurora, les requêtes de table étrangère ont une dépendance supplémentaire au-delà des connexions client de base de données standard : elles doivent atteindre Amazon S3 et AWS STS dans la région nommée par chaque table étrangère. AWS Glue
Passage global à une base de données
Les clusters de base de données principal et secondaire sont sains au moment du basculement. Une fois que le nouveau cluster de base de données principal est disponible, les requêtes continuent à être lues à partir de la région nommée dans chaque table étrangère. Si cette région est différente de la région du nouveau rédacteur, les lectures sont interrégionales et entraînent des coûts de transfert de données et une latence. Pour éviter la latence de lecture entre régions, exécutez les ALTER FOREIGN TABLE ... OPTIONS (SET ...) instructions préparées pour rediriger les tables étrangères vers une Region-local copie.
Reprise des activités après un passage au numérique
-
Autorisez les clients à se reconnecter au point de terminaison du rédacteur du nouveau cluster de base de données principal.
-
Attendez que le statut du rôle IAM soit actif. Exécutez une requête de test sur une table étrangère (par exemple,
SELECT count(*) FROM ft_orders) avec une logique de nouvelle tentative pour confirmer que les requêtes d'analyse sont opérationnelles. -
Si vous utilisez une Region-local copie, exécutez les
ALTERinstructions préparées sur le nouveau cluster de base de données principal pour mettre à jour les emplacements des tables étrangères :ALTER FOREIGN TABLE ft_orders OPTIONS (SET location 's3://dr-region-bucket/orders/', SET region 'us-west-2'); ALTER FOREIGN TABLE ft_transactions OPTIONS (SET location 'arn:aws:glue:us-west-2:123456789012:table/mydb/transactions');
Note
ALTER FOREIGN TABLE ... OPTIONS (SET ...)est une modification portant uniquement sur les métadonnées du catalogue. Il se termine immédiatement, sans aucun mouvement de données. Il faut un bref ACCESS EXCLUSIVE verrouillage sur cette seule table étrangère. Par conséquent, il est bloqué par toute requête en cours de vol sur la même table.
Basculement de base de données global
La région d'origine est peut-être altérée ou inaccessible. Si une table étrangère nomme la région altérée, les requêtes la concernant subissent une latence élevée ou échouent avec des erreurs de temporisation jusqu'à ce que cette région soit rétablie ou que vous redirigiez la table étrangère vers les données d'une région saine. Si vous avez pré-préparé une Region-local copie, exécutez les ALTER FOREIGN TABLE ... OPTIONS (SET region ...) instructions préparées pour pointer les tables étrangères vers la Region-local copie.
Retour à la région principale d'origine
Lorsque la région principale d'origine devient disponible, Aurora la réajoute automatiquement à la base de données globale en tant que cluster de base de données secondaire. Toutes ALTER FOREIGN TABLE les modifications apportées pendant le basculement ou le basculement y sont répliquées par le biais d'une réplication globale. Pour restaurer la région principale d'origine, effectuez une commutation. Une fois le basculement terminé, déterminez s'il convient de rétablir les emplacements des tables étrangères pour qu'ils pointent vers les données de la région principale restaurée.
Messages d'erreur sur une base de données globale
Après un basculement ou un basculement, les requêtes dans la nouvelle région principale peuvent échouer avec la même association de rôles IAM, les mêmes autorisations IAM et les mêmes erreurs réseau que celles qui affectent toute région exécutant un cluster de base de données secondaire. Ces erreurs et leurs résolutions sont abordées dans la section relative au basculement et au basculement de base de données globale sous. Surveillance et résolution des problèmes Les conditions préalables doivent être satisfaites dans chaque région secondaire, car l'association des rôles IAM, la politique IAM et le réseau VPC ne se répliquent pas.
-
regionIl s'agit d'une table étrangèrelocationet d'une seule définition répliquée sans remplacement par région. Les deux clusters ne peuvent pas contenir des régions différentes pour la même table. -
Les points Multi-Region d'accès Amazon S3 et les ARN des points d'accès Amazon S3 ne sont pas pris en charge en tant qu'emplacements de tables étrangers.
-
Les points de terminaison de la passerelle VPC sont régionaux et ne peuvent pas accéder à Amazon S3 d'une autre région. Un chemin réseau interrégional nécessite une NAT/internet sortie ou un Transit Gateway.
-
Après un basculement, la mise à jour de l'emplacement d'une table étrangère vers la région du nouveau cluster de base de données principal amène l'ancien cluster de base de données principal à lire Cross-region à la place.
-
La table étrangère DDL et l'extension ne se répliquent qu'une fois que la table secondaire est attachée et synchronisée. Installez l'
aurora_analyticsextension et créez des tables étrangères sur le primaire une fois le secondaire connecté afin qu'elles se propagent.