<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 05/19/2015 08:58 AM, thierry bordaz
      wrote:<br>
    </div>
    <blockquote cite="mid:555ADEFF.5090304@redhat.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 05/19/2015 07:47 AM, Martin Kosek
        wrote:<br>
      </div>
      <blockquote cite="mid:555ACE84.3030105@redhat.com" type="cite">On
        05/19/2015 03:23 AM, Janelle wrote: <br>
        <blockquote type="cite">Once again, replication/sync has been
          lost. I really wish the product was more <br>
          stable, it is so much potential and yet. <br>
          <br>
          Servers running for 6 days no issues. No new accounts or
          changes (maybe a few <br>
          users changing passwords) and again, 5 out of 16 servers are
          no longer in sync. <br>
          <br>
          I can test it easily by adding an account and then waiting a
          few minutes, then <br>
          run "ipa  user-show --all username" on all the servers, and
          only a few of them <br>
          have the account.  I have now waited 15 minutes, still no
          luck. <br>
          <br>
          Oh well.. I guess I will go look at alternatives. I had such
          high hopes for <br>
          this tool. Thanks so much everyone for all your help in trying
          to get things <br>
          stable, but for whatever reason, there is a random loss of
          sync among the <br>
          servers and obviously this is not acceptable. <br>
        </blockquote>
        <br>
        Hello Janelle, <br>
        <br>
        I am very sorry to hear about your troubles. Would you be still
        OK with helping us (mostly Ludwig and Thierry) investigate what
        is the root cause of the instability of the replication
        agreements? This is obviously something that should not be
        happening at this rate as in your deployment, so I would really
        like to be able to identity and fix this issue in the 389 DS. <br>
      </blockquote>
      <font face="Times New Roman, Times, serif">Hello Janelle,<br>
        <br>
        I can only join my voice to Martin to say how I am sorry to read
        this.<br>
        Would you turn on replication logging level (8192) on the
        master/consumer and provide us the logs(access/error) and config
        (dse.ldif).<br>
        The master is the instance where you can see the update and the
        that is linked (replica agreement) to a replica(aka consumer)
        where the update is not received.<br>
      </font></blockquote>
    <font face="Times New Roman, Times, serif">what puzzles me most, is
      that replication is working for quite some time and then breaks,
      so we need to find out about the dynamics which lead to that
      state. You reported errors about invalid credentials or about a
      bind dn entry not found, these credentials don't get changed by ds
      or entries are not deleted by ds, so what triggers these changes.<br>
      also for the suggestion by Thierry to debug, we need to determine
      where replication breaks, if you add an account and it is
      propageted to some servers and not to others, where does it stop ?
      This depends on your replication topology, you said in anotehr
      post that you have a ring topology, does it mean all 16 servers
      are conencted in a ring only, and if two links break the topology
      is disconnected ?<br>
    </font>
    <blockquote cite="mid:555ADEFF.5090304@redhat.com" type="cite"><font
        face="Times New Roman, Times, serif"> <br>
        thanks<br>
        thierry<br>
      </font> </blockquote>
    <br>
  </body>
</html>