Skip to content
Advertisement

Prevent operational risk with SQL-dependent architecture

I am currently working on a very critical tool, which has a strong dependency to a MySQL database. This particularly means that if the SQL server goes down some day, all users won’t be able to use the application, since it is retrieving their configuration stored in database and launches components defined in DB, and a configuration is absolutely required for the tool to be launched.

I was therefore wondering what were my options to limit this risk, ie. make the application functional even if the database is down. Should I define a fallback database for example? It is the first time I work with such a critical aspect and I haven’t been introduced to this kind of risk-management.

Any insights would be welcome

Advertisement

Answer

It’s not the app’s responsibility to implement fail-safe SQL backend. The app should check wheter the SQL server is running, and if not, it may retry the last SQL statement for a while, and print out a sad message in red if failed. If there are more SQL servers (hotswap or something), the app may switch automatically between them. That’s the maximum an app would do in this topic.

I think there are lotsa solutions and ideas for setting up a fail-safe SQL server or farm, but it’s out of scope (I mean programming).

User contributions licensed under: CC BY-SA
5 People found this is helpful
Advertisement