Discussion :

[dari68]

Bonjour,

J'ai un serveur avec une centaines de bases que je veux répliquer tous les jours ou toutes les semaines sur un autre site, alors je me demande si je me pencher sur la réplication transactionnelle ? Mirroring ? AlwaysOn ?

Merci.

@+

[SQLpro]

La réplication transactionnelle est une réplication de données et c'est fait pour du fonctionnel (envoyer certaines données de certaines tables à certaines autres bases de différents serveurs).
Ce que vous voulez c'est sans doute de la haute dispo, c'est à dire qu'un serveur de secours puisse reprendre la marche des applications en cas de défaillance majeur d'une des bases ou du serveur, je me trompe ?
Dans ce cas 4 solutions :
1) log shipping, simple à mettre en œuvre, base par base, mais pas de basculement automatique et totalement asynchrone. Latence élevée (au moins quelques minutes), autant de serveur de secours que vous désirez.
2) cluster Windows, complexe à mettre en œuvre, basculement automatique de l'instance, latence minimale de 30 secondes à quelques minutes, mode synchrone, jusqu'à 8 nœuds (serveurs de secours). Nécessite en sus une réplication physique au niveau hardware des IO sur la baie de disque partagée, pas de lecture sur les secours.
3) Mirroring (deprecated depuis la version 2012) : mise en œuvre simple à moyenne, base par base, basculement manuel ou automatique, pas de latence si mode automatique, mode synchrone ou asynchrone. Pas de lecture sur les secours.
4) AlwaysOn (apparu à partir de la version 2012) : mise en œuvre simple à moyennement dure, par groupe de bases de données, basculement manuel ou automatique, pas de latence si mode automatique, mode synchrone ou asynchrone, plusieurs serveurs de secours possible, lectures possible sur les secours et sauvegarde possible sur les secours.

A +

[SQLpro]

Mise à part pour le log shipping ou c'est vous qui décidez du moment ou vous capturez les informations nouvelles et du moment ou vous les ré-appliquées, tous les autres modes fonctionnent en continu (envoi automatique par SQL Server des transactions par communication à l'aide de Web Services internes, sauf pour le clustering qui ne fait que partager les fichiers des bases entre les nœuds.

A +

[dari68]

Bonjour et Merci de vos retours.

Le besoin est pouvoir travailler sur les données fraiches de la production de la vieille en lecture.

Merci

@+

[SQLpro]

Dans ce cas un simple backup restore devrait suffire. Les sauvegardes SQL Server sont très rapides en mode compressées, idem pour la restauration. Quelle volumétrie avez vous ?

Pouvez vous nous renvoyer le contenu de cette requête ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ROUND(SUM(size) * 8 / 1048576.0, 3) AS TOTAL_GB
FROM   sys.master_files
WHERE  database_id > 4

Cela donne la volumétrie globale de vos bases de prod

Si en sus vous voulez les données à une date exacte (par exemple minuit au plus tard) vous pouvez utiliser des journaux de transactions avec un STOPAT (PITR)


A +

[dari68]

Ce sont des petites bases => 21.743000000 GB , ma contrainte c'est qu'il y a une centaine de bases à restaurer.

Merci.

@+

[SQLpro]

Un script générique SQL de part et d'autre fera l'affaire.

Exemple, sauvegarder toutes les bases vers une destination en variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
DECLARE @PATH_DEST VARCHAR(256) = 'C:\DATABASES\BACKUPS\'
DECLARE @SQL NVARCHAR(max) = N''
SELECT @SQL = @SQL + N'BACKUP DATABASE [' + name + N'] TO DISK = ''' 
            + @PATH_DEST + name + N'_' 
            + REPLACE(CONVERT(CHAR(19), GETDATE(), 126), ':', '-')
            + N'.BAK'' WITH COMPRESSION;'
FROM   sys.databases
WHERE name NOT IN ('master', 'msdb', 'model', 'tempdb')
 AND  name NOT LIKE 'ReportServer$%'
 AND  source_database_id IS NULL
 AND  state = 0;
EXEC (@SQL);

A +

[dari68]

Bonjour et Merci.

J'ai fait un test sur une base: j'ai arrêté mes 2 instances puis j'ai copié les fichiers (data et log) d'une base de la 1ere instance sur la 2ème instance puis j'ai redémarré mes instances

La base a bien démarré sur la 2ème instance avec les dernières modifications.

Je ne sais pas si cette méthode est fiable tout le temps ou pas ?

Merci.

@+

[SQLpro]

Bonjour et Merci.

J'ai fait un test sur une base: j'ai arrêté mes 2 instances puis j'ai copié les fichiers (data et log) d'une base de la 1ere instance sur la 2ème instance puis j'ai redémarré mes instances

La base a bien démarré sur la 2ème instance avec les dernières modifications.

Je ne sais pas si cette méthode est fiable tout le temps ou pas ?

Merci.

@+

Non, cette méthode est stupide.

En effet l'arrêt d'une instance fait perdre des éléments primordiaux pour les performances et le diagnostic, et ne doit être utilisé qu'en dernier recours :
1) vous perdez la mise en cache des données
2) vous perdez la mise en cache des plans de requête
3) vous perdez les statistiques d'exécution de SQL Server qui permette de diagnostiquer et d'auto améliorer le système.

Essayez d'imaginer un instant que pour demandez une analyse de sang à un patient, vous décidez de lui faire arrêter le cœur !
Toute les opérations dans un SGBDR de type C/S doivent être faites à chaud !

Il serait grand temps de vous former !!!!

Notre livre peut vous y aider, mais je vous conseillerais un e des formations que nous donnons à Orsys !

A +

[dari68]

Bonjour,

Ok, Merci de ces infos.

Est-ce que vous auriez la procédure de restauration des bases qui va avec votre procédure de sauvegarde ci-dessus ?

Merci.

@+

[julien94320]

Bonjour,

Il vous suffit de faire une restauration depuis votre fichier de backup :

Voici un peu d'aide :

https://msdn.microsoft.com/fr-fr/library/ms186858.aspx

https://msdn.microsoft.com/fr-fr/library/ms177429.aspx

https://www.developpez.net/forums/d6...base-sous-nom/

[Fabien Celaia]

Ouff... ces dénominations marketing commencent sérieusement à me gonfler...
Les experts, corrigez-moi si je me plante...

Au niveau de la Haute dispo de SQL Server 2016, en gros, il y a 3 options, si j'ai bien saisi

1) Always-On Failover Cluster Instances = FCI

En gros, c'est un cluster Windows actif / actif sur lequel reposent des instances MSSQL actif/passif comme on le connaissait en v.2000. Il nécessite un espace de stockage partagé car toutes les instances doivent pouvoir y accéder.... mais une seule à la fois... Donc en cas de crash, il y a déni de service entre la libération des ressources de l'instance actif et le basculement sur la seconde. Question : dans le cas de noeuds plus nombreux que 2.... à quoi ca sert ? il ne peux a avoir une base de donnée active que sur un noeud à la fois, non ?

2) Always-On Availability Group = AG

Modifications des données via log shipping... c'est donc une réplication transactionnelle follow the flow déguisée...
Pour le fun, il y a des groupes dans lesquels on peut ajouter des bases pour que l'administration soit plus simple, mais architecturalement parlant, il y a 2 bases qui s'échangent de la donnée. Et je ne sais pas si c'est bi-directionnel ou si une base est en RW et l'autre en RO.


3) Basic Availability Group = BAG = version bridée de AG

Avantage : supporté en version std
Désavantage : limité à 2 noeuds, mais surtout à une database (donc hors course pour moi)

[SQLpro]

Au niveau de la Haute dispo de SQL Server 2016, en gros, il y a 3 options, si j'ai bien saisi

Oui, mais pas celle que tu cites...

1) Always-On Failover Cluster Instances = FCI

En gros, c'est un cluster Windows actif / actif sur lequel reposent des instances MSSQL actif/passif comme on le connaissait en v.2000. Il nécessite un espace de stockage partagé car toutes les instances doivent pouvoir y accéder.... mais une seule à la fois... Donc en cas de crash, il y a déni de service entre la libération des ressources de l'instance actif et le basculement sur la seconde. Question : dans le cas de noeuds plus nombreux que 2.... à quoi ca sert ? il ne peux a avoir une base de donnée active que sur un noeud à la fois, non ?

Non... Il n'y a pas de cluster réellement actif/actif dans SQL Server dans le sens ou pour la haute dispo avec AlwaysOn, aucun nœud ne peut avoir le même base active à deux points différent. Une seule base est toujours productive, les autres sont en lecture, certaines, synchrone d'autres asynchrones. AlwaysOn n'a pas d'espace de stockage partagé, les données sont répliquées via un transport HTTP des binaires du JT vers les esclaves.

2) Always-On Availability Group = AG

Modifications des données via log shipping... c'est donc une réplication transactionnelle follow the flow déguisée...
Pour le fun, il y a des groupes dans lesquels on peut ajouter des bases pour que l'administration soit plus simple, mais architecturalement parlant, il y a 2 bases qui s'échangent de la donnée. Et je ne sais pas si c'est bi-directionnel ou si une base est en RW et l'autre en RO.

Pas du tout. Le log Shipping reste le Log Shipping et c'est une autre technologie qui reste encore en vigueur.

3) Basic Availability Group = BAG = version bridée de AG

Avantage : supporté en version std
Désavantage : limité à 2 noeuds, mais surtout à une database (donc hors course pour moi)

C'est simplement le fait que dans la version standard le ALwaysOn est limité à :
1) un groupe de disponibilité n'incluant qu'une seule base
2) un seul réplica en destination.

A +

PS : je vais croire qu'à force de faire du MySQmerde tu deviens largué mon pauvre fadace !!!!

[Fabien Celaia]

1) Always-On Failover Cluster Instances = FCI

En gros, c'est un cluster Windows actif / actif sur lequel reposent des instances MSSQL actif/passif comme on le connaissait en v.2000. Il nécessite un espace de stockage partagé car toutes les instances doivent pouvoir y accéder.... mais une seule à la fois... Donc en cas de crash, il y a déni de service entre la libération des ressources de l'instance actif et le basculement sur la seconde. Question : dans le cas de noeuds plus nombreux que 2.... à quoi ca sert ? il ne peux a avoir une base de donnée active que sur un noeud à la fois, non ?

Non... Il n'y a pas de cluster réellement actif/actif dans SQL Server dans le sens ou pour la haute dispo avec AlwaysOn, aucun nœud ne peut avoir le même base active à deux points différent. Une seule base est toujours productive, les autres sont en lecture, certaines, synchrone d'autres asynchrones. AlwaysOn n'a pas d'espace de stockage partagé, les données sont répliquées via un transport HTTP des binaires du JT vers les esclaves.

Ben... je dis la même chose : cluster OS A/A, cluster SQL A/P ! et quid du reste de ma question ?
Question : dans le cas de noeuds plus nombreux que 2.... à quoi ca sert ? il ne peux a avoir une base de donnée active que sur un noeud à la fois, non ?

[SQLpro]

Ben... je dis la même chose : cluster OS A/A, cluster SQL A/P ! et quid du reste de ma question ?
Question : dans le cas de noeuds plus nombreux que 2.... à quoi ca sert ? il ne peux a avoir une base de donnée active que sur un noeud à la fois, non ?

Si tu parles de AlwaysOn, j'ai un client sur lequel on a 5 replicas en sus de l'instance active :
1 réplicas synchrone local pour qu'en cas de problème on bascule sur ce dernier
1 réplica asynchrone distant pour qu'en cas de sinistre majeur on bascule sur ce dernier
2 autres réplicas asynchrone locaux sur des petits serveurs afin d'assurer le reporting
1 réplica pour assurer la lecture des données afin d'limenter la BI

Bref, tu peut avoir différentes réplicas en lecture pour différents usages, y compris pour vérifier les bases, ou les sauvegarder....

A +