On Oct 13, 5:00 pm, JimCifarelli <[email protected]> wrote:
> Thank you Fred for your response.
>
> 1. I like the use of the "temporary" new.foo.com domain name and
> redirect.
> Do you know how well Ruby libraries like Net::HTTP, ActiveResource, or
> RestClient will handle 302 Redirects?
> I'm concerned that user's "posts" to the application will fail when
> confronted with a redirect.
I'm not sure. It's certainly possible that some of your api clients
wouldn't understand them
Fred
>
> 2. Great idea on the transparent forward proxy. I'll look into this.
>
> 3. My end goals include phasing out the old server (and stop paying
> for it)...just keeping it running long enough to validate users
> ability to transition to the new server without issue. For a fair
> amount of time, I can also monitor for continued API use of the old
> server and perhaps warn valid user attempts of their DNS issues.
>
> Thank you again Fred for all the time and quality answers you
> contribute to this community.
>
> -Jim
>
> On Oct 13, 4:25 am, Frederick Cheung <[email protected]>
> wrote:
>
>
>
> > On Oct 12, 7:24 pm, JimCifarelli <[email protected]> wrote:
> > .
>
> > > I'm in search of a solution that provides:
> > > 1. Little to no downtime to customers.
> > > 2. Considers Internet DNS propogation time for finding the new host
> > > IP.
> > > 3. Considers database migration.
>
> > > I'm not looking for a step-by-step, command line answer, only a higher-
> > > level point of view that can point me in the proper direction.
>
> > You've had some good answers, here are some other ones:
>
> > - register a new domain new.foo.com and point it at where your new
> > hosting will be
> > - setup database replication between your 2 sites
> > - turn off mongrels on old site
> > - stop replication
> > - turn on the mongrels on new site
> > - install a redirect on old.foo.com that redirects people to
> > new.foo.com
> > - update old.foo.com to point to new.foo.com
>
> > You can lose the database replication step at the expense of some time
> > by just dumping the db to a file and copying it over once you take
> > your old site down (or do stuff like directly copy the database's
> > files) - how practical that is depends on the size of your data.
>
> > We're doing something similar at work at the moment.
>
> > Option two is almost the same as option 1 except that instead of doing
> > a redirect from old.foo.com you actually proxy traffic between the two
> > (so unlike option one, users never see new.foo.com in their address
> > bar)
>
> > Fred
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
