4

I have a site with very high volumes of data (1000+ nodes per day * 3+ years and growing each day). When we need to create a development snapshot of this database it takes FOREVER to import it.

I know this is a long shot, but is there a way to export this database without our node data? Specifically which tables can we excise?

I know as we add more and more custom modules, more and more things will break when we do something like this. But let's say we are just using Drupal 6 core modules with CCK. Would it be possible then? If not, what would we break by doing this and could breaking it be fixed?

3

Could you just export the db in a typical fashion? Via PHPmyadmin or command line?

Also, Backup and Migrate lets you choose to export table structure without data.

  • I can, and will. My problem is that when I export, the mysqldump is 2.8 GB and takes 6+ hours to import into a dev box. Most of this is stuck in the Nodes. I don't need all of my content, but I do need the data in Blocks, Views, Taxonomy, etc. The basic structure of the site. I've tried using Features and other modules to put all this in config files, but it's never enough. I really need to be able to identify what tables are necessary for nodes, and what is needed for other functionality. – decoy Oct 12 '11 at 13:52
  • 2.8 GB? is it uncompressed? what exactly is stored?! – anonym-developer Oct 13 '11 at 16:02
  • 2.8GB compressed actually. :) It's a news site. Large number of stories. Not a lot of long stories. So each node isn't very big, but the number of nodes is huge. – decoy Oct 13 '11 at 16:15
0

I actually discovered AN answer to my problem. But I won't give myself the check, because it doesn't answer the core question of "What tables can I lose if I don't care about node content?".

We found a way to copy the binary data itself. Wasn't much documentation on this method though. It DOES require you have root on the box you are working on though. Specifically what we do is:

# /etc/init.d/mysql stop
# cd /var/lib/mysql
# tar -czf mydb.tgz mydb
# /etc/init.d/mysql start

This creates a backup of the binary data itself. Then we move that tar over to our dev box and do:

# mysql -u root -p
> CREATE DATABASE mydb;
> QUIT;
# /etc/init.d/mysql stop
# cd /var/lib/mysql
# rm -r mydb
# tar -xzf mydb.tgz
# /etc/init.d/mysql start

The database won't know the difference. This GREATLY speeds up the time it takes to move very large databases from one box to another.

Hope this helps someone else. But I definitely still want an answer to the original question. Thanks to everyone who is helping!

0

Here is Entity relationship diagram might be helpful
https://drupal.org/node/1785994

Drupal 7 core tables:
https://www.drupal.org/node/2360815

  • Hi and welcome to Drupal Answers. Could you please improve your answer by providing more in-depth detail on the key-points of your links and how them can help to answer the question. – Wtower Jan 13 '15 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.