You can use chef for setting up the cluster and pull snapshots down for the data. That will require a 1 to 1 mapping between the prod and dev / QA clusters.
That way you can also test the DevOps processes for deployment and disaster recovery. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 12/01/2012, at 8:47 AM, David McNelis wrote: > Not currently using any of those tools (though certainly an option, just > never looked into them). > > Those tools seem more based around configuration of your environments...where > I'm more concerned with backfilling data from production to early-stage > environments to help facilitate development. Still DevOps at the end of the > day...just don't know if those would be the appropriate tools for the job. > > David > > On Wed, Jan 11, 2012 at 1:37 PM, aaron morton <aa...@thelastpickle.com> wrote: > Nothing Cassandra specific that I am aware of. Do you have any ops automation > such as chef or puppet ? > > Data Stax make their chef cook books available here > https://github.com/riptano/chef > > Cheers > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 11/01/2012, at 9:53 AM, David McNelis wrote: > >> Is anyone familiar with any tools that are already available to allow for >> configurable synchronization of different clusters? >> >> Specifically for purposes of development, i.e. Dev, staging, test, and >> production cassandra environments, so that you can easily plug in the >> information that you want to filter back down to your 'lower level' >> environments... >> >> If not, I'm interested in starting working on something like that, so if you >> have specific thoughts about features/requirements for something extendable >> that you'd like to share I'm all ears. >> >> In general the main pieces that I know I would like to have on a column >> family basis: >> >> 1) Synchronize the schema >> 2) Specify keys or a range of keys to sync for that CF >> 3) Support full CF sync >> 4) Entirely configurable by either maven properties, basic properties, or >> xml file >> 5) Basic reporting about what was synchronized >> 6) Allow plugin development for mutating keys as you move to different >> environments (in case your keys in one environment need to be a different >> value in another environment, for example, you have a client_id based on an >> account number. The account number exists on dev and prod, but the >> client_id is different. Want to let a dev write a mutator plugin to update >> the key prior to it writing to the destination. >> 7) Support multiple destinations >> >> Any thoughts on this, folks? I'd wager this is an issue just about all of >> us deal with, and we're probably all doing it in a little different way. >> >> David > >
