好久没干活了，今晚痛快了一把。
话说正在看新版《三国》第三十六集的时候，接到电话说武汉平台工程师在HPUX下配ORACLE RAC，建库的时候遇到问题，无法使用裸设备文件。具体原因是好几个共享卷组里面的字符设备丢失，导致操作无法进行。
这里首先要介绍一下块设备和字符设备的概念，网上摘录如下：
块设备（block device）：是一种具有一定结构的随机存取设备，对这种设备的读写是按块进行的，它使用缓冲区来存放暂时的数据，待条件成熟后，从缓存一次性写入设备或从设备中一次性读出放到缓冲区，如磁盘和文件系统等。
字符设备（character device）：这是一个顺序的数据流设备，对这种设备的读写是按字符进行的，而且这些字符是连续地形成一个数据流。它不具备缓冲区，所以对这种设备的读写是实时的，如终端、磁带机等。
字符设备是裸设备，通过查看ll /dev/vg00/下的内容，若开头带c字符的则为字符设备
块设备是文件设备，通过查看ll /dev/vg00/下的内容，若开头带b字符的则为块设备
字符设备驱动程序直接从用户进程传输数据，或传输数据到用户进程；块设备是内核为它们提供缓冲的磁盘设备。
基本概念介绍完毕，下面再具体说一下当时的情况，接到电话的那一刻，我第一反应是在建LV的过程中出了问题，造成部分字符设备的丢失。LV出了问题怎么办，删了重建，但是这个过程比较复杂。首先，双机已经跑起来了，ORACLE CLUSTERWARE和ORACLE DATABASE软件也已经安装完毕，就差最后这个建库过程了。裸设备是存在于共享卷组当中的，而且裸设备做了条带化操作。如果要重建LV的话，必须经过下面这番步骤：
1，cmhaltcl命令停掉双机；
2，在主节点上取消共享卷组的cluster属性；
3，在副节点上对共享卷组做vgexport操作，删去之前import过来的卷组信息；
4，在主节点上删除有问题的LV，并重建LV；
5，重新对新建的LV进行条带化操作；
6，将export出来的共享卷组信息再vgimport到副节点上；
7，启动双机，激活共享卷组；
8，这才是建库的操作。
好玩就好玩在这个地方，正在我计算做完这些操作需要多长时间的时候，对方工程师给我说有一个节点上的字符设备没有丢失，有一个节点上的字符设备丢失了。我问对方是主节点上的部分字符设备丢失还是副节点上的部分字符设备丢失，如果主节点上的字符设备完好，那么有可能是在import卷组信息到副节点的过程中出了纰漏。但因为之前的操作是另一个工程师做的，所以他并不清楚谁是主节点谁是副节点。
沟通交流到这个地方，我突然想起之前貌似遇到过类似的问题，也是部分字符设备丢失，通过重建部分字符设备就能够解决。想到这里，豁然开朗。这样一来，不用删除LV更不用重复条带化过程了，那么就节约了很多时间。解决方式是只需要在缺失部分字符设备的节点上通过mknod命令重建字符设备即可，省掉了条带化操作、VG的export/import操作，节约时间大大的有。
下面说说具体过程：
1，停掉双机；
2，随便选取一个节点取消共享卷组的cluster属性；
3，通过“mknod”命令重建丢失的字符设备，比如说我这里的vgpmcs11卷组下丢失了字符设备rr06G1001，对应的块设备属性如下：
brw-r----- 1 root sys 64 0x020009 May 19 15:53 /dev/vgpmcs11/r06G1001
那么这里建立字符设备的命令就是mknod /dev/vgpmcs11/rr06G1001 c 64 0x20009
4，修改新建好的字符设备的权限和属主；
5，启动双机；
6，启动包（如果不能随双机启动的话，可以通过cmrunpkg进行启动）；
7，启动共享卷组（vgchange -S y -c y vgxx， vgchange -a s vgxx）；
8，仔细检查主、副节点下共享卷组状态是否正常，检查是否有字符设备丢失，确认无误之后，方可进行下面的步骤。
到这个地方，故障就解决了，比之之前所预想的方法要简单很多，也节约了大量的时间。这里的教训就是在卷组export/import之后定要观察其中文件状态是否正常，是否像今天这样有字符设备丢失现象发生，确认无误之后再进行后面的操作。
虽看掉一集《三国》，但得经验至此，也算小有收获。
阅读(6458) | 评论(2) | 转发(0) |
