I will tell a little about how we handled are cutover from iplanet 5.2running on SPARC hardware to FC5 on x86-64. 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. 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. 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> 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 > > 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 -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20070709/453f9abd/attachment.html
