Re: server migration

[Arjen Lentz via luv-main]

>time when we have 2 separate instances of Drupal and I don't want
>anyone to 
>make changes to the old one that get lost.

Re the backend MySQL storage, you make the new MySQL instance a slave of the 
old one. That way nothing can get lost.
We've find this many times with large systems. No outage and no data loss.

By the way, things tend to actually work out better in many respects to NOT 
have frontend and database on the same VM. This is generally the first step we 
take in creating resilient and scalable environments.

There are many disadvantages to combining all services onto the same box. In vm 
hire terms, it may also be cheaper to use more smaller instances as the pricing 
model favours those.

Regards, 
Arjen. 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

server migration

[Russell Coker via luv-main]

New hardware has been purchased for the system that hosts the LUV VM.  The old 
server is a i7-920, 8G of RAM, and 2*750G SATA disks.  The "new" server is a 
i7-930, 48G of RAM, 2*250G SATA SSD, and 2*2TB SATA disks.  I put new in 
quotes because it's not new hardware, it's hardware someone else rented first.  
For most hosting providers getting hardware someone else used first is 
standard practice.  But the Hetzner business model is that the default is to 
buy new systems that haven't been used before.  Systems that have been used 
are sold by a reverse-auction system where the price on each system goes down 
steadily until someone buys it.

I am not sure exactly when I will migrate the LUV VM, but it will probably be 
late at night.  I will coordinate with the committee because there will be a 
time when we have 2 separate instances of Drupal and I don't want anyone to 
make changes to the old one that get lost.  The advantage of doing it this way 
is that for the people viewing the web site there will be no outage.

Before starting the changes I will stop Postfix (which will only be noticed as 
delayed list mail) and configure Apache to fail any requests to the list 
server configuration web pages.  The main aim is to have the minimum of 
surprises for people who don't read my announcement messages.  Delayed mail is 
not noteworthy.  A list server web page being down for a while usually isn't a 
big deal.  The main web site with information on future meetings etc is the 
important thing that needs to remain up.

The current LUV VM has 2G of RAM and 512M of swap of which 450M is used.  The 
new VM will have at least 4G and maybe 6G of RAM.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main