Re: server migration

[Russell Coker via luv-main]

On Monday, 19 June 2017 8:30:46 AM AEST Arjen Lentz via luv-main wrote:
> >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.

Thanks for the suggestion, it's something to consider when migrating a system 
that has a non-trivial amount of writes.  But when dealing with a system that 
has an average of less than 1 write of actual data per week it's not needed.

> 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.

Well if you want some sort of HA scheme that may be the case.  But if your 
service is small enough that the amount of effort required to make a HA system 
more reliable than a single system isn't viable then a single VM.

> 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.

https://www.linode.com/pricing

For Linode the pricing scales fairly linearly with size for most common sizes 
and other hosting companies have similar schemes.

-- 
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

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

Re: server migration

[Brian May via luv-main]

Russell Coker via luv-main  writes:

> Unfortunately we have some DNS issues.  I've got a simple TCP proxy in place 
> for the web server but that doesn't work so well for email as it breaks lots 
> of anti-spam checks.  I will use a proxy for the mail server if we don't have 
> DNS sorted out tonight.

DNS looks fine to me...


root@featherby:~# host luv.asn.au
luv.asn.au has address 188.40.100.241
luv.asn.au mail is handled by 10 lists.luv.asn.au.

root@featherby:~# telnet luv.asn.au 25
Trying 188.40.100.241...
Connected to luv.asn.au.
Escape character is '^]'.
220 luv.asn.au ESMTP Postfix (Debian/GNU)
^]close

telnet> close
Connection closed.

-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main