I've been having some problems while importing some records into my ldap server and the server crashed with error (23 november)
Nov 23 12:06:55 berlinzoo slapd[29709]: ====> cache_add_entry( 184299 ): "cn=157041,ou=non iscritti,ou=<CUT> ": already in id cache Nov 23 12:06:55 berlinzoo slapd[29709]: cache_add_entry_lock failed Nov 23 12:06:55 berlinzoo slapd[29709]: cache_add_entry_lock failed Nov 23 12:09:09 berlinzoo slapd[29709]: ldbm: ==> page 3266: illegal page type or format Nov 23 12:09:09 berlinzoo slapd[29709]: ldbm: ==> PANIC: Invalid argument
When restarted, sometimes the server crashes so I've read some on google and decided to db_recover and then restart.
Yesterday (27 November) the openldap server worked "quite" well, but sometimes still crashes: Nov 27 08:09:53 berlinzoo slapd[8529]: ldbm: ==> page 3267: illegal page type or format Nov 27 08:09:53 berlinzoo slapd[8529]: ldbm: ==> PANIC: Invalid argument (infact it does not crash, my application just hangs and cannot use ldap server anymore)
I've noticed that my daily backup (I know, I'm stupid, I should have restored that backup the next day and not wait till now) since 24 is getting 2Gb (but just because it lock for max file size reached otherwise goes over 4Gb).
What I think is that there should be a kind of "circular" reference because normally the backup is 23Mb, not >4.5GB.
Anyone can suggest a correct procedure to get it stable without restoring the 23's backup file ?
Thank you very much Julien
Anyone can suggest a correct procedure to get it stable without restoring the 23's backup file ?
Your logs indicate ldbm; that database backend isn't ACID so there's no way to guarantee recovery in one piece. Your best bet is to take your most recently available good data in LDIF form (e.g. slapcat), and slapadd it into a new bdb or hdb database. {b,h}db can recover from these sort of issues.
Aaron Richton ha scritto:
Anyone can suggest a correct procedure to get it stable without restoring the 23's backup file ?
Your logs indicate ldbm; that database backend isn't ACID so there's no way to guarantee recovery in one piece. Your best bet is to take your most recently available good data in LDIF form (e.g. slapcat), and slapadd it into a new bdb or hdb database. {b,h}db can recover from these sort of issues.
Will check for a manual debugginh on the ldif files and the proceed to restore older backup.
Thanks Julien
On 11/28/06, JJ jj@thecloud.org wrote:
I've been having some problems while importing some records into my ldap server and the server crashed with error (23 november)
Nov 23 12:06:55 berlinzoo slapd[29709]: ====> cache_add_entry( 184299 ): "cn=157041,ou=non iscritti,ou=<CUT> ": already in id cache Nov 23 12:06:55 berlinzoo slapd[29709]: cache_add_entry_lock failed Nov 23 12:06:55 berlinzoo slapd[29709]: cache_add_entry_lock failed Nov 23 12:09:09 berlinzoo slapd[29709]: ldbm: ==> page 3266: illegal page type or format Nov 23 12:09:09 berlinzoo slapd[29709]: ldbm: ==> PANIC: Invalid argument
When restarted, sometimes the server crashes so I've read some on google and decided to db_recover and then restart.
Yesterday (27 November) the openldap server worked "quite" well, but sometimes still crashes: Nov 27 08:09:53 berlinzoo slapd[8529]: ldbm: ==> page 3267: illegal page type or format Nov 27 08:09:53 berlinzoo slapd[8529]: ldbm: ==> PANIC: Invalid argument (infact it does not crash, my application just hangs and cannot use ldap server anymore)
I've noticed that my daily backup (I know, I'm stupid, I should have restored that backup the next day and not wait till now) since 24 is getting 2Gb (but just because it lock for max file size reached otherwise goes over 4Gb).
What I think is that there should be a kind of "circular" reference because normally the backup is 23Mb, not >4.5GB.
Since slapcat's ldif is pretty human-readable, you should be able to manually verify what's going on. (use head/tail -somelines is 4.5GB is too big to view) This should give you a good idea of a path to figure out the changes between your last normal backup, and this huge one.
_Matt
Since slapcat's ldif is pretty human-readable, you should be able to manually verify what's going on. (use head/tail -somelines is 4.5GB is too big to view) This should give you a good idea of a path to figure out the changes between your last normal backup, and this huge one.
_Matt
Diff can be your friend too. You can diff the two ldif files and get a really clear picture of what changed...
diff old new | less
Owen
matthew sporleder ha scritto:
On 11/28/06, JJ jj@thecloud.org wrote:
What I think is that there should be a kind of "circular" reference because normally the backup is 23Mb, not >4.5GB.
Since slapcat's ldif is pretty human-readable, you should be able to manually verify what's going on. (use head/tail -somelines is 4.5GB is too big to view) This should give you a good idea of a path to figure out the changes between your last normal backup, and this huge one.
_Matt
Thanks Matt, I will split my big file into a smaller one with "split -b25m backup_file" in order to be able to edit them and check what is wrong.
Cheers Julien
openldap-software@openldap.org
-
Aaron Richton -
JJ -
matthew sporleder -
Owen DeLong