what happen to web application if database crashes and how to maintain site without user knowing it?

Building a .net web application, so I just want to know

• what开发者_开发技巧 happens to web application if database crashes?
• how to maintain site without user knowing what happened?
• how to handle the data entered by user?
• say if I use state management, in what way can I preserve data?

---

It all depends on how much effort you go to; for example, you could enable database failover, which tends to be expensive (second server, license, etc) but has a very quick recovery onto the pair. You could code your app to do something either in-memory (which gets tricky if your app recycles), or to an independent store.

The most common choice here is pragmatic: we need a DB (whether that is sql, nosql, or whatever; some central data repository); if the DB server goes offline, so does the app. You should be looking to have very good uptime on your DB tier; your time would be better spent trying to see how to improve that uptime.

Another choice for read only applications would be to keep a copy of the DB on each app-tier server, and update incrementally. When the app server is up, so (generally) is the local DB.

---

As Marc says, this is a big deal, and to be honest, I wouldn't rely on knowledge from strangers on Stack Overflow to form an opinion. Broadly speaking, hardware etc. are pretty reliable these days, and for relatively little money, you can achieve a very high level of availability (RAID drives, NAS storage, etc.). If you need higher levels of availability than you can achieve through this route, you're into specialist territory - you want the advice of someone who's done it before. It's also expensive - to go from 99.9% up time to 99.99% can easily double the cost of the solution. Halfhearted measures tend to make things worse, rather than better, by creating additional complexity in both infrastructure and code. Complexity is where the bugs live, and bugs reduce availability more effectively than hardware failure.

Having said that....

It all depends on how data-intensive your application is, how cacheable the application is, how complex the data is etc.

You can look at a clustered database - expensive, both in terms licensing/hardware and DBA time, but theoretically you could cluster across multiple data centres, getting close to 100% up time.

You can look at a messaging solution, rather than direct database access; message queuing solutions (Microsoft has one) are a fundamentally different way of architecting applications from the standard "ASP.Net app talking direct to a database", but can deal with huge volumes, and provide very high fail-over guarantees.

You can look at caching layers - having all your data in a cache might allow you to maintain the illusion of a working site even if the underlying database is off the air.