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@xxxxxxxxxx> 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
