|
Peter Koch wrote:
>
> >If you just want to make a database system of 2 nodes highly available.
> >You can have a look at http://www.linux-ha.org/ for heartbeat code, the
> >primary database server and the backup can heartbeat, if the primary
> >fails, the backup will take over the db service.
>
> Thanks, but I've looked at this site and I am still a little confused about
> the options for the database. I can use the heartbeat and fake methods
> to build a redundant load balancer for the farm, but currently for redundancy
> it assumes that the real servers don't persistant any state (or the client
> would
> need to go back to the same PC).
>
Well, I don't understand your last statement fully. As for database
transaction, the ACID property can guarantee that once the
transactions is committed, it is committed in persistent storage (or
data files). Even if the current database fails, some temporary data
is lost and transactions are aborted, but the committed transaction
result can be seen by other database server (we assume global storage
here), and clients can send the transaction requests to the surviving
database servers.
> Is there any white papers, or documents on my options. As far as I can see, I
> either need to run a database on each real server and set up a (complex?)
> distributed database synchronisation and lock manager (How much resourcing
> would this tie up to keep all databases in sync, and wouldn't this negate any
> benefit of the load balancing? (althoygh it would be redundant in a failure).
> Or,
Sure, the distributed lock manager should be light-weighted (for
efficiency) and fault-tolerant.
> is there something I'm not seeing - what is this shared-access RAID type
> server,
> is this where all server's in the farm share access to a database machine. If
> so, then is this going to be a bottleneck for the farm (my application is
> pretty
> much a big data warehousing system).
>
Sure. For a big system, you should compromise all the performance of
sub-systems, and try to avoid a bottleneck of sub-system as far as you
can. ;-)
> If all these databases need to be kept in sync (or atleast 2 if I have a
> dedicated
> server and a backup) then what is everyone using for local interconnects?
> 100Base-T,
> or something faster since this would be a lot of traffic?
>
Well, if you have two nodes (one is the backup of the other for
redundency, and no load balancing here), you can use a shared disk
array between two nodes, so there is no need to do synchronization.
Then, you can run heartbeat on the two nodes, if the primary fails,
the backup takeover the IP address and start the database services.
Wensong
> Thanks for any additional advice,
> Peter
>
> ----------------------------------------------------------------------
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
