[RAS] [ACIS-tech] Migration Help

[Ivan Kurmanov]

Dan,

The new machine needs to share the RePEc data files with the Ideas server.
Have you done anything for that? Sshfs maybe?

Also, did you set up the mailing server there?

I'm thinking, maybe we could even do the last checks tomorrow and migrate on
Thursday...

-ivan

On Aug 30, 2011 8:27 PM, "Dan Hayes" <dhayes501 at gmail.com> wrote:
> I'm fine waiting until Sept 10-11. It will likely take more downtime
> though, it took quite a while to dump the database (less than an hour
though
> I think), and then it took several hours to transfer it here. Then it took
> 8+ hours to load it on the machine here.
>
> On Tue, Aug 30, 2011 at 11:37 AM, Ivan Kurmanov <duraley at gmail.com> wrote:
>
>> On Tue, Aug 30, 2011 at 7:22 PM, Dan Hayes <dhayes501 at gmail.com> wrote:
>> > It looks like it will take editing /etc/hosts to access the web
>> interface.
>> > Set authors.repec.org to 65.89.18.160.
>> >
>> > Also, the Affiliations section appears to be working fine now.
>>
>> I witness.
>>
>> Which means the Storable strings that were written (with nfreeze) on
>> the old nebka are readable on the new one, and we do not need any
>> other serialization changes at the moment.
>>
>>
>> >>> Dan, did you measure or record the time it took to restore the
>> database?
>> >> It took a solid 8 hours. I didn't time it exactly though. I watched
>> the
>> >> size of /var/lib/mysql and it grew to over 35G, acis is 32G and rdb is
>> 4.2G
>>
>> Then it looks like we should plan for at least 10-12 hours of downtime
>> of the service for the final migration.
>>
>> From the point of view of the least user experience damage (and brand
>> damage), it would be great to do the migration over the weekend. But
>> the nearest weekend (3-4 Sep) i'm occupied except at night, when I'd
>> like to have some sleep. The weekend after (10-11 Sep) i'm available.
>>
>> Or we can ignore the weekends and plan the transition on a business
>> day. I guess Dan will do the large part of the work again, so his
>> availability is key here. I'm pretty flexible at the moment.
>>
>>
>> And of course, there's more tests and checks to be done.
>>
>> -i
>>
>> >
>> > On Tue, Aug 30, 2011 at 10:19 AM, Dan Hayes <dhayes501 at gmail.com>
wrote:
>> >>
>> >> It took a solid 8 hours. I didn't time it exactly though. I watched
>> the
>> >> size of /var/lib/mysql and it grew to over 35G, acis is 32G and rdb is
>> 4.2G
>> >>
>> >> On Tue, Aug 30, 2011 at 10:05 AM, Ivan Kurmanov <duraley at gmail.com>
>> wrote:
>> >>>
>> >>> Dan, did you measure or record the time it took to restore the
>> database?
>> >>>
>> >>> -ivan
>> >>>
>> >>> On Tue, Aug 30, 2011 at 5:41 PM, Dan Hayes <dhayes501 at gmail.com>
>> wrote:
>> >>> > The SQL database has been loaded, and it appears to be running
>> >>> > properly.
>> >>> > You can test it at 65.89.18.160 or at http://nebka.stlouisfed.org.
>> >>> >
>> >>> > Did I not need to run the updareq commands again? It appears to be
>> >>> > working
>> >>> > without me needing to do anything else.
>> >>> >
>> >>> > On Mon, Aug 29, 2011 at 10:16 AM, Dan Hayes <dhayes501 at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> FYI
>> >>> >>
>> >>> >> I rsynced the files Saturday afternoon, and dumped the sql
database
>> >>> >> then
>> >>> >> as well. I transferred the db backup on Sunday, and I'm now
>> restoring
>> >>> >> the
>> >>> >> sql databases on the STL server. It looks like its going to take a
>> >>> >> while.
>> >>> >>
>> >>> >> On Sun, Aug 28, 2011 at 9:22 AM, Thomas Krichel <
>> krichel at openlib.org>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Dan Hayes writes
>> >>> >>>
>> >>> >>> > So the reason is that its faster than MySQL for what its being
>> used
>> >>> >>> > for?
>> >>> >>>
>> >>> >>> Yes. At least we think so.
>> >>> >>>
>> >>> >>> Kindly send me an ssh public key to give you access to the test
>> >>> >>> server.
>> >>> >>>
>> >>> >>>
>> >>> >>> Cheers,
>> >>> >>>
>> >>> >>> Thomas Krichel http://openlib.org/home/krichel
>> >>> >>> http://authorprofile.org/pkr1
>> >>> >>> skype: thomaskrichel
>> >>> >>>
>> >>> >>> _______________________________________________
>> >>> >>> ACIS-tech mailing list
>> >>> >>> ACIS-tech at lists.openlib.org
>> >>> >>> http://lists.openlib.org/mailman/listinfo/acis-tech
>> >>> >>
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > ACIS-tech mailing list
>> >>> > ACIS-tech at lists.openlib.org
>> >>> > http://lists.openlib.org/mailman/listinfo/acis-tech
>> >>> >
>> >>>
>> >>> _______________________________________________
>> >>> ACIS-tech mailing list
>> >>> ACIS-tech at lists.openlib.org
>> >>> http://lists.openlib.org/mailman/listinfo/acis-tech
>> >
>> >
>> > _______________________________________________
>> > ACIS-tech mailing list
>> > ACIS-tech at lists.openlib.org
>> > http://lists.openlib.org/mailman/listinfo/acis-tech
>> >
>>
>> _______________________________________________
>> ACIS-tech mailing list
>> ACIS-tech at lists.openlib.org
>> http://lists.openlib.org/mailman/listinfo/acis-tech
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/ras-run/attachments/20110830/e160937e/attachment-0001.html>