In previous places I've consulted or worked at we've never started a production database at boot time --- for many reasons --- hardware issues during boot time causing corruption, unstable net connections to the database comm issues -- the list goes on --

If a server reboots due to an outage i don't want my database server, which is part of a database farm, to start up automatically until I've checked the system and db consistency.

What are your thoughts on this? -- I'm being told starting a db at boot is the "Right" thing to do and I fully disagree.

  • I've not run into any issues in the SQL Server world. – jl. Oct 26 '10 at 18:50
  • Please list, in excruciating detail, what steps you take to "check[] the system and db consistency." Please list the success and error conditions for each step, to determine whether you would start the DB. If any of those could be automated, script them. – mfinni Oct 26 '10 at 19:24

Personally, I don't know why you wouldn't want it to start at boot. My answer deviates slightly from the MySQL tag and talks about databases in general.

When you say you want to check consistency - is this for physical corruption or logical corruption? If something's physically corrupt, there's a very good chance it won't start anyway. If it's logically corrupt, unless you have a specific maintenance program that knows the structure of the database and what relates to what, I think you'll have a hard time manually ensuring it's logically consistent (by that I mean transactionally consistent). If the database is any good, it will do some form of transaction logging anyway to guarantee transactional consistency.

If you have hardware that corrupts things (but only on boot) you have bigger problems which need to be resolved. Equally if you have flakey network connections, you have other problems. Networking starts very early in the OS loading process, and once it's up it stays up until told otherwise.

Think of what happens if your Exchange server or SQL Server reboots at 3AM on Saturday morning and for whatever reason you are unable to get to the server and start the databases manually. Until you tend to the server, it won't accept emails or your website is down for hours when it could be up and running again by itself in the time it takes the server to reboot.


That all depends on the database, really. There are risks with either option. By not starting up services as quickly as possible, you may risk upsetting users or breaking an SLA. By starting the database automatically, you risk putting the database in a worse state than if you'd taken the time to make sure everything was in order before starting services.

In my experience, uptime is everything. A list of potential issues won't console an unhappy user when their services are unavailable. However, I do understand your fear that the situation be made worse by blind action.

That said, there's no reason you have to act blindly. If you have a list of system/database checks you'd perform before declaring the database safe to start, consider adding them to your database or application startup scripts. This way, if the checks you would perform manually are all successful, your users aren't waiting for you to get to your computer. If some step fails, then log in and fix it by hand.

  • Excellent point about scripting those checks- I flagged the same idea in my comment to his question. – mfinni Oct 26 '10 at 19:25
  • Thanks guys for the responses I need to put a little more thought into this before I come back with a response to some of your comments. – user58345 Oct 26 '10 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.