[Fedora-directory-users] Migration from i-planet 52

[Richard Megginson]

Eddie C wrote:
> The document I had suggested using ldapsearch and ldapadd to migrate 
> data. If lidf2db commands are faster/better I will use them.
>
> >> Try creating all of the required indexes first, then doing the 
> import of
> >> your original LDIF.
>
> I am willing to try this, but It is scary to me. I would have rather 
> you said I must be doing something wrong...because....
>
> Our LDAP database has been in production for 6 years. We add indexes 
> to our i-planet on average twice a year due to new software or new 
> features. Your advice is almost suggesting that adding new indexes can 
> corrupt the database.
No, not exactly.  I'm not really sure what went wrong.  Feel free to try 
it again.  It's just that for the initial data import, it's much faster 
to configure the indexes first, then use ldif2db to import the data and 
create the indexes at the same time.
>
> I will try again from scratch using everyones advice of course.
>
> Thank you,
> Edward
>
>
>
>
>
> On 12/16/06, *Noriko Hosoi* < nhosoi at redhat.com 
> <mailto:nhosoi at redhat.com>> wrote:
>
>     Richard Megginson wrote:
>
>     > Eddie C wrote:
>     >
>     >> I recently did an ldif backup of our iplanet 52 database. Its about
>     >> an 88 MB ldif file.
>     >> I took this to a new FDS server Dell 850 3 ghz duel core 2 sata
>     hard
>     >> disks.
>     >> I ran an ldapadd  the data imported perfectly.
>     >
>     Are there any reason to use ldapadd instead of ldif2db?  ldif2db
>     should
>     be much faster...
>
>     >> Then I tried to cutover some systems and give the database some
>     load.
>     >>
>     >> System went 200% processor
>     >>
>     >> Eventually I realized I was missing indexes so I added them through
>     >> the graphical tool.
>     >>
>     >> The log seemed to do something like this
>     >> generating index 1%
>     >> generating index 2%
>     >> ....
>     >> generating index 49%
>     >> Done
>     >> Seemed weird that they would jump from 49% to Done
>     >> At this point the new system was running at 100% processor
>     >> But the queries are running faster on our old 440 MHZ sparc t1
>     >> server52 database
>     >>
>     >> I ran
>     >> DB ERROR: db_verify: Page 30: out-of-order key at entry 498
>     >> DB ERROR: db_verify: DB->verify: db/o_com/channelcontentowner.db4:
>     >> DB_VERIFY_BAD: Database verification failed
>     >>
>     >> then I tried db2_index. The program seemed to be in a tight loop
>     >> complaining about 1 missing entry.
>     >>
>     >> I do not realize how the data can be so corrupted right after
>     an import.
>     >>
>     >> These are someone generic symptoms. Any ideas? Thanks
>     >
>     > Try creating all of the required indexes first, then doing the
>     import
>     > of your original LDIF.  Not only will the import+index creation be
>     > much faster (than doing the import then creating the indexes one
>     at a
>     > time), but I think your database corruption problems will vanish.
>     >
>     >>
>     ------------------------------------------------------------------------
>
>     >>
>     >> --
>     >> Fedora-directory-users mailing list
>     >> Fedora-directory-users at redhat.com
>     <mailto:Fedora-directory-users at redhat.com>
>     >> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     >>
>     >
>     >------------------------------------------------------------------------
>     >
>     >--
>     >Fedora-directory-users mailing list
>     >Fedora-directory-users at redhat.com
>     <mailto:Fedora-directory-users at redhat.com>
>     >https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     <https://www.redhat.com/mailman/listinfo/fedora-directory-users>
>     >
>     >
>
>
>
>     --
>     Fedora-directory-users mailing list
>     Fedora-directory-users at redhat.com
>     <mailto:Fedora-directory-users at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20061218/4e585da3/attachment.bin>