在过去的四天里，在夜晚的某个时间点，两次网站都会closures，因为服务器无法连接到数据库。 在这一点上，一切还在运行（apache ect）只是数据库已经死了。
当我用rootlogin到ssh进行调查时，我已经读取了只读的权限，这是我怀疑mysql服务器死机的原因。
我已经检查了mysql日志，系统日志，基本上我可以find每个日志文件，在问题开始时（或者甚至整个一天），没有任何东西显示任何错误。 这就像一个开关只是翻转，然后我重新启动系统，事情又好了…直到几天后？
最后一次发生了免费公羊2G，第一次1.5G免费。 最小的CPU使用率（<30％）。
有任何想法吗？
磁盘错误是“我只读的权限无处不在”条件的一个可能的原因。 某些types的硬件或内核级别的磁盘故障可能会导致文件系统不一致和损坏，因此内核会在检测到这种故障时保护性地强制文件系统进入“只读”模式。 如果包含根文件系统的磁盘出现打嗝，试图写入磁盘的任何内容都将开始出现许可错误。 不需要写入磁盘（如Apache或SSHd）的程序可能会继续正常工作。
下一次发生数据库故障时，请检查内核日志消息缓冲区BEFORE YOU REBOOT之前是否有任何磁盘错误的指示。 您可能必须使用'dmesg'命令，因为如果您的'/ var / log'目录是根文件系统的一部分，syslog守护进程将无法将错误消息写入'/ var / log /消息'文件在磁盘上。 此外，重新启动时内核日志缓冲区的内容将会丢失，因此您可能需要使用“ssh”或“scp”将数据复制到别处。
我有同样的问题。 它看起来像文件系统被设置为无故只读，那里（显然）不是日志文件中的任何东西。
我们用“我们不支持linux”的硬件厂商花了好几个月才解决了这个问题。
我最终发现了RAID控制器上的固件错误。 当它遇到错误时会降低arrays的性能，RAID上的ext3文件系统只能被内核读取。 一个固件升级修复了这个bug，而且服务器每隔几天就被剥离出来，变得坚如磐石。
注意：如果您正在运行MegaRAID卡，请安装MegaCli软件包并使用它来检查事件日志。
我发现这个文件非常有用。