SQL Server, Tutoriel de réplication de bases de données

Ce programme met en exergue les différentes fonctions logicielles natives incluses dans SQL Server 2008, ainsi qu’une liste de fournisseurs de matériels qui se conforment aux exigences de stockage spécifiques. Microsoft n’a pas cessé d’améliorer SQL Server au fil du temps afin de renforcer sa résilience.

Tutoriel de réplication de bases de données

Bien qu’elle vienne souvent en dernier sur la liste des problèmes de base de données à traiter, l’évolutivité doit constituer votre priorité numéro un.

Pouvez-vous vous permettre d’évoluer avec une base de données centralisée ou devez-vous envisager d’emblée une approche étroitement intégrée, mais géographiquement disséminée ? Existe-t-il une conception qui unifie l’évolutivité, la reprise après sinistre et la haute disponibilité au sein d’une stratégie unique de résilience de base de données ? En cas de réponse affirmative, la solution s’appuiera très vraisemblablement sur une des approches sans partage (share nothing) unifiée disponibles. Les plus populaires d’entre elles sont la réplication P2P (peer-to-peer) et la solution GridScale de xkoto Inc.

La réplication a été introduite en 1995 avec SQL Server 6.0 et, ces 16 dernières années, elle n’a cessé de s’améliorer. Depuis le début, la réplication était censée résoudre la problématique des défaillances de volumes, qu’ils soient locaux ou disséminés géographiquement. En général, les tables supportant des charges d’utilisateurs élevées peuvent être publiées vers plusieurs emplacements disséminés pour un accès en lecture seule. Les modifications, qui interviennent moins fréquemment, peuvent être gérées dans une base de données de publication centralisée.

Mais cette approche de publication ne résout que partiellement vos problèmes d’évolutivité. Toutes les modifications des données restent centralisées. Par ailleurs, il faut encore résoudre les problèmes de reprise après sinistre et de haute disponibilité pour la base de données de publication centralisée.

La réplication propose une approche permettant de traiter non seulement vos problèmes d’évolutivité, mais aussi la reprise après sinistre et la haute disponibilité. Grâce à la réplication P2P, vous pouvez configurer plusieurs bases de données géographiquement dispersées, qui mettent en place des sites de base de données pleinement redondants. La complexité constitue le principal frein à cette solution. Alors que la majorité des approches de reprise après sinistre et de haute disponibilité résident au niveau base de données ou serveur, la réplication utilise une granularité au niveau table. Cette solution est tout à fait indiquée lorsque vous publiez uniquement une sélection de tables fortement utilisées pour résoudre les problèmes de défaillances de volumes. Malheureusement, la réplication P2P en tant que solution de reprise après incident/haute disponibilité complète est nettement trop complexe. Néanmoins, elle peut constituer la solution idéale pour certaines applications.

L’évolutivité horizontale (scale out) de serveurs Web au moyen de mécanismes d’équilibrage de charge est devenue une tâche relativement courante. Mais cette solution est-elle viable pour les bases de données ? La base de données ne demande qu’une chose : être centralisée. Même la conception RAC (Real Application Cluster) particulièrement respectée d’Oracle a toujours besoin d’une base de données centralisée derrière tous les nœuds RAC. Toutefois, la donne a complètement changé avec la sortie par xkoto de GridScale pour DB2, puis pour SQL Server il y a quelques années.

GridScale combine efficacement l’équilibrage de la charge et la réplication P2P, et s’intercale entre l’application et la base de données. Les lectures de base de données (select) sont dirigées vers le serveur de base de données identifié comme ayant la charge la moins élevée. D’un autre côté, les requêtes de modification (insert/update/delete) sont coordonnées et gérées sur tous les serveurs de base de données du groupe. Il en résulte une configuration parallèle fournissant le potentiel d’un système à tolérance de panne et hautement évolutif, géographiquement disséminé. Chaque système indépendant fournit la haute disponibilité et la reprise après sinistre pour les autres. Par ailleurs, à la différence de la réplication, la gestion s’effectue au niveau base de données.