Coruption LDAP após a atualização

1

Eu fiz o upgrade do openldap do openldap-2.4.39-8.el6.x86_64 para o 2.4.40-12.el6.x86_64 e depois de reiniciar o servidor, recebi o seguinte erro. Estou tentando descobrir como recuperar, pois não tenho backup.

586d0afc <<< dnNormalize: <cn=write>
586d0afc backend_startup_one: starting "dc=custsvc,dc=mycompany"
586d0afc bdb_db_open: "dc=custsvc,dc=mycompany"
586d0afc bdb_db_open: database "dc=custsvc,dc=mycompany": dbenv_open(/var/lib/ldap).
586d0afc bdb(dc=custsvc,dc=mycompany): file id2entry.bdb has LSN 1/720219, past end of log at 1/600
586d0afc bdb(dc=custsvc,dc=mycompany): Commonly caused by moving a database from one database environment
586d0afc bdb(dc=custsvc,dc=mycompany): to another without clearing the database LSNs, or by removing all of
586d0afc bdb(dc=custsvc,dc=mycompany): the log files from a database environment
586d0afc bdb(dc=custsvc,dc=mycompany): /var/lib/ldap/id2entry.bdb: unexpected file type or format
586d0afc bdb_db_open: database "dc=custsvc,dc=mycompany": db_open(/var/lib/ldap/id2entry.bdb) failed: Invalid argument (22).
586d0afc ====> bdb_cache_release_all
586d0afc backend_startup_one (type=bdb, suffix="dc=custsvc,dc=mycompany"): bi_db_open failed! (22)
586d0afc slapd shutdown: initiated
586d0afc ====> bdb_cache_release_all
586d0afc bdb_db_close: database "dc=custsvc,dc=mycompany": alock_close failed
586d0afc slapd destroy: freeing system resources.
586d0afc slapd stopped.
    
por Tim Hughes 04.01.2017 / 16:07

1 resposta

1

Então, depois de procurar pela internet e não encontrar uma solução que funcionasse e o único método recomendado parecia ser db_recover -v -h /var/lib/ldap/ , o que não funcionou, mas notei que ele incrementou o ponto de verificação de recuperação.

[root@lddev-build-par01 ~]# db_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 1 offset 1632
Recovery complete at Wed Jan  4 14:52:26 2017
Maximum transaction ID 0 Recovery checkpoint [1][1632]
[root@lddev-build-par01 ~]# db_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 1 offset 1724
Recovery complete at Wed Jan  4 14:52:26 2017
Maximum transaction ID 0 Recovery checkpoint [1][1724]

Então, depois de ter certeza de que eu tinha um backup dos meus dados que não funcionavam, eu executei esse comando várias vezes até que o ponto de verificação de recuperação fosse maior do que o que o arquivo BDB achava que era. Eu realmente não esperava que funcionasse.

while true; do db_recover -v -h /var/lib/ldap/; done

Mas aconteceu: -)

Eu não gostaria de garantir que não houve perda de dados, mas como esse era um ambiente de desenvolvimento, não é o fim do mundo e o conjunto de testes logo encontrará algum problema. Espero que isso ajude alguém.

    
por 04.01.2017 / 16:19