Hi,
Not sure that deciding "dynamically" whether database is in read-only mode or not during runtime is good idea. There are code fragments that reacts on database mode located in initialized modules. Changing database mode "dynamically" during runtime - might break something or eventually set application / data in incorrect state.
What is the issue related to recycling? What you are willing to avoid?
Hi Valdis,
It might be a non-issue since in a load balanced environment the visitor would not experience any issues with this. But it does not feel good to recycle the website to set this.
My main question however was the routines for deploying to a load balanced environment. :)
This is most interesting topic and I am following this up and hope to hear your experiences.
My road has always been the boring...we don't do that :)
Updating database schedule on the fly automagically starts all sorts of nervous reactions in my poor developer body...
Hi @Alf,
did you experiment with evaluation of IDatabaseMode after initialization? Any thoughts?
I have the same approach in mind. I want to avoid the hassle and time during my deploy just to enable readonly mode.
But if it's not supported...
Kind regards,
bob
Hi Bob,
I did some experiments but there are quite alot of things that are depending on this that is defined in initialization.
I have not had time to setup the automated deploy for load balanced environment yet but this is my idea:
Hi Alf,
thanks for the quick response!
For the moment I deploy to an app service, which scales if necessary. So it's not possbile -as far I know- to take one node down, alter settings and bring back into the loadbalancer.
If I want to support this scenario, I complicates my release / (ARM) deployment a lot.
But as excpected, changing the value at runtime is not recommended.
Hi,
We're setting up a load balanced environment with one of our clients that has the most active release schedule.
We're using an automatic deployment tool where we can disable one node in the server farm to make a deploy while the other one(s) continue serving traffic.
This sounds quite straight forward until we add another thing into the pot: keeping up with the Episerver updates!
Currently Episerver does not count a change in the database schema as a major change, therefore there could be database changes with each weekly update.
And for each update in the database Episerver increments a version number that is stored within a Stored Procedure. Episerver also checks this version at startup to ensure that the database version is correct.
Are there any good plans how to handle this with the automatic deployments?
Should we take inspiration from the deployments in DXC with the following steps if we don't want a downtime when upgrading?
This list is given that we only have 2 nodes in the farm and that every step is successful so we don't need to rollback.
Of course we also consider having routines where we health check each node before putting it back into the load balanced farm, but we keep the following list simple for the example.
I'm not so keen that Node A needs to recycle to be set in Read Only mode!
Even if we would let Node A use the original database and Node B use the copy for upgrading, Node A still needs to recycle as the Read Only mode is set with a change in web.config.
I'm thinking of implementing my own IDatabaseMode that will identify whether Read Only is enabled by reading something else than web.config. Will that do any harm as the website needs to initialize before I can replace the original implementation with my own?