On Sun, Aug 19, 2012 at 8:54 AM, Héctor Velarde <[email protected]> wrote: > hi there! > > we need to create many mounting points inside a Plone 4.2 instance to make > backups and clean up the database more easily; our customer will create many > content and we want to separate it on a monthly basis.
I would not recommend doing this. I do not know any large Plone installations where multiple Mount points are used inside of a Plone instance. I had a talk with Hector and here is the outcome: 1. If your database size is increasing; you need to know where/how it is increasing. The solution to this is installing collective.stats on production environments and running the analyzer -> CSV file and reviewing which operations are causing STOREs. Most importantly looking at how many objects ARE being stored when a STORE occurs. 2. zlibstorage is very useful and appears to keep database's fairly compressed (better than 40%) - this works well due to the fact many attributes are text based; especially HTML. 3. if your using mysql replication be mindful to replicate only the tables; you do not need to replication the entire database. just the core tables. 4. iirc mysql will not "reclaim" the database size. when you do a gc-based pack (which will take a long time). There are 3 types of packs: 1. pre-pack (usually takes 10 minutes) 2. pack w/o gc (acts on the pre-packed info; takes 3-4 minutes) 3. pack w/ gc (this usually takes many many hours) 5. you must lock the database when you dump. that means any read's will block until dump is complete. I will email the ploneconf2012 guys; if I can do a talk on all of the OPS side of running these sorts of configurations - I would be more than happy. > we know there's an old product called MountFolder made for Plone 2.0.5, but > I don't think it's a good idea to try to used it with our brand new version: > > http://plone.org/products/mountfolder/ dont use it. > http://svn.plone.org/svn/collective/MountFolder/trunk/README.txt I would update that and say "DO NOT USE THIS UNLESS YOUR A PROVEN ZODB GURU" > what are you currently doing to solve problems like this one? there is no "quick & easy" answer to database size. Like any "NoSQL" system - this is all based on application usage and configuration. cheers -- Alan Runyan Skype/Twitter:: runyaga Office:: 713.942.2377 ext 111 http://ploud.com/ Plone site in less than 10 seconds _______________________________________________ Setup mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-setup
