RAC increases points of failure

wolfop · 发表于 2014-3-22 11:20

mike79 发表于 2014-3-22 02:55
这个未必是忽悠。用了vplex，还将三个vote disk放在三个站点可能是有问题的：一旦中间链路断开，vplex可 ...

14秒的RAC不知道原因无法写存储已经可能有严重后果了，自己测试一下便知，尤其正好在写control file的时候

mike79 · 发表于 2014-3-22 17:22

wolfop 发表于 2014-3-22 11:20
14秒的RAC不知道原因无法写存储已经可能有严重后果了，自己测试一下便知，尤其正好在写control file的时候 ...

我测试过几次。不过不是因为这个，而是因为VxFS扩容。底下的盘太多了，将近两百个。每次扩容时候IO会挂起几分钟，归档以及数据文件的FS都有过，但奇怪的是数据库居然不宕。不知道什么原因，不过每次都提心吊胆。
而且我记得FC协议中是有一个20s超时的。在实际环境中也有类似事情，比如DS5K系列的主控宕了，切换到备控的时间在几十秒这个量级，IO挂起但是数据库不宕。

wolfop · 发表于 2014-3-22 20:14

本帖最后由 wolfop 于 2014-3-22 20:15 编辑

mike79 发表于 2014-3-22 17:22
我测试过几次。不过不是因为这个，而是因为VxFS扩容。底下的盘太多了，将近两百个。每次扩容时候IO会挂起 ...

单机还是RAC啊？而且关键要构造有写control file的情况。

mike79 · 发表于 2014-3-22 22:26

本帖最后由 mike79 于 2014-3-22 22:31 编辑

wolfop 发表于 2014-3-22 20:14
单机还是RAC啊？而且关键要构造有写control file的情况。

SF For RAC。生产环境，发现了这个情况以后肯定是在业务低谷时期作操作的，但是Oracle自己的增量checkpoint以3秒为周期定期写控制文件的。所以即使业务少的时候也是有写控制文件的。
另外想起来，以前做过同步PPRC的测试，PPRC链路断开时，对source LUN的访问也会被挂起，而且每次几乎都是20秒。在这段时间内，切归档操作也是被挂起，直到20秒过后source LUN的访问恢复了才结束。
不知道Oracle写控制文件是通过哪个系统调用。如果是write的话，那么write本身是没有超时的，只有依靠磁盘驱动程序或者系统层面参数的scsi timeout之类的来控制超时，超时的话write返回失败。如果是这样的话，数据库IO挂起十几秒而不宕也不是不可能。

Yong Huang · 发表于 2014-3-25 02:08

> 我记得FC协议中是有一个20s超时的

Can you find the reference? Could that be a timeout at the IP layer in case you use iSCSI, not a timeout in FC?