Basic caching and database transaction logs
Hello,
I'm looking for any feedback or insight into the area of database replication for a cold-swap Drupal (5.x) site. This is my situation:
We are trying to incorporate real-time updates between two servers so we can have a cold swap if the main production box goes down. The proposed (and to this point accepted) solution is to use a binary transaction log of the mysql database to keep them in sync and also to propagate down to our testing servers from time to time. What we are encountering is that the amount of activity through our database is bloating the transaction logs to well over 15 GB per day. Our server is not equipped to support this amount of data buildup.
We've noticed that a large amount of it was coming from Drupal's caching system. Every UPDATE, INSERT and DELETE is being captured. We do not have normal caching turned on, but the amount being written into and read from the cache table is still one of the largest sources. One recommendation was to stop caching completely, which I am opposed to for a number of reasons, one being hacking core to intercept the requests.
Can anyone lend some insight to a cold-swap solution, reducing the transaction log size or caching on vs off?
Thanks,
Chris


Ical feed
alternate group?
This may be more appropriate (and therefore get more responses) in the High Performance Group.
If you need high performance and want to eliminate the cache related queries at the same time, consider memcache.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
Thanks
I had no idea that group existed. Looks like there are some good potential solutions there. Thanks, Greg.