+++
title = "Configuration de la base de données source"
weight = 25
+++
### Exécution de la réplication DMS avec le Change Data Capture (CDC)
Afin de minimiser l'interruption de service durant la migration de la base de données, nous allons utiliser la réplication continue des changements (nommé **Change Data Capture (CDC)**) à partir de la base de données source vers la base de données cible. Pour plus d'information à propos de CDC et le support natif de CDC de **AWS DMS** consultez cet article.
#### Activez les log sur la base de données source
Pour la réplication continue de **AWS DMS** à partir d'une base de données MySQL, vous devez activer les logs et effectuer un changement de configuration sur la base de données source.
1. Connectez vous sur le server **Base de données source**
Pour **le lab réalisé de manière indépendante** - les informations nécessaires pour accéder à l'environnement base de données sont décrites dans la section **Output** du "Template" **ApplicationMigrationWorkshop** CloudFormation.
Pour **Le lab réalisé lors d'un évènement organisé par AWS** - les informations nécessaires pour accéder à l'environnement base de données sont décrites dans **Database IP**, **Database Username** et **Database SSH Key** sur leTableau de bord d'équipe (Team Dashboard).
Si vous ne savez pas comment utiliser une clé SSH pour accéder à un serveur, consultez les liens suivants :
- Pour les utilisateurs Micrisift Windows consultez cet article.
- Pour les utilisateurs Mac OS consulmtez cet article.
2. Ajouter des privilègesà l'utilisateur de base de données **wordpress-user**
Exécutez les commandes suivantes sur le serveur de base de données :
```
sudo mysql -u root -pAWSRocksSince2006
GRANT REPLICATION CLIENT ON *.* to 'wordpress-user';
GRANT REPLICATION SLAVE ON *.* to 'wordpress-user';
GRANT SUPER ON *.* to 'wordpress-user';
exit
```
3. Créez un répertoire pour les **bin logs**
Exécutez les commandes suivantes sur le serveur de base de données :
```
sudo su -
mkdir /var/lib/mysql/binlogs
chown -R mysql:mysql /var/lib/mysql/binlogs
exit
```
Vous pouvez trouver plus d'informations sur les log dans la documentation MySQL.
4. Créer et modifier le fichier **/etc/mysql/my.cnf**
Exécutez les commandes suivantes pour éditer le fichier :
```
sudo su -
cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/my.cnf
chown -R mysql:mysql /etc/mysql/my.cnf
nano /etc/mysql/my.cnf
```
Enfin, ajoutez les informations suivantes sous la section **[mysqld]**, sauvegardez le fichier et quittez nano :
```
server_id=1
log-bin=/var/lib/mysql/binlogs/log
binlog_format=ROW
expire_logs_days=1
binlog_checksum=NONE
binlog_row_image=FULL
log_slave_updates=TRUE
performance_schema=ON
```
5. **Redémarrez** le service MySQL pour predre en compte les changements
De retour sur la console, exécutez la commande suivante pour prendre en compte les changements :
```
sudo service mysql restart
```
{{% notice warning %}}
L'application de ces changememnts requiert un redémarrage du service MySQL. Ceci va interrompre le service de base de données source pour quelques secondes.
{{% /notice %}}
1. **Testez** les changements
Assurez-vous que la mise à jour dans **/etc/mysql/my.cnf** a pris effet, en exécutant les commandes suivantes :
```
sudo mysql -u root -pAWSRocksSince2006
select variable_value as "BINARY LOGGING STATUS (log-bin) :: "
from performance_schema.global_variables where variable_name='log_bin';
select variable_value as "BINARY LOG FORMAT (binlog_format) :: "
from performance_schema.global_variables where variable_name='binlog_format';
exit
```
Le résultat doit montrer le **BINARY LOGGIN STATUS** positionné à **ON**, comme dans la copie d'écran suivante :
Si c'est le cas, vous pouvez **quitter** SSH, en cas de problème - vérifiez le fichier **/var/log/mysqld.log** pour les erreurs.