Hello,

 

I have configured three mirrors and am using a python script
(ldapSynchCheck.py) which check the sync status on retrieving the
contextCSN from both Provider and consumer

 

I tried deleting a tree from directory and checked what is the output of
the script and can still see "All of them are in sync". I believe this
is happening because contextCSN is not getting updated on the respective
directories and hence it will showing all in sync.

 

However sometimes I am getting below error and it seems one of the
consumer changed its contextCSN while provider was synching the data and
it also confirms that provider will not change the contextCSN until it
completes the sync to the consumer.

 

2010-05-06 15:15:51,459 - ldapSynchCheck.py - INFO - Provider is:
tardis03.nat.bt.com:389

2010-05-06 15:15:51,462 - ldapSynchCheck.py - DEBUG - Connecting to
ldap://tardis03.nat.bt.com:389

2010-05-06 15:15:51,464 - ldapSynchCheck.py - DEBUG - LDAP protocol
version 3

2010-05-06 15:15:51,465 - ldapSynchCheck.py - DEBUG - Binding with o=BT

2010-05-06 15:15:51,469 - ldapSynchCheck.py - INFO - Checking if
consumer tardis02.nat.bt.com:9011 is in SYNCH with provider

2010-05-06 15:15:51,470 - ldapSynchCheck.py - DEBUG - Connecting to
ldap://tardis02.nat.bt.com:9011

2010-05-06 15:15:51,471 - ldapSynchCheck.py - DEBUG - LDAP protocol
version 3

2010-05-06 15:15:51,472 - ldapSynchCheck.py - DEBUG - Binding with o=BT

2010-05-06 15:15:51,475 - ldapSynchCheck.py - DEBUG - Retrieving
Provider contextCSN

2010-05-06 15:15:51,482 - ldapSynchCheck.py - DEBUG - contextCSN =
20100506141551.044268Z#000000#003#000000

2010-05-06 15:15:51,483 - ldapSynchCheck.py - DEBUG - Retrieving
Consumer contextCSN

2010-05-06 15:15:51,513 - ldapSynchCheck.py - DEBUG - contextCSN =
20100506141551.044268Z#000000#003#000000

2010-05-06 15:15:51,515 - ldapSynchCheck.py - INFO -   Provider and
consumer exactly in SYNCH

2010-05-06 15:15:51,516 - ldapSynchCheck.py - INFO - Checking if
consumer tardis01.nat.bt.com:9022 is in SYNCH with provider

2010-05-06 15:15:51,517 - ldapSynchCheck.py - DEBUG - Connecting to
ldap://tardis01.nat.bt.com:9022

2010-05-06 15:15:51,519 - ldapSynchCheck.py - DEBUG - LDAP protocol
version 3

2010-05-06 15:15:51,520 - ldapSynchCheck.py - DEBUG - Binding with o=BT

2010-05-06 15:15:51,523 - ldapSynchCheck.py - DEBUG - Retrieving
Provider contextCSN

2010-05-06 15:15:51,525 - ldapSynchCheck.py - DEBUG - contextCSN =
20100506141551.044268Z#000000#003#000000

2010-05-06 15:15:51,526 - ldapSynchCheck.py - DEBUG - Retrieving
Consumer contextCSN

2010-05-06 15:15:51,573 - ldapSynchCheck.py - DEBUG - contextCSN =
20100506141549.755004Z#000000#003#000000 <here it goes different>

Traceback (most recent call last):

  File "./ldapSynchCheck.py", line 258, in <module>

    main()

  File "./ldapSynchCheck.py", line 253, in main

    is_insynch(ldapprov, ldapcons, options.basedn, options.threshold,
logger)

  File "./ldapSynchCheck.py", line 188, in is_insynch

    delta = contextCSN_to_datetime(provcontextCSN) -
contextCSN_to_datetime(conscontextCSN)

  File "./ldapSynchCheck.py", line 155, in contextCSN_to_datetime

    return
datetime.datetime.fromtimestamp(time.mktime(time.strptime(gentime,"%Y%m%
d%H%M%S")))

  File "/software/python/lib/python2.6/_strptime.py", line 454, in
_strptime_time

    return _strptime(data_string, format)[0]

  File "/software/python/lib/python2.6/_strptime.py", line 328, in
_strptime

    data_string[found.end():])

ValueError: unconverted data remains: .044268

            

As I know putting a frequent checkpoint will generate a large amount of
checkpoint log file and will cause issues while database recovery during
crash/corrupt situations.

 

Can someone please suggest how make this more precise? Is there any
other way contextCSN keeps on changing frequently? 

 

Please suggest.

 

 

Many Thanks in advance!!

 

Rahul Manchanda

 

GS Selfcare

Platform Build Team

 

Tel: +91 02066018100 Extn: 6178

SMTP: [email protected]

 

Office: Sharda Center ,6th Floor Annex

Off Karve Road, Erandwana ,Pune-04

 

Reply via email to