Aurora MySQL - Amazon OpenSearch Service
Conditions préalables à Aurora MySQLÉtape 1 : configurer le rôle du pipelineÉtape 2 : Création du pipelineCohérence des donnéesTypes de données de mappageLimites CloudWatch Alarmes recommandées

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.

Aurora MySQL

Procédez comme suit pour configurer un pipeline d' OpenSearch ingestion avec Amazon Aurora pour Aurora MySQL.

Conditions préalables à Aurora MySQL

Avant de créer votre pipeline OpenSearch d'ingestion, effectuez les étapes suivantes :

  1. Créez un groupe de paramètres de cluster de base de données Aurora personnalisé dans Amazon Aurora pour configurer la journalisation binaire.

    aurora_enhanced_binlog=1
binlog_backup=0
binlog_format=ROW
binlog_replication_globaldb=0
binlog_row_image=full
binlog_row_metadata=full

    Assurez-vous également que le binlog_transaction_compression paramètre n'est pas défini surON, et qu'il n'est pas défini surPARTIAL_JSON. binlog_row_value_options

  2. Sélectionnez ou créez un cluster de base de données Aurora MySQL et associez le groupe de paramètres créé à l'étape précédente au cluster de base de données.

  3. Configurez la conservation des journaux binaires sur 24 heures ou plus.

  4. Configurez l'authentification par nom d'utilisateur et mot de passe sur votre cluster Amazon Aurora à l'aide de la gestion des mots de passe avec Aurora et AWS Secrets Manager. Vous pouvez également créer une username/password combinaison en créant un secret Secrets Manager.

  5. Si vous utilisez la fonctionnalité de capture initiale complète, créez un rôle AWS KMS key et un rôle IAM pour exporter des données d'Amazon Aurora vers Amazon S3.

    Le rôle IAM doit être soumis à la politique d'autorisation suivante :

    JSON
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExportPolicy",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject*",
                "s3:ListBucket",
                "s3:GetObject*",
                "s3:DeleteObject*",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::s3-bucket-used-in-pipeline",
                "arn:aws:s3:::s3-bucket-used-in-pipeline/*"
            ]
        }
    ]
}

    Le rôle doit également avoir les relations de confiance suivantes :

    JSON
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "export.rds.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

  6. Sélectionnez ou créez un domaine OpenSearch de service ou une collection OpenSearch Serverless. Pour plus d'informations, consultez les sections Création OpenSearch de domaines de service et Création de collections.

  7. Associez une politique basée sur les ressources à votre domaine ou une politique d'accès aux données à votre collection. Ces politiques d'accès permettent à OpenSearch Ingestion d'écrire des données depuis votre cluster de base de données Amazon Aurora vers votre domaine ou votre collection.

Étape 1 : configurer le rôle du pipeline

Une fois que vous avez défini les conditions préalables de votre pipeline Amazon Aurora, configurez le rôle de pipeline à utiliser dans la configuration de votre pipeline. Ajoutez également les autorisations suivantes pour la source Amazon Aurora au rôle :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "allowReadingFromS3Buckets",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetBucketLocation",
        "s3:ListBucket",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::s3_bucket",
        "arn:aws:s3:::s3_bucket/*"
      ]
    },
     {
      "Sid": "allowNetworkInterfacesActions",
      "Effect": "Allow",
      "Action": [
        "ec2:AttachNetworkInterface",
        "ec2:CreateNetworkInterface",
        "ec2:CreateNetworkInterfacePermission",
        "ec2:DeleteNetworkInterface",
        "ec2:DeleteNetworkInterfacePermission",
        "ec2:DetachNetworkInterface",
        "ec2:DescribeNetworkInterfaces"
      ],
      "Resource": [
        "arn:aws:ec2:*:account-id:network-interface/*",
        "arn:aws:ec2:*:account-id:subnet/*",
        "arn:aws:ec2:*:account-id:security-group/*"
      ]
    },
    {
      "Sid": "allowDescribeEC2",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "allowTagCreation",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateTags"
      ],
      "Resource": "arn:aws:ec2:*:account-id:network-interface/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/OSISManaged": "true"
        }
      }
    },
    {
      "Sid": "AllowDescribeInstances",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances"
      ],
      "Resource": [
        "arn:aws:rds:region:account-id:db:*"
      ]
    },
    {
      "Sid": "AllowDescribeClusters",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBClusters"
      ],
      "Resource": [
        "arn:aws:rds:region:account-id:cluster:DB-id"
      ]
    },
    {
      "Sid": "AllowSnapshots",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBClusterSnapshots",
        "rds:CreateDBClusterSnapshot",
        "rds:AddTagsToResource"
      ],
      "Resource": [
        "arn:aws:rds:region:account-id:cluster:DB-id",
        "arn:aws:rds:region:account-id:cluster-snapshot:DB-id*"
      ]
    },
    {
      "Sid": "AllowExport",
      "Effect": "Allow",
      "Action": [
        "rds:StartExportTask"
      ],
      "Resource": [
        "arn:aws:rds:region:account-id:cluster:DB-id",
        "arn:aws:rds:region:account-id:cluster-snapshot:DB-id*"
      ]
    },
    {
      "Sid": "AllowDescribeExports",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeExportTasks"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "region",
          "aws:ResourceAccount": "account-id"
        }
      }
    },
    {
      "Sid": "AllowAccessToKmsForExport",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:DescribeKey",
        "kms:RetireGrant",
        "kms:CreateGrant",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*"
      ],
      "Resource": [
        "arn:aws:kms:region:account-id:key/export-key-id"
      ]
      },
    {
      "Sid": "AllowPassingExportRole",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::account-id:role/export-role"
      ]
    },
    {
      "Sid": "SecretsManagerReadAccess",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:secretsmanager:*:account-id:secret:*"
      ]
    }
  ]
}

Étape 2 : Création du pipeline

Configurez un pipeline d' OpenSearch ingestion similaire à ce qui suit. L'exemple de pipeline indique un cluster Amazon Aurora comme source. 

version: "2"
aurora-mysql-pipeline:
  source:
    rds:
      db_identifier: "cluster-id"
      engine: aurora-mysql
      database: "database-name"
      tables:
        include:
          - "table1"
          - "table2"
      s3_bucket: "bucket-name"
      s3_region: "bucket-region"
      s3_prefix: "prefix-name"
      export:
        kms_key_id: "kms-key-id"
        iam_role_arn: "export-role-arn"
      stream: true
      aws:
        sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"
        region: "us-east-1"
      authentication:
        username: ${{aws_secrets:secret:username}}
        password: ${{aws_secrets:secret:password}}
  sink:
    - opensearch:
        hosts: ["https://search-mydomain.us-east-1.es.amazonaws.com"]
        index: "${getMetadata(\"table_name\")}"
        index_type: custom
        document_id: "${getMetadata(\"primary_key\")}"
        action: "${getMetadata(\"opensearch_action\")}"
        document_version: "${getMetadata(\"document_version\")}"
        document_version_type: "external"
        aws:
          sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"
          region: "us-east-1"
extension:
  aws:
    secrets:
      secret:
        secret_id: "rds-secret-id"
        region: "us-east-1"
        sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"
        refresh_interval: PT1H

Vous pouvez utiliser un plan Amazon Aurora préconfiguré pour créer ce pipeline. Pour de plus amples informations, veuillez consulter Travailler avec des plans.

Pour utiliser Amazon Aurora comme source, vous devez configurer l'accès VPC pour le pipeline. Le VPC que vous choisissez doit être le même que celui utilisé par votre source Amazon Aurora. Choisissez ensuite un ou plusieurs sous-réseaux et un ou plusieurs groupes de sécurité VPC. Notez que le pipeline nécessite un accès réseau à une base de données Aurora MySQL. Vous devez donc également vérifier que votre cluster Aurora est configuré avec un groupe de sécurité VPC qui autorise le trafic entrant depuis le groupe de sécurité VPC du pipeline vers le port de base de données. Pour plus d'informations, consultez la section Contrôle de l'accès avec les groupes de sécurité.

Si vous utilisez le AWS Management Console pour créer votre pipeline, vous devez également l'attacher à votre VPC afin d'utiliser Amazon Aurora comme source. Pour ce faire, recherchez la section Configuration réseau, cochez la case Attacher au VPC et choisissez votre CIDR parmi l'une des options par défaut fournies, ou sélectionnez le vôtre. Vous pouvez utiliser n'importe quel CIDR à partir d'un espace d'adressage privé tel que défini dans la RFC 1918 Best Current Practice.

Pour fournir un CIDR personnalisé, sélectionnez Autre dans le menu déroulant. Pour éviter toute collision d'adresses IP entre OpenSearch Ingestion et Amazon Aurora, assurez-vous que le CIDR VPC Amazon Aurora est différent du CIDR pour l'ingestion. OpenSearch

Pour plus d'informations, consultez Configuration de l'accès VPC pour un pipeline.

Cohérence des données

Le pipeline garantit la cohérence des données en interrogeant ou en recevant en permanence les modifications du cluster Amazon Aurora et en mettant à jour les documents correspondants dans l' OpenSearchindex.

OpenSearch L'ingestion prend en charge end-to-end la reconnaissance afin de garantir la durabilité des données. Lorsqu'un pipeline lit des instantanés ou des flux, il crée dynamiquement des partitions pour un traitement parallèle. Le pipeline marque une partition comme terminée lorsqu'il reçoit un accusé de réception après avoir ingéré tous les enregistrements du OpenSearch domaine ou de la collection. Si vous souhaitez intégrer des données dans une collection de recherche OpenSearch sans serveur, vous pouvez générer un identifiant de document dans le pipeline. Si vous souhaitez intégrer des données dans une collection de séries chronologiques OpenSearch sans serveur, notez que le pipeline ne génère pas d'identifiant de document. Vous devez donc l'omettre document_id: "${getMetadata(\"primary_key\")}" dans la configuration de votre récepteur de pipeline.

Un pipeline d' OpenSearch ingestion fait également correspondre les actions des événements entrants aux actions d'indexation groupées correspondantes pour faciliter l'ingestion de documents. Cela permet de garantir la cohérence des données, de sorte que chaque modification de données dans Amazon Aurora soit conciliée avec les modifications de document correspondantes dans OpenSearch.

Types de données de mappage

OpenSearch Le pipeline d'ingestion fait correspondre les types de données MySQL à des représentations adaptées à la consommation de domaines ou de collections de OpenSearch services. Si aucun modèle de mappage n'est défini dans OpenSearch, détermine OpenSearch automatiquement les types de champs avec un mappage dynamique en fonction du premier document envoyé. Vous pouvez également définir explicitement les types de champs qui vous conviennent le mieux par le OpenSearch biais d'un modèle de mappage.

Le tableau ci-dessous répertorie les types de données MySQL et les types de OpenSearch champs correspondants. La colonne Type de OpenSearch champ par défaut indique le type de champ correspondant OpenSearch si aucun mappage explicite n'est défini. Dans ce cas, détermine OpenSearch automatiquement les types de champs à l'aide d'un mappage dynamique. La colonne Type de OpenSearch champ recommandé est le type de champ correspondant qu'il est recommandé de spécifier explicitement dans un modèle de mappage. Ces types de champs sont plus proches des types de données de MySQL et peuvent généralement permettre de meilleures fonctionnalités de recherche disponibles dans OpenSearch.

Type de données MySQL Type de OpenSearch champ par défaut Type de OpenSearch champ recommandé
BIGINT long long
BIGINT UNSIGNED long long non signé
BIT long octet, court, entier ou long selon le nombre de bits
DECIMAL text double ou mot-clé
DOUBLE float double
FLOAT float float
INT long entier
INT UNSIGNED long long
MEDIUMINT long entier
MEDIUMINT UNSIGNED long entier
NUMERIC text double ou mot-clé
SMALLINT long short
SMALLINT UNSIGNED long entier
TINYINT long  octet
TINYINT UNSIGNED long short
BINAIRE text binary
BLOB text binary
CHAR text text
ENUM text mot clé
LONGBLOB text binary
LONGTEXT text text
MEDIUMBLOB text binary
MEDIUMTEXT text text
SET text mot clé
TEXT text text
TINYBLOB text binary
TINYTEXT text text
VARBINARY text binary
VARCHAR text text
DATE long (en millisecondes d'époque) date
DATETIME long (en millisecondes d'époque) date
TIME long (en millisecondes d'époque) date
TIMESTAMP long (en millisecondes d'époque) date
YEAR long (en millisecondes d'époque) date
GEOMETRY texte (au format WKT) geo_shape
GEOMETRYCOLLECTION texte (au format WKT) geo_shape
LINESTRING texte (au format WKT) geo_shape
MULTILINESTRING texte (au format WKT) geo_shape
MULTIPOINT texte (au format WKT) geo_shape
MULTIPOLYGON texte (au format WKT) geo_shape
POINT texte (au format WKT) geo_point ou geo_shape
POLYGON texte (au format WKT) geo_shape
JSON text objet

Nous vous recommandons de configurer la file d'attente des lettres mortes (DLQ) dans votre OpenSearch pipeline d'ingestion. Si vous avez configuré la file d'attente, le OpenSearch service envoie tous les documents défaillants qui ne peuvent pas être ingérés en raison d'échecs de mappage dynamique vers la file d'attente.

Si les mappages automatiques échouent, vous pouvez utiliser template_type et template_content dans la configuration de votre pipeline pour définir des règles de mappage explicites. Vous pouvez également créer des modèles de mappage directement dans votre domaine de recherche ou votre collection avant de démarrer le pipeline.

Limites

Tenez compte des limites suivantes lorsque vous configurez un pipeline d' OpenSearch ingestion pour Aurora MySQL :

  • L'intégration ne prend en charge qu'une seule base de données MySQL par pipeline.

  • L'intégration ne prend actuellement pas en charge l'ingestion de données entre régions ; votre cluster Amazon Aurora et votre OpenSearch domaine doivent se trouver dans le même Région AWS environnement.

  • L'intégration ne prend actuellement pas en charge l'ingestion de données entre comptes ; votre cluster Amazon Aurora et votre pipeline OpenSearch d'ingestion doivent se trouver dans le même Compte AWS environnement.

  • Assurez-vous que l'authentification est activée sur le cluster Amazon Aurora à l'aide de Secrets Manager, qui est le seul mécanisme d'authentification pris en charge.

  • La configuration de pipeline existante ne peut pas être mise à jour pour ingérer des données provenant d'une autre base de données ou and/or d'une autre table. Pour mettre à jour le nom de la base de données et/ou de la table d'un pipeline, vous devez arrêter le pipeline et le redémarrer avec une configuration mise à jour, ou créer un nouveau pipeline.

  • Les instructions DDL (Data Definition Language) ne sont généralement pas prises en charge. La cohérence des données ne sera pas maintenue si :

    • Les clés primaires sont modifiées (add/delete/rename).

    • Les tables sont supprimées/tronquées.

    • Les noms de colonnes ou les types de données sont modifiés.

  • Si aucune clé primaire n'est définie pour les tables MySQL à synchroniser, la cohérence des données n'est pas garantie. Vous devrez définir correctement l'document_idoption personnalisée dans la configuration du OpenSearch récepteur pour pouvoir effectuer la synchronisation avec updates/deletes OpenSearch.

  • Les références à des clés étrangères associées à des actions de suppression en cascade ne sont pas prises en charge et peuvent entraîner une incohérence des données entre Aurora MySQL et. OpenSearch

  • Versions prises en charge : Aurora MySQL version 3.05.2 et supérieure.

CloudWatch Alarmes recommandées

Les CloudWatch mesures suivantes sont recommandées pour surveiller les performances de votre pipeline d'ingestion. Ces indicateurs peuvent vous aider à identifier la quantité de données traitées à partir des exportations, le nombre d'événements traités à partir des flux, les erreurs lors du traitement des exportations et des événements des flux, ainsi que le nombre de documents écrits vers la destination. Vous pouvez configurer des CloudWatch alarmes pour effectuer une action lorsque l'une de ces mesures dépasse une valeur spécifiée pendant une durée spécifiée.

Métrique Description
pipeline-name.rds. Informations d'identification modifiées Cette métrique indique la fréquence à laquelle AWS les secrets font l'objet d'une rotation.
pipeline-name.rds. executorRefreshErrors Cette métrique indique les échecs d'actualisation AWS des secrets.
pipeline-name.rds. exportRecordsTotal Cette métrique indique le nombre d'enregistrements exportés depuis Amazon Aurora.
pipeline-name.rds. exportRecordsProcessed Cette métrique indique le nombre d'enregistrements traités par le pipeline OpenSearch d'ingestion.
pipeline-name.rds. exportRecordProcessingErreurs Cette métrique indique le nombre d'erreurs de traitement dans un pipeline d' OpenSearch ingestion lors de la lecture des données d'un cluster Amazon Aurora.
pipeline-name.rds. exportRecordsSuccessTotal Cette métrique indique le nombre total d'enregistrements d'exportation traités avec succès.
pipeline-name.rds. exportRecordsFailedTotal Cette métrique indique le nombre total d'enregistrements d'exportation qui n'ont pas pu être traités.
pipeline-name.RDS. Octets reçus Cette métrique indique le nombre total d'octets reçus par un pipeline d' OpenSearch ingestion.
pipeline-name.RDS. Octets traités Cette métrique indique le nombre total d'octets traités par un pipeline d' OpenSearch ingestion.
pipeline-name.rds. streamRecordsSuccessTotal Cette métrique indique le nombre d'enregistrements traités avec succès à partir du flux.
pipeline-name.rds. streamRecordsFailedTotal Cette métrique indique le nombre total d'enregistrements n'ayant pas pu être traités à partir du flux.