我有几个有关RAID 5，BBWC（电池备份写caching），文件系统（ext3）和可选的MySQL的问题。
我有一个假设，我要求服务器故障社区validation或不这一个：
有了这个解决scheme，当操作系统收到写入确认，数据可能在RAID控制器caching中，而不是在持久性内存（我的RAID驱动器磁盘）。
如果出现电源故障并且数据位于RAID控制器caching中，则BBWC会使用电池组保存数据。 在此之前，一切都很好。
但是电池有一定的容量，并不是无限的。 如果停电时间超过两三天，则RAIDcaching将丢失。
对我来说这是一个戏剧性的，可能的情况。
我的问题是：
硬件 ：HP DL380 G7
操作系统 ：与ext3的Centos 5
是的，这是电池支持的写入caching的限制 – 如果电池电量耗尽，您的未写入的数据是烤面包片。 这就是为什么我更喜欢更新的基于NVRAM的RAID控制器。 文件系统不能帮助你，因为他们认为数据是被写入的 – 至多他们可以提供一个一致的数据视图，而不是确保数据是最新的。
你需要多less电力中断/中断？ 电池有几天的寿命。 但是，自G7 ProLiant服务器以来，使用闪存备份caching（FBWC）单元变得越来越stream行。 如果您的Smart Array P410控制器还没有，那么这是一个直接的改进。 这个技术在这里有更详细的描述 。 FBWC单元中的超级电容器的要点是提供足够的功率来将写入caching内容写入闪存，在那里它将一直持续到系统电源恢复。 另一个好处是没有电池处理和处理。 所以从制造商的angular度来看，推广使用闪光灯和旧式电池是有好处的。
我认为，如果停电时间足够长，以至于电池寿命也是一个问题，也意味着还有其他基础设施问题需要担心。 同样的事情，如果有人不在现场提供电力救济。 我们的build议是通过稳定的UPS解决scheme来保护您的系统。
至于caching中包含的数据量，通常都很小。 在你的情况下，caching可能是512MB或1024MB。 随机和stream媒体写入需要足够长的时间，直到它们被刷新到磁盘。 在任何时候，你可能都在看几兆字节的数据。 突然崩溃后，caching数据丢失（RAID电池故障）后，我没有发生重大损坏。 除非系统的写入模式exception沉重，并且以意外的方式同时失去电源（如雷击），否则这可能不会成为您的问题。 虽然ext3很有弹性。
你应该得到一个UPS，这样服务器可以正常关机，而BBWC根本不需要使用。 即使是一个相对较小的UPS也可以提供几分钟的关机时间，这通常足以将这些caching刷新到磁盘。
闪回支持写caching可以帮助，但我认为大多数人会同意UPS是一个更好的主意。
一个更昂贵的select：你可能要考虑得到一个发电机，如果你通常经历3天以上的停电。 我发现这种事情很less见，但我看到你在池塘边。
感谢您的回应。 我知道替代scheme，比如FBWC，但我的问题是基于我的情况：
在我的工作上，我们已经部署了这个解决scheme，我必须预见到问题。
你觉得mysql可能被破坏，并拒绝从我的场景开始？