在启动时启动生产数据库--

在启动时启动生产数据库--

在我以前咨询或工作过的地方,我们从来没有在启动时启动过生产数据库 --- 原因有很多 --- 启动期间的硬件问题导致损坏、与数据库通信问题的网络连接不稳定 -- 诸如此类 --

如果服务器由于中断而重新启动,我不希望我的数据库服务器(作为数据库场的一部分)自动启动,直到我检查系统和数据库一致性。

您对此有何看法?——有人告诉我,在启动时启动数据库是“正确”的做法,但我完全不同意。

答案1

就我个人而言,我不知道为什么你不希望它在启动时启动。我的回答与 MySQL 标签略有不同,并且总体上谈论了数据库。

当您说要检查一致性时 - 这是针对物理损坏还是逻辑损坏?如果某个东西物理损坏,那么很有可能它无论如何都无法启动。如果它是逻辑损坏的,除非您有一个特定的维护程序,知道数据库的结构以及与什么相关的内容,否则我认为您将很难手动确保它在逻辑上是一致的(我的意思是在事务上是一致的)。如果数据库很好,它无论如何都会进行某种形式的事务日志记录以保证事务一致性。

如果您的硬件损坏了系统(但仅限于启动时),那么您将面临更大的问题,需要解决。同样,如果您的网络连接不稳定,那么您将面临其他问题。网络在操作系统加载过程的早期就开始了,一旦启动,它就会一直保持启动状态,直到另行通知。

想象一下,如果您的 Exchange 服务器或 SQL Server 在周六凌晨 3 点重启,而您出于某种原因无法访问服务器并手动启动数据库,会发生什么情况。除非您照看好服务器,否则它将无法接受电子邮件,或者您的网站将停机数小时,而服务器重启后它本可以自行重新启动并运行。

答案2

事实上,这一切都取决于数据库。无论哪种选择都有风险。如果不尽快启动服务,您可能会冒着惹恼用户或违反 SLA 的风险。如果自动启动数据库,您可能会冒着让数据库处于比在启动服务之前花时间确保一切正常更糟糕的状态的风险。

根据我的经验,正常运行时间至关重要。当服务不可用时,列出潜在问题并不能安慰不满意的用户。但是,我确实理解您担心盲目行动会使情况变得更糟。

话虽如此,你没理由盲目行事。如果你有一份在宣布数据库可以安全启动之前要执行的系统/数据库检查列表,请考虑将它们添加到数据库或应用程序启动脚本中。这样,如果你的检查手动执行的所有操作都成功了,你的用户就不会等你去电脑前。如果某个步骤失败,然后登录并手动修复。

相关内容