Grouper Users - Open Discussion List

[Jeffrey Crawford <>]

The only thing I can suggest is when we moved from postgres to Oracle, I had to devise a dump from postgres, throw that through some perl filters and populate the other DB. I would do that several times and have new grouper instances connect to the DB to be migrated to, then test.

When we were confident we had a working migration script we switched over and only had an around 5 min. downtime. Granted we didn't have the data we have now.

Jeffrey E. Crawford
Enterprise Service Team

    ^         ^

   / \  ^    / \    ^

  /   \/ \  /   \  / \

 /        \/     \/   \

/                      \

You have been assigned this mountain to prove to others that it *can* be moved.

On Fri, Aug 25, 2017 at 7:23 PM, Baron Fujimoto <> wrote:

We are planning to migrate our Grouper from MySQL db instance to another,
basically using the procedure outlined here:

<https://spaces.internet2.edu/display/Grouper/Migrating+Grouper+from+one+MySQL+to+another>

Presumably, we want to prevent any updates to the Grouper db until the
migration is completed to ensure cnosistency between the old and new DBs.

We know from experience though that the db export and import process are
quite time consuming (hours, at least).

Does anyone have any suggestions for lessening the impact on our Grouper
users during this migration process? For example, is there a way to put
Grouper in a read-only mode? Else, in the absence of options, I think
we're looking at a complete service outage for the duration of the
export/import migration process.

Aloha,
-baron
--
Baron Fujimoto <> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum