CI with Always on Availability groups ?

  • Im exploring the idea of both CI and 2014 Availability groups in DEV at the moment. current prod environment is 2008 with some legacy 2005 that needs uplifting before a move to 2014 in prod is implemented. so I have a little time to explore the options in dev. I think ill stick with traditional deployment into the prod environment.

    I'm ok with SSDT database project and TFS for source code control, but it then starts to get tricky.

    What would be best practice to set up a shared SQLdev & UAT environment that utilised CI into an AlwaysOn Activity group.

    Do you need to build to each node on check in and if so how do you handle data persistence across the nodes which will be different as data is replicated across the nodes from primary.

    Is it enough to Suspend data movement between nodes update primary and then resume data movement and can this be scripted?

    How are Object changes like new fields to tables and new procs deployed?

    Ive not seen this discussed in CI threads I've read to date. (any pointers appreciated)

  • colin Robinson-345240 (5/12/2015)


    Do you need to build to each node on check in and if so how do you handle data persistence across the nodes which will be different as data is replicated across the nodes from primary.

    You won't be able to, all nodes except the primary replica are at best read only. All relicas in an availability group will have the same data in the databases, they're replicas of the primary.

    Is it enough to Suspend data movement between nodes update primary and then resume data movement and can this be scripted?

    How are Object changes like new fields to tables and new procs deployed?

    Question is more, why do you need to do anything special? Any changes (data or structure) made to the primary will be transferred to the secondaries. Synchronously for the sync replicas and asynchronously for the read only replicas

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Gail,

    Cheers, thats the explanation i needed.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply