[HyperDB] Replication and Failover - v.2

[Callum Macdonald]

G'day,

I think this is getting slightly off the topic of HyperDB, perhaps we
could move the discussion to a more relevant forum. I'm not sure what
that might be though.

I would suggest looking again at the aims of your setup. If you can be
clear on your priorities, the rest can be figured out. But with muddy
priorities, you will most likely have a muddy system.

If you want to be attack resistant, I'm not sure that two fully
replicated systems achieves that aim.

If your primary aim is fault tolerance, then two fully replicated
servers adds some value. But remember any software bugs or issues will
be replicated. So really what are you protected from?

If you want to maximise performance, I would suggest two fully
replicated systems will greatly over-complicate the system and the
complication will outweigh any performance gain.

I recently watched Robert Scoble's interview on avoiding the fail
whale[1]. The speakers all seemed to agree on one point. Build a system,
then modify or improve based on performance. Track everything, figure
out where your issues lie, and then solve them. You cannot design a
perfect system on paper, without real life testing.

So my advice would be to start with a simpler system. Split your
database / web server and see how you go. Measure performance
obsessively. Then make improvements based on real world data, rather
than theoretical postulation.

Best of luck with your setup.

Cheers - Callum.

[1] http://www.fastcompany.com/scalability

On Fri, 2008-10-24 at 18:45 +0200, Mustafa Suphi Yilmaz wrote:
> Dear Masters,
> I talked with my hosting-master and he gave me one of his long replies. =)
> I understand what he tries to accomplish but I have doubts to protect the
> system in case of a failover. What I want mostly is to create a two-server
> system to resist most of the major problems ( an ddos attack, a cross-script
> attack, or any kinda intrusion ).  I know that nothing can resist to a
> long/complex ddos attack or all the open systems can be exploited in some
> way - there is always bugs - but I want to have maximum performance from a
> two-server setup with Wordpress. If you can read my hosting-master's plan
> and share your knowledge over this matter, I'll be more than glad.
> 
> " It's actually fairly simple.  More simple than the explanation you gave
> them.
> I don't see a problem with achieving both high availability and high
> performance.  I'm just a bit concerned about the auto-increment problem.  It
> may be simpler to use HyperDB than get into it.
> 
> Hyperdb may not be needed and might be counter-productive if the
> auto-increment problem can be solved gracefully.  Of course proponents will
> probably hotly disagree.
> 
> First of all, we will be using CARP, pfsync and ifstated.  Each server will
> have it's both IP addresses and traffic will randomly go to either server as
> a
> function of DNS.  What CARP, pfsync and ifstated accomplish are:
> 
> 1) CARP and pfsync allow both servers to have both IP addresses.  When both
> are available only one will answer on each IP.  pfsync monitors load and
> balances it by redirecting traffic to the IP on which fewer connection
> states
> exist.  In other words, the load can't help but be nearly perfectly balanced
> between the the servers when both are available because either of them can
> answer on either IP address.
> 
> 2) ifstated is for fail-over and monitors availability of services on ports.
> For example, if MySQL or Apache goes down on server 1, it will notify CARP
> and
> pfsync and the result will be that server 2 is now handling all traffic.
>  The
> switch will take less than 1 second and will be transparent to users.
> 
> The servers each have 2 1 GB network interfaces.  One to the Internet and
> the
> other only to each other, as a back-end.  pfsync uses the back-end NICs to
> exchange state information.  The back-end NICs will also be used by the
> MySQL
> Master-Slave process.
> 
> If each server is a slave and a master to the other one (having solved the
> auto-increment problem) then MySQL traffic stays on a server except for
> replication.  Only writes will need to cross an Interface.  In this case,
> HyperDB is not needed.
> 
> The potential advantage of HyperDB is that it simplifies things.  The setup
> can be such that MySQL on one server is entirely a master and the other
> entirely a slave.  No auto-increment problem exists.  The potential cost is
> that MySQL may consistently have more load on the master server.  HyperDB
> probably has the potential to mitigate this.  That's the question. "
> 
> Best Wishes,
> Mustafa Suphi Yilmaz
> http://paulocoelhoblog.com
> 
> P.S. Thank you Andy and Callum for your responses!
> _______________________________________________
> HyperDB mailing list
> HyperDB at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/hyperdb