Posted by melficeful on December 2, 2012 at 8:45am
Hi everyone.
My Drupal site is an aggregated site.
Through out the years, my drupal database has built up quite a large database (>500mb). node_revision is the table that has the most data.
Is there a way to separate the nodes into different databases in order reduce the size of my drupal database?
The aged nodes are still valuable thus deleting them is not an option.
I have thought of using multisite module to move the aged nodes to another database. But this approach doesn't work in my case since my nodes still have to interact with each other in certain level.
Thank you for reading.
Comments
It slightly depends on the
It slightly depends on the reason you need a smaller db. One obvious question arises whether you can delete some of the revisions. As you are on D6 there is a module for this job http://drupal.org/project/revision_deletion. Another point is that if the db is big you can make them smaller by utilising Drupal's swappable caching system to use different storage for the cache.
Digit Professionals
Hi John_B, Thank you for your
Hi John_B,
Thank you for your suggestion about the revision_deletion module. I have installed it and run it.
Since most (99%) of the nodes are auto-inserted by my php scripts, so the revision_deletion module had helped a little bit.
I'm very interested to read more about Drupal's swappable caching system. Is there a link so that I can read more about it?
I was thinking to use multisites with the sub-folder approach to move all the aged nodes to the new site with the same theme.
There are some Lullabot blog
There are some Lullabot blog posts about caching e.g. http://www.lullabot.com/articles/a-beginners-guide-to-caching-data
I don't like multi site. Probably more trouble than it is worth.
Digit Professionals
Finally I ended up writing a
Finally I ended up writing a php script to move the body($node->body) of the aged nodes to a new database.
Then update the node body with a php function call to retrieve body from the new database.
I'm not sure if this is a good practice, but it reduces the size of drupal database dramatically.