Site icon Blog ARC Optimizer

Réplication MYSQL AWS Aurora entre comptes pour les rapports financiers et la continuité des activités

Réplication MYSQL AWS Aurora entre comptes pour les rapports financiers et la continuité des activités


À l’ère numérique d’aujourd’hui, les données sont devenues l’un des actifs les plus précieux, avec une valeur qui monte en flèche en raison du recours croissant aux informations et à la prise de décision basées sur les données. Chaque fois qu’il est nécessaire de déplacer des données d’un endroit à un autre, les organisations le prennent très au sérieux. Le mouvement des données, qu’il s’agisse d’une région ou d’un compte AWS, nécessite une planification minutieuse pour garantir la sécurité, la conformité et l’efficacité opérationnelle.

Dans ce blog, nous vous guiderons pas à pas à travers le processus de configuration de la réplication entre comptes entre deux clusters Amazon Aurora MySQL dans différents comptes AWS, en tirant parti de l’appairage VPC pour une communication sécurisée. Que vous ayez besoin de répliquer des données de production à des fins de reporting ou de maintenir une redondance pour la reprise après sinistre, ce guide vous proposera une solution complète adaptée à vos besoins.

En savoir plus: Comment les organisations B2B peuvent élaborer une stratégie gagnante de gestion du cycle de vie des leads

Énoncé du problème

Une entreprise financière avait besoin de répliquer les données de sa base de données Aurora MySQL de production (dans le compte A) vers un compte AWS distinct (compte B) à des fins de reporting. L’objectif était de maintenir la redondance des données et d’assurer la continuité des activités tout en exécutant des requêtes analytiques gourmandes en ressources et en lecture seule sur la réplique du compte B sans affecter les performances de l’environnement de production. De plus, la solution devait être sécurisée, rentable et évolutive pour faire face à la croissance future.

Défis

  • Assurer la sécurité et la conformité des données lors du transfert de données financières sensibles entre comptes.
  • Réduire l’impact sur le système de production tout en permettant un reporting en temps réel dans un compte séparé.
  • Établir une connexion réseau sécurisée à faible latence entre les deux comptes AWS.
  • Automatiser la configuration pour minimiser l’intervention humaine et les erreurs potentielles, tout en facilitant la maintenance de la solution.

Solutions

La réplication entre comptes est une fonctionnalité puissante d’AWS qui permet la réplication des données entre différents comptes AWS. Dans ce blog, nous vous guiderons tout au long du processus de configuration de la réplication entre deux clusters Amazon Aurora MySQL, résidant dans deux comptes AWS différents, à l’aide de l’appairage VPC pour une mise en réseau sécurisée.

Réplication RDS

Pourquoi la réplication entre comptes ?

Notre organisation avait besoin de répliquer les données d’un cluster Aurora MySQL source dans un compte AWS vers un cluster Aurora de destination dans un autre compte AWS. Cette configuration était requise pour la redondance et pour exécuter une réplique en lecture seule à des fins de création de rapports, isolée dans un compte distinct. La contrainte imposée au pipeline de réplication était qu’il devait être sûr, rentable et évolutif en tirant parti de l’infrastructure AWS, tout en étant faible en termes de frais généraux et de maintenance.

Pour les entreprises financières, cette approche offre certains avantages très pertinents, tels que :

  • Sécurité des données : Étant donné que les informations sensibles sont conservées dans différents comptes AWS, les risques contre tout accès non autorisé sont considérablement accrus. En cas de compromission d’un compte, la segmentation du compte garantit que les informations sensibles ne sont pas perdues.
  • Contrôle des coûts : En plaçant les rapports ainsi que les opérations de lecture lourdes dans un compte AWS distinct et en laissant la production des données à un autre compte, les organisations sont en mesure de contenir l’utilisation des ressources et les dépenses.
  • Continuité des activités : La réplication entre comptes permet de garantir que les données sont récupérables même en cas de panne du système ou inaccessibles en raison de certains événements survenus dans l’environnement source.

Aperçu du processus

  1. Établissez une mise en réseau entre les comptes AWS : Configurez l’appairage de VPC entre les VPC dans les comptes AWS source et de destination.
  2. Activer la journalisation binaire dans Aurora MySQL : Activez la journalisation binaire dans le cluster Aurora MySQL source.
  3. Configurer la réplication : Créez et configurez un utilisateur de réplication et lancez le processus de réplication depuis Aurora MySQL source vers Aurora MySQL cible.
Étape 1 : Configuration du peering VPC entre deux comptes AWS

L’appairage de VPC vous permet d’acheminer le trafic entre les VPC en toute sécurité. Voici comment établir une connexion d’appairage de VPC entre les VPC de deux comptes AWS différents.

Étapes d’appairage de VPC

  1. Ouvrez la console Amazon VPC :
    • Accédez au tableau de bord VPC.
    • Dans le volet de navigation, cliquez sur Peering Connections.
  2. Créer une connexion d’appairage :
    • Choisissez Créer une connexion d’appairage.
    • Remplissez les détails :
      • Nom : vous pouvez éventuellement attribuer un nom descriptif à la connexion d’appairage.
      • ID VPC (demandeur) : sélectionnez le VPC de votre compte à partir duquel vous souhaitez créer la connexion d’appairage.
      • Compte : Choisissez un autre compte.
      • ID de compte : saisissez l’ID de compte AWS du VPC Accepter (le compte AWS cible).
      • ID VPC (accepteur) : saisissez l’ID du VPC du compte cible.
    • Cliquez sur Créer une connexion peering.
  3. Acceptez la demande de peering dans le compte cible :
    • Dans le compte AWS cible, ouvrez la console VPC.
    • Accédez à Peering Connections et vous verrez une demande de peering en attente.
    • Acceptez la demande de peering.
  4. Mettre à jour les tables de routage :
    • Une fois la connexion d’appairage établie, mettez à jour les tables de routage dans les deux VPC pour acheminer le trafic entre les deux VPC.
  5. Configurez les groupes de sécurité :
    • Assurez-vous que les groupes de sécurité des deux comptes autorisent le trafic nécessaire. Plus précisément, pour les connexions à la base de données, autorisez le port TCP 3306 (port par défaut MySQL) entre les CIDR du VPC.

Remarques importantes :

  • Les blocs CIDR des VPC des deux comptes ne doivent pas se chevaucher.
  • Assurez-vous que des règles de groupe de sécurité appropriées sont définies pour les connexions à la base de données. Par exemple, autorisez le trafic entrant sur le port 3306 dans le groupe de sécurité du VPC source pour le CIDR du VPC de destination et vice versa.
Étape 2 : Activation de la journalisation binaire dans Aurora MySQL

Par défaut, Aurora MySQL n’active pas la réplication des journaux binaires sur les instances de lecteur. Pour activer la réplication, nous devons configurer la journalisation binaire.

Étapes pour activer la journalisation binaire :

  1. Ouvrez la console Amazon RDS :
    • Accédez à la console RDS.
    • Sélectionnez votre cluster Aurora MySQL.
  2. Modifiez le groupe de paramètres du cluster :
    • Dans l’onglet Configuration, recherchez le groupe de paramètres du cluster de base de données.
    • Cliquez sur Actions du groupe de paramètres et choisissez Modifier.
  3. Modifier le format du journal binaire :
    • Recherchez le paramètre binlog_format.
    • Remplacez sa valeur par ROW (recommandé pour la réplication).

      format_binlog

  4. Enregistrer les modifications :
    • Après avoir mis à jour le paramètre, cliquez sur Enregistrer les modifications.
  5. Redémarrez l’instance de base de données principale :
    • Pour appliquer le nouveau format de journal binaire, redémarrez l’instance principale de votre cluster Aurora.

Note: La modification du format du journal binaire ne prendra effet qu’après le redémarrage de l’instance de base de données principale.

Étape 3 : Configuration de la réplication entre les clusters Aurora MySQL
  1. Configurez la conservation des journaux binaires :
    Pour garantir que les journaux binaires sont conservés suffisamment longtemps pour la réplication, augmentez la période de conservation en exécutant la commande suivante dans le cluster Aurora MySQL source : 
    CALL mysql.rds_set_configuration('binlog retention hours', 48);
  2. Créez un instantané et partagez-le :
    • Prendre un instantané :
      Dans le compte AWS source, créez un instantané du cluster Aurora MySQL à partir duquel vous souhaitez effectuer la réplication.
    • Partagez l’instantané :
      Une fois l’instantané créé, partagez-le avec le compte AWS cible. Vous pouvez le faire via la console Amazon RDS en sélectionnant l’instantané et en choisissant Partager l’instantané.
    • Restaurer l’instantané :
      Dans le compte AWS cible, restaurez l’instantané partagé pour créer un nouveau cluster Aurora MySQL.
  3. Obtenez la position de récupération après incident de Binlog :
    Une fois l’instantané restauré dans le compte cible, Aurora fournira une position de récupération après incident du journal binaire via un journal des événements. Vous aurez besoin de cette position dans le journal binaire pour configurer la réplication incrémentielle. Le message d’événement ressemblera à ceci : 
    "Message": "Binlog position from crash recovery is mysql-bin-changelog.000002 154”
  4. Créez un utilisateur de réplication dans le compte source :
    Dans le cluster Aurora MySQL source, créez un utilisateur de réplication avec les privilèges nécessaires : 
    mysql> CREATE USER 'repl_user'@'%' IDENTIFIED BY '<enter_your_password>';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
  5. Configurer la réplication dans le cluster Aurora cible :
    • Définissez le maître externe :
      Dans le cluster Aurora MySQL cible, utilisez la commande suivante pour configurer le cluster Aurora source en tant que maître externe : 
      CALL mysql.rds_set_external_master ('repl-source.cluster-xxxx.us-east-1.rds.amazonaws.com',3306,
'repl_user',
'<enter_your_password>',
'mysql-bin-changelog.000002',
154,
0
);
    • Démarrer la réplication :
      Après avoir défini le maître externe, lancez la réplication en exécutant : 
      CALL mysql.rds_start_replication;
    • Vérifiez l’état de la réplication :
      Utilisez la commande suivante pour vérifier l’état de la réplication : 
      mysql> SHOW SLAVE STATUS\G;
    • Arrêtez la réplication (si nécessaire) :
      Si jamais vous devez arrêter la réplication, utilisez cette commande : 
      CALL mysql.rds_stop_replication;

Dépannage et défis :

  • Chevauchement CIDR : Initialement, nous avons été confrontés au problème de l’interférence du bloc CIDR de deux Virtual Private Clouds, provoquant l’échec de la connexion VPC Peering. Cela nous a obligé à reconfigurer les gammes CIDR.
  • Mauvaise configuration du groupe de sécurité : Il semble qu’il y ait eu un problème avec certaines règles de sécurité des groupes de sécurité, qui a provoqué l’échec des tentatives de connexion à la base de données. Ce problème a été résolu en autorisant les connexions entrantes vers le port 3306 à partir des plages CIDR pertinentes.
  • Conservation des journaux binaires mal configurée : Dans les paramètres antérieurs, les journaux binaires étaient bloqués et purgés très rapidement, ce qui entraînait des raisons qui n’autorisaient jamais la réplication. Cela a été corrigé en augmentant le temps de rétention.

Meilleures pratiques pour la réplication entre comptes

1. Automatisation : Envisagez d’utiliser IaC pour automatiser le peering de PC, la configuration du cluster Aurora, etc. afin de minimiser les erreurs humaines et d’augmenter l’efficacité.

2. Surveillance et alertes : Assurez-vous que le processus de réplication et son état sont surveillés et que le lancement est configuré à l’aide d’AWS Cloudwatch.

3. La sécurité avant tout : N’oubliez pas d’utiliser des mécanismes de chiffrement pour les données en transit entre les comptes et même la réplication attribuée aux rôles IAM doit être basée sur le principe du moindre privilège.

Conclusion

Avec ce guide, vous pouvez facilement configurer la réplication entre comptes entre les clusters Aurora MySQL à l’aide de l’appairage de VPC : fluide, sécurisé et sans problèmes de données ! 🚀 Il s’agit de garder vos données synchronisées et vos opérations fonctionnent comme un charme.

VOUS TROUVEZ CECI UTILE ? PARTAGEZ-LE



Le meilleur outil 2023 pour ta croissance Instagram !



Source link
Quitter la version mobile