7

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?

4
  • @joeqwerty Paradoxes can be mind expanding. You know, like Zen koans or Taoist parables.
    – cjc
    May 11, 2012 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, 2012 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, 2012 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, 2012 at 14:29

1 Answer 1

13

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:

4
  • 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, 2012 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, 2012 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, 2012 at 14:21
  • 1
    Upvoted because you tried (and succeeded) to be helpful instead of just complaining (like I see here so much on SO!) Keep it up! :)
    – rinogo
    May 24, 2016 at 0:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .