Discussion :

[Arnard]

Bonjour,

je cherche à simuler une mise en erreur d'une réplication P2P, j'ai donc monté une plateforme de 3 serveurs, mis une base en réplication, avec une configuration de rétention des transactions allant de 0 à 1h, et débranché 1 des 3 serveurs.

Au bout d'une heure le moniteur me remonte que les nodes sont en erreur, je rebranche et là ça reprend correctement le traitement, ce n'est pas vraiment le traitement que j'attendais (node restant en erreur). Que dois-je faire ou obtenir ce résultat ? Je précise qu'aucune opération d'écriture n'a été faite sur une des bases pour ce premier test.

Enfin, dernière question, dans la configuration de la distribution, à quoi correspond le champ "Durée de rétention de l'historique", j'appréhende mal son rôle.

Merci

[Arnard]

Après test, je me suis aperçu qu'il fallait modifier les données pour provoquer un abandon des abonnés.

Reste ma question sur la rétention des historiques, si quelqu'un peut m'éclairer, ce serait sympa

[dbaffaleuf]

Hello,

C'est la valeur en heures passée à la proc sp_MShistory_cleanup de nettoyage des tables d'historique des agents:

• MSlogreader_history
• MSdistributor_history
• MSsnapshot_history.

Les évènements antérieurs à cette valeurs sont supprimés des tables d'historique. Si tu conserver une rétention plus grande, il faut l'augmenter. Vérifie dans le job 'Distribution Cleanup history', (ou son équivalent français). Par exemple, une valeur de rétention à 48 heures donne:

EXEC dbo.sp_MShistory_cleanup @history_retention = 48

David B.

[dbaffaleuf]

Re-

D'ailleurs le nom du job exact est 'Agent history clean up: distribution'

[Arnard]

Merci dbaffaleuf pour cette réponse, SQL Server induit en erreur en parlant de stockage des historiques de performance dans Management Studio je trouve.

Un décalage de 12h reste recommandé ? Quel est l'usage en général ?

Merci

[dbaffaleuf]

C'est pas mal de laisser 3-4 jours en cas de pépin en début de week end long. Le mètre-étalon, c'est le week end de l'ascension pour les boites qui n'ont pas d'astreinte 24/7. Imagines que ton distributeur tombe à cause d'un duplicate key (surtout dans une P2P) le mercredi soir, tu te retrouves avec une base distribution gigantesque le lundi matin et une historique incomplet dans les tables de l'agent. En fait, le cleanup ne laisse que la dernière ligne:

Code :

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

1
2
3
4
5
6
7
  DELETE MSdistribution_history   
   WHERE agent_id = @agent_id  
    AND time <= @cutoff_time   
    AND timestamp not in (SELECT max(timestamp)   
          FROM MSdistribution_history   
          WHERE agent_id = @agent_id)  
   OPTION(MAXDOP 1)

Donc tu verras peut être ton erreur, mais peut être pas dans tous les cas. C'est un cas extrême, mais la Loi de Murphy est impitoyable

Raisonnablement 72 ou 96 heures c'est pas mal, à condition que la base distribution puisse grossir tranquillement (parce que ça tient quand même de la place tout cet historique).

A+ David B.

[Arnard]

Oki, merci pour ces précisions