Eddie C wrote: > I will tell a little about how we handled are cutover from iplanet 5.2 > running on SPARC hardware to FC5 on x86-64. This is very good information. Thanks! > > I had some extra ports on our terminal server so I connected the old > SPARC systems to the terminal server so I can manage them out-of-band > (and later after I took their IP addresses away) > > Remember LDAP is a directory service. Directory services support > frequent read operations and infrequent write operations. Not every > application fits this profile but in our case we shut down/disabled > our web application that modifies our LDAP. > > We have a multi-GB database approx 2 GB. We ran an LDAP search > command/db2ldif. I do not remember this taking a long time probably < > 8 minutes. Remember LDAPsearch is very fast. db2ldif is much, much faster than ldapsearch. > > We were moving from master/slave to multi-master. At that point I > setup multi-master on the new systems. We used SCP to copy over the > ldif data, then I added it to one side using Ldapmodify. Again this > took less then 20 minutes. ldif2db is much, much faster than ldapmodify. > > I quickly re-added indexes and verified final settings. Then I > disabled the old systems using the Terminal Server and added a > sub-ip-interface to the new systems for an IP take-over. > > When we had done testing and all was well and good again we re-enabled > out web application. > > For us the migration was a Friday process and our window was based on > how long we could live without database changes. All our applications > that have read access suffered a small intermittent outage when we > switched the IP. > > The good part about this process is you can completely test the dump > and restore without doing the actual cut-over to see how long the > entire process will take. Dump from your old harware/restore to new. > > Tools to move the database real time/cross platform would be nice, but > in our case they would be overkill if you have a small amount of data > the standard tools can probably do it in soft-real time. > > > On 7/9/07, *Richard Megginson* <rmeggins at redhat.com > <mailto:rmeggins at redhat.com>> wrote: > > David Barker wrote: > > Richard Megginson wrote: > >> > >> One of the big issues is cross platform migration e.g. going from > >> FC-5 i386 to F7 x86_64. There are a number of issues involved > with > >> this. We are trying to figure out the best way to do this and we > >> need your help. If you could, please read the section about cross > >> platform migration - > >> > http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform > >> - and let us know what you think, especially if you are an > admin who > >> will actually be using this in a production environment. > > > > I'd guess the "worst-case upgrade" is a single directory server > > deployment where a cross platform upgrade could imply only 1 host is > > available for reformat? If so, doing a "Local Source to Remote > Target" > > migration doesn't make much sense. In such cases, an export to ldif > > first, backup/ reinstall / restore "/opt/fedora-ds" and then do the > > upgrade against the restored data seems like the best way to do > things. > Do you mean, you reformat the disk and install the new version of the > OS? On the same machine? In that case, if the architecture is the > same, no data conversion is needed - the data in the databases can > just > be used directly. > > > > Multi-directory-server sites probably have spare hardware kicking > > around - I wouldn't worry about wasting disk space ;-) > Sure, but there are some cases where folks will have multi-GB > databases > on old machines. > > > > -- > > 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 > > > > ------------------------------------------------------------------------ > > -- > 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://lists.fedoraproject.org/pipermail/389-users/attachments/20070709/c62336c6/attachment.bin
