Atteindre un temps d’arrêt minimal pour les mises à niveau de versions majeures dans Amazon Aurora pour PostgreSQL à l’aide d’AWS DMS: idk.dev – Gratuit : Audit complet de votre site internet

Avant de commencer !

Atteindre un temps d'arrêt minimal pour les mises à niveau de versions majeures dans Amazon Aurora pour PostgreSQL à l'aide d'AWS DMS: idk.dev
Share on facebook
Share on twitter
Share on pinterest

[*]

AWS propose deux options PostgreSQL gérées: Amazon RDS pour PostgreSQL et Amazon Aurora PostgreSQL. Lorsqu’Amazon RDS ou Aurora prend en charge une nouvelle version majeure d’un moteur de base de données, par exemple PostgreSQL 10 à 11, vous pouvez mettre à niveau vos instances de base de données vers la nouvelle version. Les mises à niveau de versions majeures peuvent contenir des modifications de base de données qui peuvent ne pas être rétrocompatibles avec les applications existantes. Pour plus d’informations, consultez Mise à niveau du moteur de base de données PostgreSQL pour Aurora PostgreSQL et Meilleures pratiques pour la mise à niveau d’Amazon RDS vers les versions majeures et mineures de PostgreSQL.

Amazon RDS et Aurora offrent tous deux une option pour lancer manuellement une mise à niveau de version majeure en modifiant votre instance de base de données. Ceci est également connu comme un mise à niveau sur place et nécessite des temps d’arrêt pour vos applications pendant le processus de mise à niveau. De plus, vous devez restaurer la dernière sauvegarde en cas de problème avec la mise à niveau. Par conséquent, cette option peut ne pas être souhaitable pour tous les types de charge de travail. Une autre approche consiste à utiliser AWS Database Migration Service (DMS) pour les mises à niveau de versions majeures. AWS DMS utilise la réplication logique PostgreSQL pour la synchronisation en temps quasi réel des données entre deux versions principales. Vous ne devez utiliser AWS DMS que si vous remplissez les conditions suivantes:

  • Aucune option de mise à niveau sur place n’est disponible pour une version majeure particulière
  • Vous devez mettre à niveau quelques bases de données ou sélectives dans un cluster Aurora
  • Vous souhaitez minimiser les temps d’arrêt requis pour le processus de mise à niveau et disposer d’une option de restauration plus rapide vers l’ancienne instance en cas de problème avec la transition

La solution AWS DMS nécessite davantage de ressources AWS et une planification supplémentaire par opposition à l’option de mise à niveau sur place. Comme DMS est basé sur une solution de réplication logique sortante, il y aura une augmentation de la charge en termes d’utilisation du processeur, de lecture et d’écriture IOPS à la source. L’augmentation peut varier en fonction de facteurs tels que l’activité de changement, le nombre de tâches actives pendant la migration. En tant que meilleure pratique, veuillez tester la procédure DMS dans un environnement de non-production et assurez-vous que vous avez dimensionné votre environnement source pour répondre à cette charge supplémentaire. En outre, vous devez disposer d’une configuration optimale pour le nombre de tâches simultanées, l’instance de réplication DMS et la surveillance nécessaire.

Cet article vous guide à travers la mise à niveau de votre base de données Aurora PostgreSQL 10 vers Aurora PostgreSQL 11 à l’aide d’AWS DMS avec un temps d’arrêt minimal. La procédure pas à pas fournit de nombreux artefacts réutilisables qui peuvent vous aider à démarrer rapidement. Bien que cette publication utilise Aurora, les instructions sont également valables pour une instance Amazon RDS pour PostgreSQL.

Vue d’ensemble de la solution

À un niveau élevé, ce message comprend les étapes suivantes:

  • Configuration des ressources AWS nécessaires à l’aide d’AWS CloudFormation
  • Configuration de l’environnement source basé sur la version Aurora PostgreSQL 10.x et chargement des exemples de données
  • Configuration de l’environnement cible basé sur Aurora PostgreSQL 11.x
  • Exécution d’une migration de schéma à l’aide des utilitaires natifs de PostgreSQL
  • Configuration de la migration des données (pleine charge et capture des données modifiées (CDC)) à l’aide d’AWS DMS.
  • Surveillance, test et transition vers l’environnement cible

Le diagramme suivant illustre l’architecture de haut niveau.

Conditions préalables

Avant de commencer, vous devez disposer des prérequis suivants:

  • Un compte AWS avec des privilèges d’administrateur IAM. Vous pouvez également utiliser l’administrateur de stratégie gérée AWS.
  • Connaissance des services AWS suivants:
  • Expérience avec psql.

Configuration de l’environnement

Pour configurer votre environnement, procédez comme suit:

  1. Téléchargez le modèle CloudFormation Aurora_PostgreSQL_DBLaunch.yaml du dépôt GitHub.
  2. Lancez-le sur AWS Management Console.
  3. Nommez la pile apgupgrade.
  4. Spécifiez les configurations de base de données source et cible.
  5. Laissez les autres valeurs à leur valeur par défaut.
    Ce message utilise la région USA Est (Virginie du Nord), mais vous pouvez utiliser n’importe quelle région préférée. Assurez-vous que lors de l’utilisation des commandes AWS CLI, vous définissez AWS_DEFAULT_REGION dans votre région préférée.
    La pile CloudFormation déploie les ressources suivantes:
    • VPC (10.0.0.0/25)
    • Passerelle Internet
    • Deux sous-réseaux privés
    • Deux sous-réseaux publics
    • Environnement AWS Cloud9
    • Cluster Aurora avec compatibilité PostgreSQL 10.x (aurora-source) et 11.x (aurora-target) dans un VPC, lancé avec une seule instance db.r5.large (instance Writer) uniquement
    • Exemple de base de données avec le nom demo
      .Vous pouvez vous référer à la documentation AWS CloudFormation pour en savoir plus sur le processus de création de pile. La création de la pile CloudFormation prend environ 15 minutes. Vous pouvez voir la progression en regardant dans la section des événements.
  1. Enregistrer le nom d’utilisateur maître Aurora pgadmin. Le mot de passe par défaut de l’utilisateur principal est auradmin.
    Cette publication utilise l’AWS Cloud9 IDE pour exécuter des scripts SQL et charger des données. Vous pouvez également lancer une instance Amazon EC2 dans le même VPC.
  2. Une fois le lancement réussi, connectez-vous à l’environnement AWS Cloud9.
  3. Installez les outils client PostgreSQL.
  4. Clonez l’exemple de référentiel AWS DMS à partir de GitHub et chargez les données dans la base de données source. Voir le code suivant:
    cd ~/environment
    git clone https://github.com/aws-samples/aws-database-migration-samples.git
  5. Accédez au /PostgreSQL/sampledb/v1 annuaire.
  6. Configurez les variables d’environnement pour les points de terminaison Aurora source et cible. Voir le code suivant:
    export AURORA_SOURCE_EP=
    export AURORA_TARGET_EP=

    Vous pouvez obtenir les noms des points de terminaison de cluster dans la section de sortie AWS CloudFormation.

  7. Connectez-vous en tant qu’utilisateur maître à aurora-source à l’aide de l’utilitaire psql et configurez les exemples de données. Le code suivant crée le schéma dms_sample et charge les objets de schéma et les données:
    cd ~/environment/aws-database-migration-samples/PostgreSQL/sampledb/v1
    psql -h $AURORA_SOURCE_EP  -U pgadmin -d demo -f install-postgresql.sql 

    L’installation par défaut prend entre 30 et 45 minutes et charge environ 7 Go de données. Vous pouvez voir des erreurs psql telles que role does not exist ou psql: install-postgresql.sql:30: INFO: pg_hint_plan: hint syntax error at or near APPEND. Vous pouvez les ignorer.

  8. Vérifiez que les tables sont correctement configurées et que le chargement des données est terminé.
  9. Pour vérifier la liste des tables et leurs tailles, exécutez la commande psql suivante:
    psql -h $AURORA_SOURCE_EP -U pgadmin -d demo 
    alter database demo set search_path="$user","dms_sample","public";
     dt+ dms_sample.*
  10. Clonez le référentiel GitHub qui contient les scripts et les SQL utilisés par ce post. Voir le code suivant:
    cd ~/environment
    git clone https://github.com/aws-samples/amazon-aurora-postgresql-upgrade

Configuration de l’environnement source

Il est important de passer en revue en profondeur les conditions préalables, les limitations et les meilleures pratiques lorsque vous configurez votre environnement source. Ce post met en évidence quelques considérations importantes. Pour plus d’informations, consultez Utilisation d’une base de données PostgreSQL comme source pour AWS DMS.

Activation de la réplication logique

Activer la réplication logique en mettant à jour rds.logical_replication=1 dans le aurora-source groupe de paramètres de cluster et redémarrez l’instance. Pour plus d’informations, consultez Utilisation de la réplication logique PostgreSQL avec Aurora. Voir le code suivant:

# Get the parameter group name and Instance details for Aurora cluster
aws rds describe-db-clusters --db-cluster-identifier "aurora-source" --query "DBClusters[*].[DBClusterIdentifier,DBClusterMembers[0].DBInstanceIdentifier,DBClusterParameterGroup]" --output table

# Set the rds.logical_replication to 1 for enabling replication
aws rds modify-db-cluster-parameter-group 
--db-cluster-parameter-group-name  
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot"

# Reboot the instance 
aws rds reboot-db-instance --db-instance-identifier  

Considérations sur le type de données

AWS DMS ne prend pas en charge tous les types de données PostgreSQL lors de la migration des données de PostgreSQL vers PostgreSQL. À la date de publication de cet article de blog, vous ne pouvez pas migrer les types de données composites et les horodatages avec des fuseaux horaires. En outre, AWS DMS diffuse certains types de données sous forme de chaînes si le type de données est inconnu. Certains types de données, tels que XML et JSON, peuvent migrer avec succès en tant que petits fichiers, mais peuvent échouer s’il s’agit de documents volumineux. Si vous avez des tables avec de tels types de données, vous devez utiliser des outils de réplication PostgreSQL natifs comme pg_dump ou la réplication logique Publisher / Subscriber pour migrer ces tables. Pour plus d’informations, consultez Migration de PostgreSQL vers PostgreSQL à l’aide d’AWS DMS. Voir le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS
psql -h $AURORA_SOURCE_EP -U pgadmin -d demo -f SourceDB/dms_unsupported_datatype.sql

Vous ne voyez pas de lignes pour la requête précédente, car vous n’avez aucun type de données non pris en charge dans votre configuration.

Une autre considération clé consiste à identifier les tables NUMERIC type de données sans précision ni échelle. Lors du transfert de données NUMERIC type de données mais sans précision ni échelle, AWS DMS utilise NUMERIC (28,6) (une précision de 28 et une échelle de 6) par défaut. Par exemple, la valeur 0.611111104488373 de la source est convertie en 0.611111 sur la cible PostgreSQL. Voir le code suivant:

select table_schema,table_name,column_name,data_type from information_schema.columns where data_type ='numeric' and numeric_scale is null;

Vous devez évaluer l’impact de ce problème de précision sur votre charge de travail et ajuster la précision de la table.

Si votre application doit conserver la précision et l’échelle de la base de données cible, vous devez modifier la base de données source à l’aide d’ALTER TABLE. le ALTER TABLE est une commande DDL (Data Definition Language) qui acquiert un verrou exclusif sur la table et est maintenue jusqu’à la fin de la transaction, ce qui provoque un empilement des connexions à la base de données et une panne d’application, en particulier pour les grandes tables. Par conséquent, déployez ces modifications pendant une fenêtre de maintenance après une analyse approfondie.

Si ce n’est pas un problème pour votre charge de travail, vous pouvez répliquer avec la configuration telle quelle, avec la mise en garde que vous ne pouvez pas activer la validation AWS DMS pour la table impliquée. Pour plus d’informations, consultez Validation des tâches AWS DMS.

Clés primaires manquantes

Une table capturée doit avoir une clé primaire. Si une table n’a pas de clé primaire, AWS DMS ignore DELETE et UPDATE enregistrer les opérations pour cette table. Vous avez également besoin d’une clé primaire à des fins de CDC et de validation des données.

Pour identifier les tables qui n’ont pas de clé primaire, entrez le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS
psql -h $AURORA_SOURCE_EP -U pgadmin -d demo -f SourceDB/missing_pk.sql

table_schema  |    table_name
--------------+------------------
 dms_sample   | mlb_data
 dms_sample   | nfl_data
 dms_sample   | nfl_stadium_data
 dms_sample   | seat

Pour gérer ces tables, tenez compte des suggestions suivantes:

  • Identifiez toute colonne pouvant servir de clé primaire. Il peut s’agir d’une colonne avec un index unique et sans contrainte nulle.
  • Si une telle clé n’existe pas, essayez d’ajouter une clé de substitution en ajoutant une colonne comme GUID. Une autre option consiste à ajouter toutes les colonnes présentes dans le tableau.
  • Si le tableau ne reçoit que des insertions et n’accepte aucune mise à jour ou suppression (par exemple, vous l’utilisez comme tableau d’historique), vous pouvez le laisser tel quel et DMS copiera les insertions.

Dans cette procédure pas à pas, vous créez des clés primaires sur toutes les tables (à l’exception du siège) pour vous assurer que la validation CDC et AWS DMS se produit. Étant donné que vous ignorez l’étape de création de clé primaire pour la table de siège, vous pouvez remarquer qu’AWS DMS signale l’état de validation comme aucune clé primaire et n’effectue aucune validation de données sur cette table. Voir le code suivant:

set search_path='dms_sample';
alter table mlb_data add primary key (mlb_id);
alter table nfl_data add primary key (position ,name,team);
alter table nfl_stadium_data add primary key(stadium,team);

Propagation du langage de définition des données

Vous pouvez répliquer les instructions DDL avec AWS DMS, mais il existe des exceptions. Par exemple, lors de l’utilisation de CDC, AWS DMS ne prend pas en charge TRUNCATE opérations. Pour plus d’informations, consultez Limitations relatives à l’utilisation d’une base de données PostgreSQL en tant que source pour AWS DMS.

En tant que meilleure pratique, vous devez appliquer manuellement les instructions DDL pendant la fenêtre de maintenance sur la base de données source et cible. En fonction de votre stratégie DDL, assurez-vous de l’activer ou de la désactiver en configurant l’attribut de connexion supplémentaire captureDDLs lors de la création de point de terminaison et des paramètres de stratégie de tâche AWS DMS. Pour plus d’informations, voir Paramètres de tâche pour le traitement des modifications Gestion DDL.

Autres considérations avant la mise à niveau

PostgreSQL version 11 contient plusieurs modifications susceptibles d’affecter la compatibilité avec les versions précédentes. Par exemple, la colonne relhaspkey a été déconseillé dans le pg_class catalogue, et vous devez utiliser le pg_index catalogue à la place pour vérifier les clés primaires. Si vous avez des requêtes de surveillance personnalisées qui dépendent de telles colonnes, vous devez les modifier en conséquence. Pour plus d’informations sur les modifications susceptibles d’affecter la compatibilité avec les versions précédentes, consultez les notes de publication de la version principale (telles que les notes de publication de PostgreSQL 11.0 sur le site Web de PostgreSQL).

Si vous utilisez des extensions comme pg_stat_statements ou pg_hint_plan, vous devez les créer manuellement dans la base de données cible. Lors de leur création, assurez-vous de vérifier s’il existe une incompatibilité de version entre la base de données source et la base de données cible et recherchez les notes de publication. Par exemple, pg_repack a ajouté la prise en charge de PostgreSQL 11 dans 1.4.4, ce qui signifie que vous devez mettre à niveau votre pg_repack client à 1.4.4. Vous pouvez vérifier les extensions installées à l’aide du code suivant:

Après avoir configuré l’environnement source et vérifié qu’il est prêt, vous pouvez configurer l’environnement cible.

Configuration de l’environnement cible

Il est important d’examiner attentivement les conditions préalables, les limitations et les meilleures pratiques lors de la configuration de votre environnement cible. Pour plus d’informations, consultez Utilisation d’une base de données PostgreSQL comme cible pour AWS Database Migration Service. Dans cette section, vous effectuez la migration de schéma et les paramètres requis dans l’environnement.

Cet article fournit un groupe de paramètres personnalisé basé sur PostgreSQL version 11. Vous pouvez personnaliser davantage cela en fonction de vos configurations existantes.

Configurer session_replication_role =replica pour désactiver temporairement tous les déclencheurs de l’instance jusqu’à la fin de la migration. Voir le code suivant:

# Identify instance id for aurora-target cluster

aws rds describe-db-clusters --db-cluster-identifier "aurora-target" 
--query "DBClusters[*].[DBClusterIdentifier,DBClusterMembers[0].DBInstanceIdentifier,
DBClusterParameterGroup]" --output table

# Check DB parameter group

aws rds describe-db-instances --db-instance-identifier  
 --query "DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,
 DBParameterGroups[0].DBParameterGroupName,DBParameterGroups[0].ParameterApplyStatus]"
 --output table

# Modify session_replication_role setting to replica

aws rds modify-db-parameter-group --db-parameter-group-name  
--parameters "ParameterName=session_replication_role,ParameterValue=replica,
ApplyMethod=immediate"

# Make sure the ParameterApplyStatusvalue changes from applying to in-sync
aws rds describe-db-instances --db-instance-identifier  
 --query "DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,
 DBParameterGroups[0].DBParameterGroupName,DBParameterGroups[0].ParameterApplyStatus]"
 --output table

# Verify that database parameter is set in target database

demo=> show session_replication_role ;
 session_replication_role 
--------------------------
 replica
(1 row)

Pour poursuivre cette migration, vous devez d’abord créer le schéma et les objets associés dans la base de données cible. La migration de schéma comprend deux étapes: migrer les utilisateurs, les rôles et les autorisations et migrer les définitions de schéma. Comme il s’agit d’une migration homogène, vous utilisez des outils PostgreSQL natifs tels que pg_dumpall et pg_dump.

Migration d’utilisateurs, de rôles et d’autorisations système

Utilisation pg_dumpall pour vider des objets globaux communs à toutes les bases de données. Cela inclut des informations sur les rôles et les propriétés des bases de données, telles que les autorisations d’accès qui s’appliquent à des bases de données entières (pg_dump n’exporte pas ces objets). Voir le code suivant:

cd ~/environment
cd amazon-aurora-postgresql-upgrade/DMS/SourceDB
pg_dumpall -h $AURORA_SOURCE_EP -g -U pgadmin -f db_roles.sql --no-role-password

Amazon RDS pour PostgreSQL et Aurora PostgreSQL bloquent l’accès à la table du catalogue pg_authid. Par conséquent, vous devez utiliser le —no—role-password option dans pg_dumpall pour vider la définition de l’utilisateur et des rôles. De plus, vous devez utiliser le client PostgreSQL 10 pour cela.

le db_roles.sql le fichier contient toutes les informations sur l’utilisateur et le rôle, y compris rdsadmin et autre rds_* les rôles. Identifiez les utilisateurs appropriés pour votre environnement et excluez les utilisateurs indésirables et les définitions d’espace disque logique du script SQL et exécutez-le sur la base de données cible. Cela garantit que des utilisateurs et des rôles cohérents sont configurés dans l’environnement source et l’environnement cible. Étant donné que les mots de passe ne sont pas exportés, vous devez synchroniser les mots de passe manuellement à l’aide alter user commandes.

Si vous stockez vos informations d’identification dans AWS Secrets Manager ou utilisez l’authentification IAM, configurez les informations d’identification et les autorisations nécessaires pour l’environnement cible.

psql -h $AURORA_TARGET_EP -U pgadmin -d demo -c "CREATE USER dms_user WITH PASSWORD 'dms_user'"

Migration d’objets de schéma

Pour copier le schéma DDL, vous utilisez le pg_dump commander. Voir le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS/SourceDB
pg_dump –h  $AURORA_SOURCE_EP -d demo --schema-only -U pgadmin -f pg_schema.sql

le pg_schema.sql le fichier inclut toutes les instructions DDL.

Il est recommandé de créer des objets dans l’ordre suivant pour un chargement efficace des données:

  1. Créez des séquences, des tables et des contraintes de clé primaire pour lancer le chargement complet.
  2. Une fois le chargement complet terminé, vous pouvez arrêter les tâches avant d’appliquer les modifications CDC. Vous pouvez gérer cela dans les paramètres de tâche AWS DMS.
  3. Créez des index secondaires supplémentaires et d’autres objets restants.

Cette approche garantit que les index secondaires ne ralentissent pas le processus de chargement complet.

Ce message a déjà extrait le dms_sample DDL liés au schéma de la pg_schema.sql et créé plusieurs fichiers DDL en fonction du type d’objet. Vous pouvez trouver ces fichiers SQL dans le TargetDB annuaire. Pour créer le dms_sample schéma dans l’environnement cible, entrez le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS/
psql -h $AURORA_TARGET_EP -U pgadmin -d demo -f ./TargetDB/create_table.sql
psql -h $AURORA_TARGET_EP -U pgadmin -d demo -f ./TargetDB/create_pk_constraint.sql

Vérifiez que les objets de schéma se trouvent dans la cible avant de procéder à la migration de la base de données.

Migration de base de données

Dans cette étape, vous créez une instance de réplication AWS DMS (AWS DMS version 3.3.1), des points de terminaison source et cible via AWS CloudFormation à l’aide du nom de la pile DMSRepforBlog. Étant donné que vous utilisez les commandes AWS CLI pour créer des tâches de réplication, vous devez créer deux rôles: dms-vpc-role et dms-cloudwatch-logs-role. Pour obtenir des instructions, consultez Création des rôles IAM à utiliser avec l’AWS CLI et l’API AWS DMS.

Lancez le modèle CloudFormation avec le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS/src 
# Install jq utility
sudo yum install jq -y
# Set AURORA_DB_CFSTACK_NAME to Aurora PostgreSQL launch CloudFormation stack name. 
export AURORA_DB_CFSTACK_NAME=""
echo $AURORA_DB_CFSTACK_NAME
# Verify above stack name matches the Aurora stack created in earlier step

export AWS_DEFAULT_REGION="us-east-1"

#Source Endpoint Information
SrcRDSEndPoint=$(aws cloudformation describe-stacks --stack-name $AURORA_DB_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="SrcRDSEndPoint") | .OutputValue')

#Target Endpoint Information
TgtRDSEndPoint=$(aws cloudformation describe-stacks --stack-name $AURORA_DB_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="TgtRDSEndPoint") | .OutputValue')

#Subnet Information
SubnetID1=$(aws cloudformation describe-stacks --stack-name $AURORA_DB_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="SubnetID1") | .OutputValue')

SubnetID2=$(aws cloudformation describe-stacks --stack-name $AURORA_DB_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="SubnetID2") | .OutputValue')

#Security Group Information
RepSecurityGroup=$(aws cloudformation describe-stacks --stack-name $AURORA_DB_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="RDSSecurityGrp") | .OutputValue')

export SrcDBUsername="pgadmin"
export SrcDBPassword="auradmin"
export TgtDBUsername="pgadmin"
export TgtDBPassword="auradmin"

# Launch the Cloudformation Stack to create DMS replication instance
aws cloudformation create-stack --stack-name DMSRepforBlog --template-body file://DMSRepInstance.yaml --parameters ParameterKey=RepAllocatedStorage,ParameterValue=100 ParameterKey=RepMultiAZ,ParameterValue=false ParameterKey=RepSecurityGroup,ParameterValue=$RepSecurityGroup ParameterKey=ReplInstanceType,ParameterValue=dms.r4.2xlarge ParameterKey=SrcDBUsername,ParameterValue=$SrcDBUsername ParameterKey=SrcDBPassword,ParameterValue=$SrcDBPassword ParameterKey=SrcDatabaseConnection,ParameterValue=$SrcRDSEndPoint ParameterKey=SrcEngineType,ParameterValue=aurora-postgresql ParameterKey=Subnets,ParameterValue="$SubnetID1 , $SubnetID2" ParameterKey=TgtDBUsername,ParameterValue=$TgtDBUsername ParameterKey=TgtDBPassword,ParameterValue=$TgtDBPassword ParameterKey=TgtDatabaseConnection,ParameterValue=$TgtRDSEndPoint ParameterKey=TgtEngineType,ParameterValue=aurora-postgresql

La création d’une pile prend jusqu’à 5 minutes. Une fois terminé, testez la connexion pour la source et la cible avec le code suivant:

 Set AWSDMS_CFSTACK_NAME to DMS replication Cloudformation stack name
AWSDMS_CFSTACK_NAME="DMSRepforBlog"
export AWS_DEFAULT_REGION="us-east-1"
#Set variable to replication instance arn
DMSREP_INSTANCE_ARN=$(aws cloudformation describe-stacks --stack-name $AWSDMS_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="ReplicationInstanceArn") | .OutputValue')

# Set source database end point arn
DB_SRC_ENDPOINT=$(aws cloudformation describe-stacks --stack-name $AWSDMS_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="SrcEndpointArn") | .OutputValue')
# Set target database end point arn
DB_TGT_ENDPOINT=$(aws cloudformation describe-stacks --stack-name $AWSDMS_CFSTACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="TgtEndpointArn") | .OutputValue')

Après avoir obtenu l’ARN pour l’instance de réplication et les points de terminaison, vous pouvez continuer à tester votre connexion. Voir le code suivant:

#Test source DB connection

aws dms test-connection --replication-instance-arn ${DMSREP_INSTANCE_ARN} --endpoint-arn ${DB_SRC_ENDPOINT}
# Ensure status changes from testing to successful (takes about ~1 min)
aws dms describe-connections --filter Name=endpoint-arn,Values=${DB_SRC_ENDPOINT} Name=replication-instance-arn,Values=${DMSREP_INSTANCE_ARN} --output table

#Repeat same steps for target DB

aws dms test-connection --replication-instance-arn ${DMSREP_INSTANCE_ARN} --endpoint-arn ${DB_TGT_ENDPOINT}
# Ensure status changes from testing to successful (takes about ~1 min)
aws dms describe-connections --filter Name=endpoint-arn,Values=${DB_TGT_ENDPOINT} Name=replication-instance-arn,Values=${DMSREP_INSTANCE_ARN} --output table

Pour actualiser le point de terminaison source des schémas, entrez le code suivant:

# Below command is an asynchronous operation and can take several minutes

aws dms refresh-schemas --endpoint-arn $DB_SRC_ENDPOINT --replication-instance-arn $DMSREP_INSTANCE_ARN --output table

# Check status
aws dms describe-refresh-schemas-status --endpoint-arn $DB_SRC_ENDPOINT --output table

Configuration d’AWS DMS

AWS DMS prend en charge la pleine charge et CDC pour cette migration. Vous pouvez également utiliser des outils natifs tels que pg_dump pour la pleine charge et AWS DMS pour CDC uniquement. Ce message utilise AWS DMS pour effectuer à la fois le chargement complet et le CDC.

Dans cette procédure pas à pas, vous créez deux tâches: une pour les grandes tables et l’autre pour les autres tables pour améliorer le parallélisme à l’aide de différents paramètres de tâche. La cohérence transactionnelle est conservée au sein d’une tâche, de sorte que les tables de tâches distinctes ne participent pas aux transactions courantes.

Pendant la migration, le chargement complet de grandes tables (en termes de lignes ou de taille physique de la table) peut prendre un temps considérable. Voici les meilleures pratiques pour la charge complète d’AWS DMS:

  • Identifiez les grandes tables et divisez-les en plusieurs morceaux en fonction des clés primaires numériques. Divisez ces morceaux en plusieurs tâches sur le nombre d’instances DMS.
  • Pour copier de grandes tables partitionnées, divisez manuellement les tâches ou utilisez la partition automatique disponible dans AWS DMS à partir de la version 1.2 ou supérieure.
  • Choisissez la classe d’instance de réplication appropriée et le nombre d’instances de réplication après avoir effectué quelques itérations dans un environnement hors production. Pour plus d’informations, consultez Choix de la taille optimale pour une instance de réplication.
  • Planifiez votre pleine charge pendant les heures creuses à la source pour réduire la charge et minimiser les besoins de stockage pour conserver les modifications de la base de données dans les journaux WAL (Write Ahead Logs).
  • Désactivez l’aspirateur automatique sur la base de données cible et activez-le une fois la charge complète terminée.

Pour plus d’informations, consultez Amélioration des performances d’une migration AWS DMS.

Vous utilisez les commandes AWS CLI pour créer deux tâches DMS:

  • La tâche 1 comprend person, sporting_event_ticket, et ticket_purchase_hist parce qu’ils ont des relations clés étrangères
  • La tâche 2 comprend les tables restantes

Le modèle CloudFormation de l’instance de réplication DMS Les sorties L’onglet contient des valeurs pour les ARN de réplication et de noeud final. Vous pouvez également utiliser le jq utilitaire pour extraire l’ARN requis. Voir le code suivant:

# Switch to directory hosting table mapping and task setting files
cd ~/environment/amazon-aurora-postgresql-upgrade/DMS/Migration
# Task 1
export task_identifier=dms-sample-task1-full-load-cdc
aws dms create-replication-task --replication-task-identifier ${task_identifier} --source-endpoint-arn ${DB_SRC_ENDPOINT} 
--target-endpoint-arn ${DB_TGT_ENDPOINT} --replication-instance-arn ${DMSREP_INSTANCE_ARN} --migration-type full-load-and-cdc 
--table-mappings 'file://table-mapping-task1.json' --replication-task-settings 'file://tasksetting.json'

DMS_TASK_ARN1=$(aws dms describe-replication-tasks | jq -r  '.ReplicationTasks[]|select(.ReplicationTaskIdentifier=="dms-sample-task1-full-load-cdc")|.ReplicationTaskArn')

# Task 2
export task_identifier=dms-sample-task2-full-load-cdc

aws dms create-replication-task --replication-task-identifier ${task_identifier} --source-endpoint-arn ${DB_SRC_ENDPOINT} 
--target-endpoint-arn ${DB_TGT_ENDPOINT} --replication-instance-arn ${DMSREP_INSTANCE_ARN} --migration-type full-load-and-cdc 
--table-mappings 'file://table-mapping-task2.json' --replication-task-settings 'file://tasksetting.json'

DMS_TASK_ARN2=$(aws dms describe-replication-tasks | jq -r  '.ReplicationTasks[]|select(.ReplicationTaskIdentifier=="dms-sample-task2-full-load-cdc")|.ReplicationTaskArn')

Assurez-vous que vous suivez les instructions spécifiques pour configurer les tâches et les points de terminaison en fonction de la version du moteur AWS DMS. Par exemple, si vous utilisez une version d’AWS DMS inférieure à 3.1.0, vous devez effectuer une configuration supplémentaire à la source.

Vous pouvez démarrer les tâches lorsqu’elles sont prêtes. Pour vérifier leur état, utilisez le code suivant et assurez-vous que ReplicationTaskStatus passe de creating à ready:

aws dms describe-replication-tasks --filters Name=replication-instance-arn,Values=${DMSREP_INSTANCE_ARN} --query "ReplicationTasks[:].{ReplicationTaskIdentifier:ReplicationTaskIdentifier,ReplicationTaskArn:ReplicationTaskArn,ReplicationTaskStatus:Status,ReplicationTFullLoadPercent:ReplicationTaskStats.FullLoadProgressPercent}" --output table

# Start tasks
aws dms start-replication-task --replication-task-arn ${DMS_TASK_ARN1} --start-replication-task-type start-replication
aws dms start-replication-task --replication-task-arn ${DMS_TASK_ARN2} --start-replication-task-type start-replication

# Track progress
aws dms describe-replication-tasks --filters Name=replication-instance-arn,Values=${DMSREP_INSTANCE_ARN} --query "ReplicationTasks[:].{ReplicationTaskIdentifier:ReplicationTaskIdentifier,ReplicationTaskArn:ReplicationTaskArn,ReplicationTaskStatus:Status,ReplicationTFullLoadPercent:ReplicationTaskStats.FullLoadProgressPercent}" --output table

Remarque: Une fois la tâche démarrée, vous pouvez vérifier si AWS DMS a créé les emplacements de réplication dans le aurora-source cluster en exécutant la commande suivante (select * from pg_replication_slots). Un emplacement est créé par tâche. Cela est vrai uniquement pour les tâches à pleine charge et CDC. Si vous utilisez des tâches CDC uniquement, vous devez créer l’emplacement manuellement et le spécifier dans la configuration du point de terminaison source. Assurez-vous de nettoyer les tâches et les emplacements manuels une fois qu’ils sont terminés ou lorsqu’ils ne sont plus nécessaires.

# Track progress describing statistics at table level
aws dms describe-table-statistics --replication-task-arn ${DMS_TASK_ARN1} --output table
aws dms describe-table-statistics --replication-task-arn ${DMS_TASK_ARN2} --output table

Une fois le chargement complet terminé, les tâches sont configurées pour s’arrêter. Vous pouvez maintenant créer des index supplémentaires et des objets restants. Voir le code suivant:

cd ~/environment/amazon-aurora-postgresql-upgrade/DMS
psql -h $AURORA_TARGET_EP  -U pgadmin -d demo -f ./TargetDB/create_secondary_index.sql
psql -h $AURORA_TARGET_EP  -U pgadmin -d demo -f ./TargetDB/create_fk_constraints.sql
psql -h $AURORA_TARGET_EP -U pgadmin -d demo -f ./TargetDB/create_view.sql
psql -h $AURORA_TARGET_EP  -U pgadmin -d demo  -f ./TargetDB/create_function.sql
psql -h $AURORA_TARGET_EP  -U pgadmin -d demo -f ./TargetDB/object_grants.sql

Vous devez reprendre les tâches de création post-index pour une réplication continue. Voir le code suivant:

aws dms start-replication-task --replication-task-arn ${DMS_TASK_ARN1} --start-replication-task-type resume-processing
aws dms start-replication-task --replication-task-arn ${DMS_TASK_ARN2} --start-replication-task-type resume-processing

Vous pouvez maintenant effectuer une activité DML sur la source et voir AWS DMS la répliquer sur la cible. Voir le code suivant:

psql -h $AURORA_SOURCE_EP -U pgadmin -d demo -c "select dms_sample.generateticketactivity(1000)"
psql -h $AURORA_SOURCE_EP -U pgadmin -d demo -c "select dms_sample.generatetransferactivity(100)"

Vous pouvez suivre la progression de la tâche via la console. La capture d’écran suivante montre le Tâches de migration de base de données page.

L’état de validation pour toutes les tables est validé, à l’exception de la table de siège, qui a l’état Pas de clé primaire. Voir la capture d’écran suivante.

Suivi de la migration

Vous pouvez surveiller la progression de la migration à l’aide des métriques Amazon CloudWatch. Pour plus d’informations, consultez Surveillance des tâches AWS DMS. En tant que meilleure pratique, assurez-vous de configurer des alarmes CloudWatch pour CDCLatencySource et CDCLatencyTarget. Cela permet d’obtenir des alertes en temps opportun sur le retard de réplication et de prendre les mesures appropriées. Pour plus d’informations sur les exemples de commandes AWS CLI et la configuration de la surveillance pour CDCLatencySource et CDCLatencyTarget, consultez le fichier de surveillance des tâches DMS sur GitHub. Vous pouvez également surveiller TransactionLogsDiskUsage et CPUUtilization métriques sur le cluster source aurora. Pour plus d’informations, consultez Surveillance d’un cluster de bases de données Amazon Aurora.

Dépannage

Lors de la migration de bases de données complexes et multi-téraoctets, vous pouvez rencontrer des problèmes tels que des erreurs ou un lent traitement de la copie des données. Dans ces scénarios, vous pouvez vous référer aux publications suivantes, qui couvrent diverses techniques de dépannage et les meilleures pratiques pour l’utilisation d’AWS DMS:

Tester votre application

Une fois la réplication interceptée via AWS DMS, vous pouvez commencer à tester votre application en vous connectant à aurora-target grappe. Avant de procéder aux tests, rassemblez des statistiques pour la base de données à l’aide d’utilitaires tels que vacuumdb ou analyse. Par exemple, consultez le code suivant:

vaccumDB -d demo -vZ -h  -U pgadmin -p 5432

Vous pouvez utiliser les stratégies de test suivantes:

  • Pour les tests en lecture seule, pointez votre application directement vers le aurora-target cluster lorsque la réplication est activée.
  • Pour l’écriture ou tout type de test de stress sur la cible, créez un instantané de cluster DB ou clonez la base de données du aurora-target grappe. De cette façon, vous n’avez pas à interrompre le processus de réplication. Assurez-vous également d’activer les déclencheurs, les index et tous les paramètres personnalisés avant de tester. Il est important de tester soigneusement votre charge de travail par rapport à la nouvelle version pour voir s’il existe des problèmes d’incompatibilité ou de performances.
  • Passez en revue les paramètres personnalisés existants à partir de la source, testez-les et configurez-les de manière appropriée dans l’environnement cible.

Coupure

Une fois les tests terminés du point de vue fonctionnel et non fonctionnel, vous êtes prêt à pointer vos applications vers le nouvel environnement de version majeure. Assurez-vous d’avoir défini un critère de réussite pour la transition avec un plan de restauration. Cet article fournit la liste de contrôle suivante comme référence; vous devez l’adapter à votre environnement. Complétez la liste de contrôle dans l’ordre suivant:

  1. Assurez-vous que tous les utilisateurs et rôles sont configurés avec les autorisations appropriées dans aurora-target.
  2. Vérifiez la correspondance des nombres d’objets de base de données (tels que les index et les fonctions) dans l’environnement source et cible. Reportez-vous à des exemples de requêtes dans le référentiel pour effectuer une comparaison d’objets.
  3. Configurez votre surveillance sur les bases de données cibles, telles que les métriques CloudWatch, pour qu’elles soient identiques à la source.
  4. Recherchez les transactions de longue durée sur la source et arrêtez-les ou terminez-les avec pg_stat_activity. Voir le code suivant:
    cd ~/environment/amazon-aurora-postgresql-upgrade/DMS
    psql -h $AURORA_SOURCE_EP -d demo -U pgadmin -f ./SourceDB/longrunningsess.sql
  5. Arrêtez toutes les applications qui écrivent dans aurora-source. C’est le point à partir duquel votre temps d’arrêt commence.
  6. Assurez-vous qu’il n’y a pas de délai de réplication AWS DMS en surveillant les métriques CloudWatch CDCLatencySource et CDCLatencyTarget.
  7. Assurez-vous qu’il n’y a aucune erreur de validation des données dans AWS DMS. Vous pouvez également vérifier le nombre de lignes pour les tables de clés à l’aide de commandes SQL.
  8. Arrêtez la tâche AWS DMS.
  9. Mettre à jour le aurora-target groupe et ensemble de paramètres de cluster session_replication_role=origin et appliquer immédiatement.
  10. Assurez-vous que les séquences (le cas échéant) sont synchronisées avec la valeur actuelle à la source en ajustant manuellement la dernière valeur. Voir le code suivant:
    select 'select setval('||quote_literal(schemaname||'.'||sequencename)||','||last_value||',true);' from pg_sequences;
  11. Modifiez votre application pour pointer vers le aurora-target point de terminaison et démarrez l’application.
  12. Effectuez les tests nécessaires pour vérifier que l’application fonctionne correctement.
  13. Activez la cible pour une utilisation en production. C’est le moment où votre temps d’arrêt s’arrête.
  14. Surveillez votre environnement cible et enregistrez les éventuels problèmes.
  15. Supprimez les tâches AWS DMS et nettoyez les ressources AWS après un test réussi.

Conclusion

Ce post a partagé des instructions étape par étape pour la migration de vos données entre Aurora et Amazon RDS pour les versions principales de PostgreSQL et des considérations clés pour votre planification et votre exécution. En tant que meilleure pratique, consultez la documentation AWS DMS, Aurora et PostgreSQL pour obtenir les dernières informations sur les mises à niveau de versions majeures. Cette publication a également fourni les modèles de code, les scripts SQL, les paramètres de tâche et les meilleures pratiques que vous pouvez utiliser pour migrer rapidement vos bases de données. Si vous avez des questions ou des commentaires à propos de cet article, veuillez partager vos réflexions dans la section des commentaires.


à propos des auteurs

Gowri Balasubramanian est un architecte principal de solutions de bases de données chez Amazon Web Services. Il travaille avec les clients AWS pour fournir des conseils et une assistance technique sur les services de bases de données relationnelles et NoSQL, les aidant à améliorer la valeur de leurs solutions lors de l’utilisation d’AWS.

Amit Bansal est consultant principal au sein de l’équipe des services professionnels chez Amazon Web Services. Il se concentre sur les migrations de bases de données vers AWS et travaille avec les clients pour concevoir et implémenter les architectures Amazon RDS, Aurora et Redshift.

HariKrishna Boorgadda est consultante principale au sein de l’équipe des services professionnels chez Amazon Web Services. Il se concentre sur les migrations de bases de données vers AWS et travaille avec les clients pour concevoir et implémenter les architectures Amazon RDS et Aurora.

Inscris-toi à notre newsletter !

Partage cet article avec tes amis !

Share on facebook
Share on google
Share on twitter
Share on linkedin