Comment puis-je utiliser AWS DMS pour migrer depuis une instance de base de données Amazon RDS exécutant SQL Server ?

Date de la dernière mise à jour : 26/09/2019

Comment puis-je utiliser AWS Database Migration Service (AWS DMS) pour migrer depuis une instance de base de données Amazon Relational Database Service (Amazon RDS) exécutant SQL Server ?

Brève description

Vous pouvez migrer les données d'une ou plusieurs instances de base de données SQL Server à l'aide d'AWS DMS vers n'importe quel moteur de base de données cible pris en charge.

Dans un premier temps, servez-vous de l'utilisateur principal de l'instance RDS SQL Server pour configurer la base de données et les tables. Ensuite, créez votre point de terminaison source à l'aide de la console AWS DMS ou de l'interface de ligne de commande AWS (AWS CLI).

Pour plus d'informations sur la façon dont SQL Server utilise la capture des données modifiées (CDC) ainsi que les conditions préalables et les conditions requises pour utiliser la réplication continue avec les instances de base de données SQL Server, consultez Utilisation de la réplication continue (CDC) depuis une source SQL Server.

Résolution

AWS DMS propose deux méthodes de capture des modifications en cours: MS-Replication et MS-CDC.

Remarque : les instances Amazon RDS qui exécutent SQL Server comme source doivent utiliser MS-CDC car Amazon RDS ne prend pas en charge les privilèges Sysadmin.

Exécutez la commande suivante à l'aide de l'utilisateur principal pour activer MS-CDC au niveau de la base de données :

EXEC msdb.dbo.rds_cdc_enable_db 'DBName';
GO

Exécutez ensuite la commande suivante pour chaque table afin d'activer la CDC au niveau de la table :

EXECUTE sys.sp_cdc_enable_table @source_schema = N'SchemaName', @source_name =N'TableName', @role_name = NULL;
GO

Exécutez ensuite la commande suivante pour augmenter la période de conservation des transactions dans le T-Log :

EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 3599;
GO

Lors de la configuration de la réplication continue pour une instance SQL Server, il est recommandé de définir le « pollinginterval »(intervalle d'interrogation) pour conserver les modifications pendant une journée (86 400 secondes). Cependant, certaines versions de SQL Server ont un problème connu. Par conséquent, si la valeur du « pollinginterval »(intervalle d'interrogation) est définie sur plus de 3599 secondes, la valeur est réinitialisée à la valeur par défaut, qui est de cinq secondes. Dans ce cas, les entrées T-Log sont purgées avant qu'AWS DMS les lise. Pour voir quelles versions sont encore affectées par ce problème, consultez la documentation Microsoft suivante : « Incorrect results occur when you convert "pollinginterval" parameter from seconds to hours in sys.sp_cdc_scan in SQL Server » (Des résultats incorrects se produisent lorsque vous convertissez le paramètre « pollinginterval » (intervalle d'interrogation) de secondes en heures dans sys.sp_cdc_scan dans SQL Server.)

Une fois que vous avez créé une tâche AWS DMS, vous pouvez surveiller l'état de votre tâche de migration. Si vous arrêtez la tâche et que vous la reprenez au bout d'une heure, elle peut échouer car le journal T-Log a été tronqué et AWS DMS ne dispose pas des numéros de séquence de journal (LSN) requis en raison du problème mentionné précédemment. Pour éviter cela, procédez comme suit :

1.    Arrêtez la tâche de capture :

use [DBName]
exec sys.sp_cdc_stop_job;

2.    Arrêtez la tâche AWS DMS et attendez que toutes les activités restantes s'arrêtent.

3.    Reprenez la tâche DMS et attendez qu'elle se synchronise en surveillant la latence source de la tâche AWS DMS.

4.    Redémarrez la tâche de capture :

use [DBName]
exec sys.sp_cdc_start_job;

Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?