> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
> Guide pas à pas pour configurer Amazon Aurora MySQL comme source pour ClickPipes
# Guide de configuration de la source Aurora MySQL
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
Ce guide pas à pas explique comment configurer Amazon Aurora MySQL pour répliquer des données dans ClickHouse Cloud à l’aide de [MySQL ClickPipe](/docs/fr/integrations/clickpipes/mysql/index). Pour les questions fréquentes sur MySQL CDC, consultez la [page FAQ MySQL](/docs/fr/integrations/clickpipes/mysql/faq).
## Activer la rétention du journal binaire
Le journal binaire est un ensemble de fichiers de log contenant des informations sur les modifications de données apportées à une instance de serveur MySQL, et les fichiers de journal binaire sont requis pour la réplication. Pour configurer la rétention du journal binaire dans Aurora MySQL, vous devez [activer la journalisation binaire](#enable-binlog-logging) et [augmenter l’intervalle de rétention du binlog](#binlog-retention-interval).
La fonctionnalité de sauvegardes automatisées détermine si la journalisation binaire est activée ou désactivée pour MySQL. Les sauvegardes automatisées peuvent être configurées pour votre instance dans la RDS Console en accédant à **Modify** > **Additional configuration** > **Backup** et en cochant la case **Enable automated backups** (si elle n’est pas déjà cochée).
Nous recommandons de définir la **Backup retention period** sur une valeur suffisamment longue, en fonction du cas d’usage de la réplication.
Si ClickPipes tente de reprendre la réplication et que les fichiers de binlog requis ont été purgés en raison de la valeur de rétention du binlog configurée, le ClickPipe passera en état d’erreur et une resynchronisation sera nécessaire.
Par défaut, Aurora MySQL purge le journal binaire dès que possible (c.-à-d. avec une *purge différée*). Nous recommandons d’augmenter l’intervalle de rétention du binlog à au moins **72 heures** afin de garantir la disponibilité des fichiers de binlog pour la réplication en cas de défaillance. Pour définir un intervalle de rétention du journal binaire ([`binlog retention hours`](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/mysql-stored-proc-configuring.html#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)), utilisez la procédure [`mysql.rds_set_configuration`](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/mysql-stored-proc-configuring.html#mysql_rds_set_configuration) :
[//]: # "REMARQUE La plupart des fournisseurs de CDC recommandent la durée de rétention maximale pour Aurora RDS (7 jours/168 heures). Comme cela a un impact sur l’utilisation du disque, nous recommandons, par précaution, un minimum de 3 jours/72 heures."
```text theme={null}
mysql=> call mysql.rds_set_configuration('binlog retention hours', 72);
```
Si cette configuration n'est pas définie ou si l'intervalle est trop court, cela peut entraîner des trous dans les logs binaires et compromettre la capacité de ClickPipes à reprendre la réplication.
## Configurer les paramètres du binlog
Vous trouverez le groupe de paramètres en cliquant sur votre instance MySQL dans la RDS Console, puis en accédant à l’onglet **Configuration**.
Si vous avez un cluster MySQL, les paramètres ci-dessous se trouvent dans le groupe de paramètres du [cluster DB](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.CreatingCluster.html) plutôt que dans le groupe de l’instance DB.
Cliquez sur le lien du groupe de paramètres pour accéder à sa page dédiée. Vous devriez voir un bouton **Edit** en haut à droite.
Les paramètres suivants doivent être définis comme suit :
1. `binlog_format` sur `ROW`.
2. `binlog_row_metadata` sur `FULL`.
3. `binlog_row_image` sur `FULL`.
Ensuite, cliquez sur **Save Changes** dans l’angle supérieur droit. Vous devrez peut-être redémarrer votre instance pour que les modifications prennent effet. Vous le saurez si `Pending reboot` apparaît à côté du lien du groupe de paramètres dans l’onglet **Configuration** de l’instance Aurora.
## Activer le mode GTID (recommandé)
MySQL ClickPipe prend également en charge la réplication sans mode GTID. Cependant, l’activation du mode GTID est recommandée pour de meilleures performances et un dépannage plus simple.
Les [Global Transaction Identifiers (GTIDs)](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html) sont des identifiants uniques attribués à chaque transaction validée dans MySQL. Ils simplifient la réplication du binlog et facilitent le dépannage. Nous **recommandons** d’activer le mode GTID afin que MySQL ClickPipe puisse utiliser la réplication basée sur GTID.
La réplication basée sur GTID est prise en charge pour Amazon Aurora MySQL v2 (MySQL 5.7) et v3 (MySQL 8.0), ainsi que pour Aurora Serverless v2. Pour activer le mode GTID sur votre instance Aurora MySQL, suivez ces étapes :
1. Dans la RDS Console, cliquez sur votre instance MySQL.
2. Cliquez sur l’onglet **Configuration**.
3. Cliquez sur le lien du groupe de paramètres.
4. Cliquez sur le bouton **Edit** dans le coin supérieur droit.
5. Définissez `enforce_gtid_consistency` sur `ON`.
6. Définissez `gtid-mode` sur `ON`.
7. Cliquez sur **Save Changes** dans le coin supérieur droit.
8. Redémarrez votre instance pour appliquer les modifications.
## Configurer un utilisateur de base de données
Connectez-vous à votre instance Aurora MySQL en tant qu'utilisateur admin, puis exécutez les commandes suivantes :
1. Créez un utilisateur dédié pour ClickPipes :
```sql theme={null}
CREATE USER 'clickpipes_user'@'%' IDENTIFIED BY 'some-password';
```
2. Accordez des autorisations sur le schéma. L'exemple suivant montre les autorisations pour la base de données `mysql`. Répétez ces commandes pour chaque base de données et chaque hôte que vous souhaitez répliquer :
```sql theme={null}
GRANT SELECT ON `mysql`.* TO 'clickpipes_user'@'host';
```
3. Accordez à l'utilisateur les autorisations de réplication :
```sql theme={null}
GRANT REPLICATION CLIENT ON *.* TO 'clickpipes_user'@'%';
GRANT REPLICATION SLAVE ON *.* TO 'clickpipes_user'@'%';
```
### Utilisation de l’authentification IAM (facultatif)
Au lieu d’un mot de passe, vous pouvez authentifier l’utilisateur ClickPipes à l’aide du contrôle d’accès basé sur les rôles d’AWS IAM. Créez l’utilisateur comme suit, puis accordez-lui les mêmes privilèges de schéma et de réplication que ceux indiqués ci-dessus :
```sql theme={null}
CREATE USER 'clickpipes_iam_user' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
Voir [AWS IAM DB authentication (RDS/Aurora)](/docs/fr/integrations/clickpipes/postgres/auth) pour suivre les étapes complètes de configuration du rôle IAM et de la politique requis afin que ClickPipes puisse s’authentifier de cette manière.
## Configurer l’accès au réseau
### Contrôle d’accès par adresse IP
Pour limiter le trafic vers votre instance Aurora MySQL, ajoutez les [adresses IP NAT statiques documentées](/docs/fr/integrations/clickpipes/home#list-of-static-ips) aux **Inbound rules** de votre groupe de sécurité Aurora.
### Accès privé via AWS PrivateLink
Pour vous connecter à votre instance Aurora MySQL via un réseau privé, vous pouvez utiliser AWS PrivateLink. Suivez le [guide de configuration d’AWS PrivateLink pour ClickPipes](/docs/fr/resources/support-center/knowledge-base/cloud-services/aws-privatelink-setup-for-clickpipes) pour mettre en place la connexion.
## Et ensuite ?
Maintenant que votre instance Amazon Aurora MySQL est configurée pour la réplication via binlog et qu’elle établit une connexion sécurisée à ClickHouse Cloud, vous pouvez [créer votre premier MySQL ClickPipe](/docs/fr/integrations/clickpipes/mysql/index#create-your-clickpipe). Pour les questions fréquentes sur MySQL CDC, consultez la [page FAQ MySQL](/docs/fr/integrations/clickpipes/mysql/faq).