Discussion :

[Providence0]

Hello à tous,
je pense que j'ai un peu de mal à assimilé les objectifs des différentes méthodes de réplication :

D'après ce que j'ai compris :

Miroir : méthode de réplication permettant de copier une base de donnée vers une autre (méthode déprécié, où on favorise la méthode Always ON de nos jours), par contre je ne vois pas à quoi sert le témoin.

Always ON : Haute disponibilité il joue plusieurs rôle dont la répartition de charge (load balancer), la réplication (comme le mirroir) et le fail over (si la machine primaire ne marche plus, on peut basculer sur la 2ème machine), par contre pour utiliser le Always ON, il faut que les windows server soient en cluster (wsfc) et il n'est apparu que dans les versions SQL Server récente (de souvenir à partir de la Version 12).

Réplication Transactionnel : D'après mes tests et de ce qui m'avait été dit (si j'ai bien compris) c'est que ça pouvait nous permettre de faire des réplications de bases mais également de tables seulement. (au lieu de copier toute la base), mais son utilité reste très flou.

Réplication 2 ways : Pas encore eu l'occassion de bien le tester, mais d'après ce que j'ai compris on peut faire des transactions sur les 2 machines (et si on le peut, il serait assez intéressant vu qu' la différence du Always ON on ne peut que lire sur la machine secondaire), mais j'ai également remarqué qu'il y a des contraintes sur les versions (de souvenir une des 2 versions ne pouvait pas être plus récente que l'autre).


PS : n'hésitez pas à me corriger si je dis une connerie :p

[SQLpro]

Hello à tous,
je pense que j'ai un peu de mal à assimilé les objectifs des différentes méthodes de réplication :

Encore une fois ne parlons pas de réplication, mais de haute disponibilité ou de migration. La réplication dans MS SQL Server c'est le fait de récupérer certaines données de certaines tables d'une base A sur une serveur S1 pour les y porter dans une base B d'un serveur S2, peut importe la structure de la base.... ELle ne concerne donc pas du tout l'intégralité de la base !

D'après ce que j'ai compris :

Miroir : méthode de réplication permettant de copier une base de donnée vers une autre (méthode déprécié, où on favorise la méthode Always ON de nos jours), par contre je ne vois pas à quoi sert le témoin.

Encore une fois cela n'est pas une réplication mais une duplication. La base miroir est un clone parfait de la base source, binairement identique (à un chouia près). Elle reste en vigueur dans les versione antérieuree à la 12 et dans les éditions standard jusqu'à la 2014.
Le témoin sert à éviter le syndrome du "split brain" et sert de quorum afin de déterminer la situation de la base survivante en cas de crash. Sans ce témoin, le basculement automatique n'est pas possible, car les deux bases pourrait se retrouver opérationnelles au même moment et donc des utilisateurs alimenter pour certain l'une et pour les autres la seconde !

Always ON : Haute disponibilité il joue plusieurs rôle dont la répartition de charge (load balancer), la réplication (comme le mirroir) et le fail over (si la machine primaire ne marche plus, on peut basculer sur la 2ème machine), par contre pour utiliser le Always ON, il faut que les windows server soient en cluster (wsfc) et il n'est apparu que dans les versions SQL Server récente (de souvenir à partir de la Version 12).

Comme les base dupliquées sont en lecture seule, la possibilité de répartition de charge n'est possible que si les clients ne font que de la lecture.

Réplication Transactionnel : D'après mes tests et de ce qui m'avait été dit (si j'ai bien compris) c'est que ça pouvait nous permettre de faire des réplications de bases mais également de tables seulement. (au lieu de copier toute la base), mais son utilité reste très flou.

Bien qu'il puisse être utiliser pour dupliquer l'intégralité d'une base c'est un non sens que d'utiliser la réplication de données pour ce faire, les ressources mobilisé&es et la complexité de la mise en œuvre, conduit généralement à la catastrophe. C'est pourquoi le mirroring ou AlwaysOn on été inventés !
La réplication de données, sert essentiellement à la répartition de charge. Voici un exemple. Un grand site web marchand (fnac.com, pour le pas la nommer possède 2 séries de machines SQL Server l'une assurant le front office (site web, 8 machines) et l'autre le back office (stock, expédition - 4 machines). Les données, commune sont les produits et les clients. En revanche, les commentaires, liste d'envie reste sur le FO, le paiement, les bons de livraison, le routage et le stocke reste sur le BO. Comme tu le voit les bases ne sont pas identiques... Différentes flux de réplication (horizontaux et verticaux) sont mis en œuvre pour orchestrer le tout à des intervalles réguliers :

• Les INSERT.UPDATE client du FO vers le BO toutes les 5 minutes
• Les commentaires entre les différentes FO toutes les heures
• Les produit du BO vers le FO à midi et minuit

.

Réplication 2 ways : Pas encore eu l'occassion de bien le tester, mais d'après ce que j'ai compris on peut faire des transactions sur les 2 machines (et si on le peut, il serait assez intéressant vu qu' la différence du Always ON on ne peut que lire sur la machine secondaire), mais j'ai également remarqué qu'il y a des contraintes sur les versions (de souvenir une des 2 versions ne pouvait pas être plus récente que l'autre).

Attention ce mode de réplication engendre systématiquement des conflits de réplication qu'il faut traiter soit par du code métier soit à la main...

PS : n'hésitez pas à me corriger si je dis une connerie :p

C'est fait !

[Providence0]

Merci pour votre réponse rapide, c'est vraiment cool


Il y a encore un point qui me perturbe :

Je pensais que la réplication de donnée ne pouvait pas faire une fusion des modifications (ou du moins avait du mal)

Mais dans votre exemple : on fait une répartition de charge (grâce aux réplications) et on migre les commentaires toutes les heures entre les différentes machines FO, du coup cela signifie qu'on peut lire et écrire sur les différentes machines FO et fusionner nos données?

[SQLpro]

La réplication des données utilise différents modes qui sont adaptés à différentes situations (snapshot, transactionnelle, fusion...). Peu importe la topologie.
Dans le cas cité, les clients ne figurent que sur 1 seul serveur afin de répartir la charge. Ainsi M. Paul Bismuth sera par exemple stocké sur le serveur F0 5 et sur aucun autre. Sur chaque serveur du FO, figurent donc des personnes uniques réparties sur le nombre de nœuds. Si Paul Bismuth poste un commentaire, ce dernier va être répliqué sur les 7 autres nœuds avec son pseudonyme (mettons "sarko"...). Il n'y a donc jamais de situation de fusion (mise à jour de la même ligne par deux nœuds différents).
Dans ce cas on peut utiliser la réplication transactionnelle... Seule méthode apte à garantir l'intégrité de la base.

A +

[Providence0]

Je vois, c'est assez clair.
Merci