[HyperDB] Replication and Failover - v.2

[Mustafa Suphi Yilmaz]

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!