Paul Cotter wrote:
> [OT] - but...
I disagree somewhat about OT; I see your point but, I want to use this
class specifically in mod_perl handlers. Also, clustered servers are
definitely on topic, I think.
> Do not throw out database replication as a solution.
I remember a previous discussion way back on this list comparing
performance differences between filesystem and database performance.
I believe an eight-fold performance advantage for filesystems was
found. While no benchmark applies directly to anything in the real
world, I can use a clear performance advantage like this.
> Even simplistic methods such as replacing all updates with stored
> procedures that can update across multiple data-bases (eg Oracle Sybase etc)
> will have problems. If you wish to separate the servers geographically then
> loss of network will cause problems unless you adopt a store-and-forward
> basis.
I'm not considering geographical separation, fortunately. But couldn't
that be handled by copying the total contents of the data store from a
peer, assuming a small (< 2MB) data store and a fast (100 Mbps) network,
plus queuing incoming updates while the copy is in process?
> One method that has a reasonable level of success is a transaction log
> analyser. Updates (as opposed to reads) are applied to a single server and
> the transaction log analyser applies them to the other servers. However, for
> ease of creation and maintenance a publish-and-subscribe replication system
> is easiest. Remember that only certain data need be replicated. I have tried
> in the past to extract to cached flat files for performance. At the end of
> the day it is usually cheaper to go out and buy more hardware.
I'm working in an environment with a very high write to read (.7 to 1)
ratio. I like MySQL database replication, and it will remain part of
this project. I just think it makes better sense to use something else
with the 2 small data stores I'm dealing with, which have a few thousand
records each, and get updated many times a second during peak traffic.
--Christopher
