On Sat, Feb 1, 2014 at 2:27 AM, Boaz Citrin <[email protected]> wrote:
> @Jason - the purpose is that compaction will not catch up with heavy > write rate and will affect performance. > If compaction will not catch up with your writes, then you do not have sufficient hardware resources. You are operating in a very high-risk environment. Replication in lieu of compaction is papering over a deeper problem. You may have a strong threat of consuming all of your filesystem space or i/o bandwidth is high. Consider upgrading to faster SAS or SSD storage. Of course, you know your situation better than I do. Maybe you have good reasons for your specific situation. But the above paragraph should be a pretty useful rule of thumb. So I replicate/copy to a side database, compact it, then replicate the > new changes from the original and switchover. > I do not understand. If couch can compact the side database, then it can compact the primary database. The compaction code is doing everything you describe, except automatically, without external direction, and with plenty of debugging over the years. I encourage you to tested and confirm whether compaction can not catch up with your heavy write rate? Of course if you have working code in place now, then hey CouchDB is relaxed. Keep using what works! :)
