Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 5 sur 5
  1. #1
    Invité de passage
    Inscrit en
    décembre 2007
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 1
    Points : 0
    Points
    0

    Par défaut [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

  2. #2
    Nouveau Membre du Club
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 33
    Points : 39
    Points
    39

    Par défaut

    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

  3. #3
    Membre actif
    Inscrit en
    août 2007
    Messages
    134
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 134
    Points : 153
    Points
    153

    Par défaut

    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.

  4. #4
    Nouveau Membre du Club
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 33
    Points : 39
    Points
    39

    Par défaut

    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

  5. #5
    Candidat au titre de Membre du Club
    Inscrit en
    avril 2007
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 16
    Points : 10
    Points
    10

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •