Re: Mirror Mode, replicas and delta-syncrepl

On Thu, Oct 22, 2009 at 4:34 PM, Sam Tran <[email protected]> wrote:
> Hi All,
>
> I am looking to upgrade our OL 2.3 platform to OL 2.4.
>
> For all write operations, I'd like to have two masters in Mirror Mode
> configuration and behind a load balancer with a virtual IP (VIP)
> address. All read operations will be performed on a set of replicas.
> The replication mode would be delta-syncrepl. I am trying to figure
> out how to configure replication between the replicas and the masters.
> I came across those two threads that seem to address this issue:
>
> http://www.openldap.org/lists/openldap-devel/200903/msg00085.html
> http://www.openldap.org/lists/openldap-software/200903/msg00127.html
>
> If I understand correctly, there are two possible configurations:
>
> 1) On each replica, create a single syncrepl stanza that points to the
> load balancer VIP.
>
[snip]

I have started replication using the first configuration where the
consumer has a single syncrepl stanza pointing to the load balancer
Virtual IP address (VIP):

syncrepl    rid=012
                provider=ldaps://vip.example.com:636
                bindmethod=simple
                binddn="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
                credentials=xxxxxxxxxxxxxxxxx
                type=refreshAndPersist
                retry="5 +"
                searchbase="dc=example,dc=com"
                logbase="cn=accesslog"
                logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
                schemachecking=on
                syncdata=accesslog


I have two providers, A and B, configured in Mirror Mode behind the
VIP (vip.example.com). Write operations are performed on the provider
that hold the VIP at a given time.

The consumer got its initial content load when provider A had the VIP.
Any subsequent updates on the provider that holds the VIP were
replicated to the consumer.

I then manually migrated the VIP from provider A to provider B to
simulate a failover. Any updates on the provider that holds the VIP
were not replicated to the consumer unless I manually restarted the
consumer. Here are the resulting logs on the consumer:

Oct 28 11:35:22 info-ldap-012 slapd[12157]: slapd starting
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2: rid=012
LDAP_RES_SEARCH_RESULT
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2: rid=012
(4096) Content Sync Refresh Required
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2: rid=012
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 28 11:35:22 info-ldap-012 last message repeated 16 times
Oct 28 11:35:22 info-ldap-012 slapd[12157]: syncrepl_entry: rid=012
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 28 11:35:22 info-ldap-012 slapd[12157]: syncrepl_entry: rid=012
be_search (0)
Oct 28 11:35:22 info-ldap-012 slapd[12157]: syncrepl_entry: rid=012
uid=st,ou=People,dc=example,dc=com
Oct 28 11:35:22 info-ldap-012 slapd[12157]: syncrepl_entry: rid=012
be_modify uid=st,ou=People,dc=example,dc=com (0)
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2: rid=012
LDAP_RES_SEARCH_RESULT
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2:
cookie=rid=012,sid=00b,csn=20090721190743.568481Z#000000#000#000000;20091028153356.906
892Z#000000#00a#000000;20091028153507.836516Z#000000#00b#000000
Oct 28 11:35:22 info-ldap-012 slapd[12157]: nonpresent_callback:
rid=012 present UUID edbbfcd6-c629-1029-9d11-9eba13a1da21, dn
dc=example,dc=com
Oct 28 11:35:22 info-ldap-012 slapd[12157]: nonpresent_callback:
rid=012 present UUID edda076c-c629-1029-9d12-9eba13a1da21, dn
cn=manager,dc=example,dc=com
[snip]
Oct 28 11:35:22 info-ldap-012 slapd[12157]: slap_queue_csn: queing
0x12c1fb20 20091028153507.836516Z#000000#00b#000000
Oct 28 11:35:22 info-ldap-012 slapd[12157]: slap_graduate_commit_csn:
removing 0x12d959f0 20091028153507.836516Z#000000#00b#000000
Oct 28 11:35:22 info-ldap-012 slapd[12157]: do_syncrep2: rid=012
LDAP_RES_INTERMEDIATE - REFRESH_DELETE


However if I perform an update on provider A (even though it doesn't
hold the VIP), the change is replicated to the consumer. Here are the
resulting logs on the consumer:

Oct 28 11:33:56 info-ldap-012 slapd[22967]: do_syncrep2:
cookie=rid=012,sid=00b,csn=20091028153356.906892Z#000000#00a#000000
Oct 28 11:33:56 info-ldap-012 slapd[22967]: slap_queue_csn: queing
0x1e7eea84 20091028153356.906892Z#000000#00a#000000
Oct 28 11:33:56 info-ldap-012 slapd[22967]: slap_graduate_commit_csn:
removing 0x1e803500 20091028153356.906892Z#000000#00a#000000
Oct 28 11:33:56 info-ldap-012 slapd[22967]: syncrepl_message_to_op:
rid=012 be_modify uid=st,ou=People,dc=example,dc=com (0)
Oct 28 11:33:56 info-ldap-012 slapd[22967]: slap_queue_csn: queing
0x1e7eeff0 20091028153356.906892Z#000000#00a#000000
Oct 28 11:33:56 info-ldap-012 slapd[22967]: slap_graduate_commit_csn:
removing 0x1e7f0170 20091028153356.906892Z#000000#00a#000000

Is this the expected behaviour? Should I infer that delta-syncrepl
does not work when the consumer is pointing to a load balancer
fronting two providers in Mirror Mode configuration?

Thanks.
--
Sam