Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I want to set up a staging server to do final test for my website. The staging site's database is replicating production master mysql db in order to reflect a real environment.

If a deploy only contains code changes, it's easy to deploy it first to staging and then to production if it's stable enough.

But if a deploy contains database changes, how can I deploy it to staging without influencing master's database but still keep it realtime sync with master db?


Edit:

If it can't be done. How can I make the data write to staging server 'not lossing'? If some user use the beta site, I don't want their data be lost when staging finally became stable.

I wonder how facebook or google roll out their new features without losing beta tester's data?

share|improve this question
2  
How can I keep two things the same but make one of them different? How can I have my cake and eat it too? –  joeqwerty May 11 '12 at 14:29
    
@joeqwerty Paradoxes can be mind expanding. You know, like Zen koans or Taoist parables. –  cjc May 11 '12 at 14:45
    
@lxyu: they have more magic than you. Well, they have more engineers, and they've already architected their infrastructure to allow them to do that sort of thing through various database partition schemes. Since you're asking this question, we're going to assume that you haven't architected your site in this fashion. –  cjc May 11 '12 at 15:11
    
@cjc, ok, then are there opensource frameworks to do stuff like this? or some examples or guides to follow? –  lxyu May 12 '12 at 13:52
    
Second edit to my question references some SO questions dealing with this. My quick skim of the answers suggests that the summary is, "It's a hard problem." –  pjmorse May 12 '12 at 14:29

1 Answer 1

up vote 8 down vote accepted

You can't.

My suggestion is to not replicate production to staging, but to occasionally rebuild the staging database with one of your production backup files. Then you're working with production data (albeit a few hours or days old) but changes you make on staging won't affect production.

EDIT: With your edit, this is now a significantly different question.

If you have beta testers using your staging server and expecting their data to roll into production, it's not a staging server: it's a production server. I think that's the fundamental concept shift making this difficult to answer; most of us (I think) consider a staging server to be an etch-a-sketch that can be dumped and rebuilt without fear. If you're planning to allow some users to beta-test your changes and retain their data when you roll into production, you need a different framework than staging/production.

EDIT2: Here are some Stack Overflow questions that deal with this sort of setup:

share|improve this answer
    
ok, seems I misunderstand what staging server means. I'll reconsider it then. When refer to 'a different framework', can you give me a name? –  lxyu May 12 '12 at 13:54
    
No, I can't; I haven't worked that way myself. "Different pattern" might be a better way to put it. You might consider looking in to A/B testing; that's intended for a somewhat different problem (seeing how users respond to interface changes) but it might help. I think I'd call what you want a "segmented" or "gradual rollout" but I don't know if those are the formal terms for it. –  pjmorse May 12 '12 at 14:19
    
Actually, "What is it called when production features are rolled out gradually?" might be a reasonable question, although I suspect it's more of a Stack Overflow than Server Fault question. –  pjmorse May 12 '12 at 14:21
    
Thank you very much, I'll check that. –  lxyu May 12 '12 at 14:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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