[RS] synchronisation bases

Bonjour
Replication server 15
Bases ASE 15.0.2
J'ai trois bases :
la base 1 est répliquée sur la base 2
la base 2 est répliquée sur la base 1
la base 1 est répliquée sur la base 3
la base 2 est répliquée sur la base 3

Je veux pouvoir synchroniser mes bases quand il y a de l'activité.
Je ne sais pas comment m'y prendre
Voici en bref, les étapes pour la mise en place de ma réplication
- création de connection pour les trois bases.
- dump/load
- création de database Réplication définition.
create database replication definition <RD_BD_name>
with primary at <name>
replicate DDL
not replicate system procedures
go
- créaton de subscription :
create subscription <name_sub>
for database replication definition <RD_BD_name>
with primary at <name>
with replicate at <name>
without materialization
subscribe to truncate table
go
- check de la subscription
il doit me manquer des étapes car mes bases ne sont pas synchrones.
quelles sont les étapes pour synchroniser les bases entre elles

Merci d'avance pour vos réponses

Difficle de répondre en 2 mots :

Il faudrait utiliser la commande "define subscription <sub_name> for database replication definition <blablabla>" avec l'option "use dump marker" et utiliser un dump/load pour synchoniser les bases (1 vers 2).

Mais, il va bien falloir arrèter l'activitée, à un momment, pour exécuter le "load database ...".

La documentation Sybase peut aussi être une aide (RepServer Administration Guide, chapter Managing Replicated Objects using Multi-Site Availability)


DBRep

Lors de l'utilisation d'un dump marker, penser à désactiver le trunc log on checkpoint ou les dump transaction sur la base source, avant de faire le define subscription puis le dump/load.
Sinon, le enable marker pourait se perdre.

Plouf-plouf, je recommence:

Je pense que tu cherche à faire une omelette sans casser d'oeufs, si je puis dire.

Prenons un exemple simple de Warm/Standby (WS) "classique", lors de la resynchonisation de la Standby à partir de l'Active DB (Warm) à l'aide de l'option "use dump marker", l'activité utilisateur peut être maintenue sur l'Active DB, mais pas sur la Standby, qui de toute façon devra êre "reloadée", donc ne peut PAS conserver son activité utilisateur (qui, dans le cas d'une WS, est une activité utilisateur en lecture seule, si activité il y a).

Dans ton cas, même si ton schéma n'avait que 2 bases, il faudrait forcement arreter l'activité utilisateur sur une des bases (celle qui ne serait pas "maître").
Alors, avec 3 bases, la seule base qui poura conserver son activité utilisateur pendant le processus de resynchonisation sera ta base "maître".
Ca c'est en utilisant l'option "use dump marker", qui permet vraiment de conserver une activité utilisateur sur la base "maître". La seule chose qui peut pénaliser tes utilisateurs sur cette base "maître", c'est l'exécution du "dump database" (qui peut les ralentir).
Et si tu n'utilise pas l'option "use dump marker", tu es obligé d'arreter toute activité sur toutes tes bases pour 1) extraire tes données des bases "source" 2) intégrer tes données dans les bases "cible".

Donc grosso modo en utilsant l'option "use dump marker", ça donnerait ça :
- arrêt de l'activité sur les bases 2 et 3 (en supposant que la base 1 soit ta base "maître")
- "define subscription for db <blabla> use dump marker" de 1 vers 2
- dump de la base 1
- reload de la base 1 dans la base 2
- resume base 2
- "create subscription fo db <blabla> without materialization" de 2 vers 1
- "define subscription for db <blabla> use dump marker" de 1 vers 3
- dump de la base 1
- reload de la base 1 dans la base 2
- resume base 3
- "create subscription fo db <blabla> without materialization" de 3 vers 1
- "create subscription fo db <blabla> without materialization" de 3 vers 2
- "create subscription fo db <blabla> without materialization" de 2 vers 3
- redémarage de l'activité sur les bases 2 et 3

=> je pense qu'il n'est pas possible de faire la synchronisation de 1 vers 2 et de 1 vers 3 en parallele, mais bien, l'un après l'autre.
=> de-même, il faut faire un deuxième DumpDB de la base 1, parce que l'utilisation de l'option "use dump marker" nécessite qu'un "dump" soit exécuté après.

Enfin, c'est mon point de vue...


Il y a un autre truc qui me chiffone un peu dans ta configuration, c'est cette réplication bi-directionnelle à 3 bases (même à 2 bases, le problème serait le même), j'imagine l'utilisateur Dupont en train de modifier une donnée sur la base 1 et un autre utilisateur Durant en train de modifier la même donnée sur la base 2, Dupont va se retrouver avec les données de Durant mais aura perdu les siennes sur la base 1, et vice-versa pour la base 2.
Si tu n'as pas de garde-fou pour éviter ce genre d'action, tu risque fort de te retrouver avec des bases de-synchronisées sans vraiment comprendre pourquoi ...


DBRep

Bonjour,

Je pense qu'il y a de fortes chances que tu ne puisses pas faire de dump load entre tes bases 1 et 2 car elles sont surement toutes les deux des sources.

Le seul moyen alors de synchroniser de maniere croisé est soit de laisser replication server materialiser lui meme les données sur la base repliqué avec la commande create subscription. Ca marche si les tables sont petites car on maintient des locks sur la table source le temps de la copie. Il existe pas mal d'option a la commande de creation automatique pour eviter les soucis

Si les tables sont trop grosses ou que le lock n'est pas envisageable la procédure a suivre est un peu plus complexe car on ne peut pas utiliser les automatismes du replication server :

- define subscription
- suspend connection
- activate subscription (rep serv stocke les maj sur la table)
- copies des données (bcp, select into ou insert select)
- autocorrection on (evite les conflits pendant la synchro)
- resume connection (rep serv applique les maj sur la base cible)
- controle manuel que les données sont synchro
- validate subscription
- autocorrection off

Dans tous les cas je conseille vivement de lire les manuels accessibles gratuitement sur le site de sybase http://infocenter.sybase.com/help/index.jsp

Bonne chance.