[consulting] Drupal server requirements

Michael Haggerty mhaggerty at trellon.com
Wed Mar 29 19:43:06 UTC 2006


This statement is misleading. There are plenty of ways to set up a MySQL
cluster that require no coding at the application level, which can handle
operation segmentation entirely within the cluster. There are also a lot of
3rd party database clustering applications available right now that offer
even more granular levels of control over database operations.

If you want to do it entirely in MySQL, take a look at NDB clusters. There
are limitations there in that your database pretty much needs to be memory
resident and recovering from a node failover can take a lot of time. But you
certainly gain advantages in terms of updates and writes even in a highly
utilized environment. At the application level, you connect to one database,
ever, period. 

This is a good strategy for cutting down on read floods, because data is
written to one node and 'replicated' over to other nodes as operations
permit. If you are working over an SCI interface and using InnoDB or MaxDB
tables, replication should be a millisecond operation.

If you are looking for a clustering solution that lets you specify which
nodes are actually written to, further segmenting operations beyond this
level, there are a number of 3rd party products which give you this kind of
functionality. (And they are all fairly cheap, too.) 

http://www.continuent.com/

http://www.insession.com/goldengate/

The big thing to remember is most people using Drupal are NEVER going to run
into race conditions in their database, and a clustering solution is
inappropriate for about 99% of the Drupal sites out there. Let's face it,
adding hardware or upgrading a server is probably the most efficient
solution to dealing with database bottleneck problems and probably cheaper
than spending the man hours implementing a cluster. 

When you get into that 1% category where you do need to deal with millions
of hits a day, clustering is definitely something to consider. Something
important to remember though is that applications are good at somethings,
and databases themselves are good at others. To that end, trying to support
clustering at the application level is probably not a good idea, because no
application is going to support all types of database configurations and the
solutions you are going to be able to build are going to be highly dependent
on specific architectures, thus reducing their viability in general (imho).

The real problem is expectations - so many people want to just install
Drupal and have it instantly address problems that really require non-code
level solutions. Forsaking thought about the environment with the
expectation that the code is going to solve the problem is unrealistic.

M


> -----Original Message-----
> From: John Handelaar
> Sent: Wednesday, March 29, 2006 8:06 AM
> To: A list for Drupal consultants and Drupal service/hosting providers
> Subject: Re: [consulting] Drupal server requirements
> 
> Did you take a look at mysql.inc ?
> 
> Drupal doesn't distinguish between read and write operations.
> 
> You can't cluster MySQL apps which don't understand how.
> 
> -------------------------------------------
> John Handelaar
> 
> E  john at handelaar.org    T +353 21 427 9033
> M  +353 85 748 3790    http://handelaar.org
> -------------------------------------------
> Work in progress: http://dev.vocalvoter.com
> -------------------------------------------



More information about the consulting mailing list