Synchronisation à  la demande

L’utilisation de la réplication pour les bases de données extrêmement volumineuses est loin d’être simple, dès lors qu’une entreprise souhaite pouvoir basculer ses opérations vers un deuxième site dans des délais très brefs. Le personnel chargé des bases de données doit être certain que les données sont synchronisées en permanence et ils ont généralement très peu de temps pour résoudre tous les problèmes survenant lors d’un sinistre.

Plusieurs scénarios possibles dans la réplication transactionnelle sont susceptibles d’entraîner une désynchronisation des données entre l’éditeur et l’abonné, ce qui peut s’avérer problématique pour l’entreprise en cas de sinistre. Par exemple, le distributeur distant (le serveur qui stocke les métadonnées et les données d’historique et conserve temporairement les transactions répliquées) peut se bloquer et, pour des raisons économiques, l’entreprise ne peut pas arrêter immédiatement l’entrée de nouvelles données sur l’éditeur (comme c’est le cas avec notre banque). L’éditeur continuera alors d’accumuler de nouvelles données et les bases de données sur celui-ci et sur l’abonné seront désynchronisées. Autre possibilité, un abonnement peut expirer, pour une raison ou une autre (par exemple, en cas de défaillance de l’agent de réplication), auquel cas les modifications sur l’éditeur ne seront pas propagées vers l’abonné.

Enfin, un utilisateur peut, par inadvertance ou intentionnellement, exécuter une commande DELETE sur l’abonné et supprimer les données déjà propagées. Dans ce cas, l’abonné aura quelques enregistrements de moins que l’éditeur. Si vous employez la réplication transactionnelle, vous avez probablement déjà rencontré au moins une fois cette situation.

Pour éviter la désynchronisation des données, la banque m’a demandé de développer un mécanisme de synchronisation des données en ligne pour le système bancaire qui réplique deux bases de données extrêmement volumineuses (d’une taille combinée de près de 500 Go) d’un serveur situé à New York vers un autre implanté dans l’Etat du Delaware, comme l’illustre la figure 1. Par ailleurs, chaque site comporte des serveurs de reporting contenant les mêmes données de reporting, à savoir un sous-ensemble des données des deux grandes bases de données. Dans les situations d’urgence, la banque doit pouvoir basculer le chargement des données du serveur de New York vers celui du Delaware et inverser le flux des données de réplication entre les deux serveurs OLTP (à savoir, du serveur du Delaware vers celui de New York). Dans le plan de réplication d’origine de la banque, une tâche planifiée s’exécute toutes les heures afin de comparer le nombre d’enregistrements dans les tables correspondantes de l’éditeur et de l’abonné.

Naturellement, l’algorithme de la tâche prend en compte la latence de livraison. Si la tâche détecte une incohérence dans les bases de données, la banque doit immédiatement synchroniser les données.

Pour accomplir cette synchronisation rapide, je ne pouvais pas me servir des techniques classiques telles que l’application de captures instantanées de réplication, la technique de sauvegarde et restauration traditionnelle, ou encore l’utilisation de DTS (Data Transformation Services). Comme une capture instantanée requiert la copie de toutes les données et non seulement de la partie dont vous avez besoin, la préparation et l’application de captures instantanées pour des bases de données volumineuses au moyen de l’Agent de capture instantanée de la console SQL Server Enteprise Manager peut prendre des heures, voire plusieurs jours et c’est un luxe que la banque ne peut pas se permettre. Celle-ci doit synchroniser uniquement les données qui ont changé depuis la dernière exécution réussie de la tâche planifiée, ce qui correspond à seulement quelques heures de nouvelles informations. La préparation d’une capture instantanée spéciale des tables concernées, lesquelles contiennent des centaines de milliers de lignes, constituerait également un gaspillage de temps et de ressources.

La technologie de sauvegarde et restauration traditionnelle serait tout aussi inefficace car elle remplacerait l’intégralité de la base de données de l’abonné par les informations de l’éditeur, ce qui serait inapproprié dans le cas du serveur de reporting. En effet, les serveurs de reporting de la banque ne contiennent qu’un sous-ensemble des tables répliquées des serveurs OLTP, avec quelques tables supplémentaires pour le reporting. Une autre raison pour laquelle je ne pouvais pas utiliser cette approche tient au fait qu’une telle restauration nécessite un accès exclusif à l’abonné. Si l’éditeur acceptait de nouvelles données pendant la restauration, Cela entraînerait une nouvelle désynchronisation immédiate des données. Mais la banque ne pouvait pas se permettre d’arrêter l’éditeur.

Nous ne pouvions pas non plus recourir à l’Assistant Importation/exportation DTS (DTS Import/Export Wizard). Ce dernier donne la possibilité d’utiliser une requête pour spécifier les données à transférer, afin de copier vers l’abonné un ensemble des données de l’éditeur. Dans ce cas, vous devez toutefois recréer les tables de destination, sinon DTS ajoute les données que vous restaurez aux tables existantes. L’ajout de lignes peut créer des doublons sur l’abonné si la requête ne définit pas exactement toutes les lignes manquantes. Par ailleurs, avec DTS, vous devez spécifier une requête pour chaque table et cette tâche peut s’avérer énorme si la synchronisation concerne de nombreuses tables. De même, la tâche peut devenir encore moins conviviale si vous avez plusieurs abonnés (ce qui est le cas de notre banque) et l’assistant doit s’exécuter plusieurs fois. Tous ces facteurs justifiaient la nécessité d’une nouvelle approche pour la banque.

C’est pourquoi j’ai élaboré et mis en oeuvre avec succès une méthode que j’ai dénommée « réplication forcée ». Cette technique permet de synchroniser les données entre des articles sélectionnés sans avoir à arrêter les opérations en ligne sur l’éditeur et les abonnés, et vous pouvez planifier la réplication forcée afin qu’elle s’exécute quand bon vous semble. Cette méthodologie peut être appliquée à n’importe quel système de base de données qui utilise la réplication transactionnelle, mais elle est tout particulièrement avantageuse pour les applications qui fonctionnent avec des bases de données volumineuses (100 Go ou supérieures) et qui nécessiteraient trop de temps pour la synchronisation des données au moyen de captures d’instantanés ou d’autres méthodes de sauvegarde et restauration.