When I want to update my web server in the cloud I just ssh into my AWS instance and go into “screen” and just press Ctrl-C to terminate the web server. Is this dangerous in any way? My application uses websockets and database so is it possible the database could be corrupted this way if I don’t shut down the server gracefully?
I saw some people talking about this topic in this github issues and there are some third party packages for handling graceful shutdowns of servers, I am still lost as why I need this feature. If anyone could enlighten me of the benefits of graceful shutdown that would be great. Thanks.
The main benefit is usually in graceful restarts, that is stopping the old code and starting the new without dropping active connections or refusing connections in the interval between. If you’re not bothered by that, a ^C shutdown should be fine. Database consistency etc is something that you need to handle by transactions and so on regardless.
Okay I see. I have a lot of data stored in memory as well so I would probably have to store that to the database when I initiate a graceful shutdown. And then when I restart the web server I can just fetch the information from the database and put it back in memory and the users can resume back to what they were doing on my site with the data?
Yes that is true. The reason why I keep it in memory as the data is expected to be called/manipulated by users many times in a short period of time. I didn’t want to suffer any performance penalties so I placed the data in memory.
I am debating on whether to save the data in memory in the database every time the data in memory changes in case of a crash. This will be extra overhead to my database and the data is not sensitive or critical like a bank application, more along the lines of entertainment.
I don’t know enough about what you’re building/designing, but Redis could be a good (fast) temporary cache. Saying that, persisting to DB may not be appreciably slower.
You might want to also look at using a “proper” process monitor (systemd, supervisord, runit) instead of screen to handle logging/restarting/etc
How about a defer statement immediately after opening the database, which calls a method that writes the memory-cached data back to the database then closes the database?
Sure, you’ll still lose cached data on an actual panic, but it’s not clear to me that it’s a good idea to write back data that caused a panic anyway…
