ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

CentOS 7.5部署Oracle 19c RAC全流程:从环境准备到避坑实战

CentOS 7.5部署Oracle 19c RAC全流程:从环境准备到避坑实战 简介这是一份面向数据库工程师、软件工程师及数据库学习者的完整实操教程以VMware虚拟化平台为基础系统讲解CentOS 7.5环境下部署Oracle 19c RAC集群的全流程涵盖GRID软件安装、ASM磁盘配置、RAC数据库实例创建、IP与存储空间规划以及后续的数据库和ASM运维操作适合希望从零搭建高可用数据库环境的读者。资源包共1个PDF文件大小5.24MB内容共111页按章节组织从文档说明、安装规划、VMware创建虚拟机到GRID与RAC安装步骤层层递进并配有空间规划、IP规划等关键参数表便于对照实施。目前已有418人学习值得作为生产环境部署Oracle RAC的案头参考与操作手册。1. 为什么要看这份 CentOS7.5Oracle 19cRAC 的 PDF很多 DBA 和运维手里攒着一堆安装文档但 CentOS 7.5 配 Oracle 19c RAC 的这一类往往是群里转来转去、页脚都卷边了的那份。原因很简单CentOS 7.5 不是 Red Hat 官方认证的 RHEL 版本Oracle 19c 又是一代大幅改动过的版本RAC 的安装链路比单实例长得多——光是 Grid InfrastructureGI的 root.sh 就能卡掉一半的人。这份 PDF 的价值不是把官方文档翻译一遍而是它把三个版本组合之间的兼容性、内核参数、cvuqdisk 缺失这类软性坑全部提前踩平了。这份文档能解决的具体问题包括在 CentOS 7.5 上让 19c RAC 的安装前检查cvecheck一次通过、正确配置共享存储和 ASM 磁盘组、处理 GI 和数据库软件两个 Oracle Home 的安装顺序以及集群起不来的时候的排查路径。适合三类人一是刚接手 RAC 环境的新人 DBA需要一份能照着敲的部署手册二是做企业私有化交付的工程师需要在无外网环境下快速出一套高可用数据库三是准备把旧版 11g/12c RAC 升级到 19c 的运维需要先理解 19c 在架构和命令层面的变化。需要先说明标题指向的是一份 PDF 文档我这里不会逐页复述它的原文而是沿着「CentOS 7.5 Oracle 19c RAC」这条技术主线把每步的选型理由、关键参数和最容易翻车的地方讲清楚。你能在这个方向里拿到可复现的步骤也能看到我做这套环境时踩过的坑。2. 装 RAC 前先把账算清硬件、网络和存储的三个硬约束2.1 为什么 CentOS 7.5 不是 Red Hat 却常被拿来跑 Oracle 19cOracle 19c 的官方认证列表里写的是 Red Hat Enterprise Linux 7 系列但 CentOS 和 RHEL 在二进制兼容性上几乎一致内核版本、glibc、systemd 的行为都对齐所以社区和大量企业内部环境都默认 CentOS 7.x 可以跑。关键点是内核版本要和 19c 的 GI 要求的 min kernel 对得上。19c 在 x86_64 上要求内核不低于 3.10.0-957CentOS 7.5 的内核是 3.10.0-862这就出现了一个真实存在的落差。如果你的 CentOS 7.5 内核停留在 862直接装 GI 18c 以上的版本root.sh 阶段可能报关于oracle-validated包或内核参数的错。实操里两条路一条是yum update kernel把内核升到 957 以上再装另一条是依然用 7.5 但手动补齐所有参数和包。我一般倾向第一条省心。换句话说CentOS 7.5 Oracle 19c RAC 这套组合能成立的前提是系统内核先对齐到 19c 的认证线。2.2 两台节点的最低配置和共享存储划分RAC 至少需要两台节点每台内存最低按 16G 规划8G 不是不能跑但 GI DB 两个 Home 加上 ASM 实例和集群进程内存会非常紧张。我自己在虚拟机里做过一次 8G 的测试环境swap 用得飞起crsd 进程被 OOM 的概率很大后来老老实实回到 16G。存储上Oracle 19c RAC 支持 ASM 直接管盘也可以走 NFS但生产环境绝大多数还是 ASM。需要准备一块共享盘放 OCR 和 Vote File至少三块小盘做冗余盘的大小不用太讲究1G 到 5G 都行。另一组盘放数据文件和 FRA空间按数据量估。这里注意一个容易忽略的点OCR 和 Vote File 在 19c 里默认放同一个磁盘组而且这个磁盘组的冗余度决定了集群的可用性。如果你只有一块共享盘ASM 的 external 冗余也能建但任一节点掉盘集群就废了测试无所谓生产别这么干。2.3 网络规划public、private 和 VIP 的地址分配逻辑RAC 需要至少两张网卡一张跑 public 网络含 VIP一张跑 private 的集群内部心跳。19c 的 GI 安装时要求你提供 public hostname、node VIP hostname 和 private hostname。常见的坑是 private 网卡用了和 public 同一网段这在安装检查时会直接报错。标准做法是 private 网络用独立的网段比如 192.168.56.x 这类不要路由到外部的地址段。DNS 配置方面每个节点的/etc/hosts必须写全所有节点的 public、VIP、private 三条记录缺 VIP 记录或写反 private 地址是安装检查里非常高频的报错来源。下面是我的一份 hosts 模板# /etc/hosts 模板节点一 192.168.10.11 db1.localdomain db1 192.168.10.12 db2.localdomain db2 192.168.10.111 db1-vip.localdomain db1-vip 192.168.10.112 db2-vip.localdomain db2-vip 192.168.56.11 db1-priv.localdomain db1-priv 192.168.56.12 db2-priv.localdomain db2-priv参数说明public 和 VIP 在同一网段VIP 不能配在网卡上由 GI 的 oracle-rs 脚本统一管理。private 地址必须和 public 分开网段而且两个节点间的 private 网段要能互通用ping -c 3 db2-priv验证。特别注意hostname 里的短名要和/etc/sysconfig/network里配置的 HOSTNAME 一致否则 GI 的配置工具会识别为两个不同的节点。3. GI 安装链路从 yum 依赖到 root.sh 跑通的完整脚本3.1 用 yum 一次性补齐系统依赖包CentOS 7.5 装 19c GI 前需要装一堆依赖包官方文档列得七零八落实际用 yum 一条命令更省事。前提是你的 yum 源可用如果机器在隔离内网需要提前把 RPM 包装到本地。以下是我常用的安装命令# 安装基础依赖和 Oracle 需要的包CentOS 7 用 Oracle Linux 7 的包名兼容 yum install -y binutils \ compat-libcap1 \ compat-libstdc-33 \ glibc \ glibc-devel \ ksh \ libaio \ libaio-devel \ libgcc \ libstdc \ libstdc-devel \ libXext \ libXtst \ libX11 \ libXau \ libXi \ make \ sysstat \ unixODBC \ unixODBC-devel \ gcc \ gcc-c \ elfutils-libelf-devel \ fontconfig-devel \ libXrender-devel \ libXpm-devel \ libXp-devel 2/dev/null || true # 2/dev/null 是防止个别包名在 CentOS 7.5 里不存在时直接中断命令逻辑就是一次性把编译链接、图形界面库、ODBC 驱动全收齐。compat-libstdc-33这个包在 CentOS 7 的默认源里未必有需要先启用 EPEL 源或用 Oracle Linux 的包替换否则会失败。判断依赖是否全部可用的快捷办法是直接启动runInstallerGI 的安装前检查会报告缺失项那时再补也不迟。3.2 用户、内核参数和 limits.conf 的一组统一配置Oracle 用户和用户组是 RAC 的根grid 用户和 oracle 用户的属组必须规划一致。常见做法是创建两个用户oinstall 是所有用户的主组dba 给 oracle 用户做系统组asmdba、asmadmin 给 grid 用户做 ASM 的管理组。下面是创建用户和目录的脚本groupadd oinstall groupadd dba groupadd asmadmin groupadd asmdba groupadd oper useradd -g oinstall -G dba,asmdba,oper oracle useradd -g oinstall -G asmadmin,asmdba,oper grid mkdir -p /u01/app/grid mkdir -p /u01/app/oracle chown -R grid:oinstall /u01/app/grid chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u01/app参数说明grid 用户必须加 asmadmin 和 asmdba 组这是 19c 里 ASM 实例归属的硬性要求。oracle 用户不加 asmadmin只有 asmdba因为数据库实例只需要访问 ASM 的权限不需要管理权限。这个分配如果错了装完 GI 后 oracle 用户执行asmcmd会报权限错误。内核参数的配置直接影响数据库性能也能让安装前检查直接绿掉。19c 在 7.5 上的参数比 11g 时代多了不少我贴一份实际用到的最小集cat /etc/sysctl.conf EOF fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 1073741824 kernel.shmmax 4398046511104 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576 vm.swappiness 10 EOF sysctl -p逻辑说明kernel.shmmax我按物理内存的 50% 以上配置测试环境 32G 时设成 4T 的上限目的是让 SGA 在分配时不至于触碰共享内存上限。net.ipv4.ip_local_port_range从 9000 开始是因为 RAC 内部通信会大量占用高端口范围太窄会导致连接池耗尽。vm.swappiness设 10 是让 Redis、Oracle 这类内存型应用尽量少进入 swap这个值在 CentOS 7 上对 Linux 内核有效Oracle 官方文档也推荐了。最后是 limits.conf。19c 的安装检查对 nofile、nproc、stack 的要求很高以下配置可以直接覆盖默认cat /etc/security/limits.conf EOF grid soft nproc 16384 grid hard nproc 16384 grid soft nofile 4096 grid hard nofile 65536 grid soft stack 10240 grid hard stack 32768 oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 4096 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 EOF3.3 用 cluvfy 做安装前检查cvuqdisk 缺失的修复19c GI 安装包里自带cluvfy工具做安装前多节点检查是这套流程里最值得花时间的一步。命令路径通常是$GRID_HOME/bin/cluvfy但在还没有安装 GI 之前需要通过解压后的安装介质来调用# 解压 GI 安装包到 cluster 目录后执行 cd /u01/grid19c export CVUQDISK_PKG/u01/grid19c/gridSetup.rsp ./runcluvfy.sh stage -pre crsinst -n db1,db2 -fixup -method rootcvuqdisk是全套检查里最容易报错的一项报错信息通常是缺少cvuqdiskRPM 包。这个包在 GI 安装介质的rpm目录下能找到名字形如cvuqdisk-1.0.10-1.rpm。安装方式要注意必须用 root 装到每个节点上rpm -ivh cvuqdisk-1.0.10-1.rpm说明一下cvuqdisk 是 Oracle 用来探测共享磁盘的一个驱动包不装的话cluvfy检查共享存储会直接失败而且后面asmca创建磁盘组时也识别不到盘。这个包虽然小但因为它藏在 GI 安装介质的 rpm 目录里很多第一次装 19c RAC 的人会卡在这一步。3.4 响应文件静默安装 GIroot.sh 的等待与验证GUI 跑runInstaller在单一节点上没问题但多节点环境里更容易复现、更适合写成脚本的是响应文件静默安装。19c 的 GI 安装响应文件与其他版本差异不小最常见的方式是先用图形界面生成一份 rsp然后拿它做静默安装。但如果没有图形环境可以直接手写一个最小响应文件# grid19c.rsp 的片段 oracle.install.responseFileVersion/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0 INVENTORY_LOCATION/u01/app/oraInventory oracle.install.optionCRS_CONFIG ORACLE_BASE/u01/app/grid ORACLE_HOME/u01/app/19.0.0/grid oracle.install.asm.OSDBAasmdba oracle.install.asm.OSOPERasmoper oracle.install.asm.OSASMasmadmin oracle.install.asm.SYSASMPasswordYourPassw0rd oracle.install.asm.diskGroup.nameDATA oracle.install.asm.diskGroup.redundancyEXTERNAL oracle.install.asm.diskGroup.AUSize4 oracle.install.asm.diskGroup.disks/dev/sdb1;/dev/sdc1 oracle.install.crs.config.scanNamescan-cluster.example.com oracle.install.crs.config.gpnp.enableGpnptrue说明关键参数INVENTORY_LOCATION是 oraInventory 的位置必须所有节点一致oracle.install.asm.diskGroup.disks用分号分隔多块 ASM 盘oracle.install.asm.SYSASMPassword会用于 ASM 实例的 SYS 用户后续 dbca 建库时还要用到。SCAN 名称需要提前在 DNS 里配好如果没有 DNS可以在/etc/hosts里把 SCAN 解析到其中一个节点的 public IP 上测试环境这样做没问题生产环境建议还是上 DNS。启动静默安装后安装脚本会在两个节点上依次执行 root.sh。这个阶段最容易出现的问题有两个一是 root.sh 在第二个节点上跑的时候因为 ssh 互信没配对而失败二是 root.sh 执行期间发生了ohasd启动失败常见原因是/etc/oracle目录权限或has服务被 systemd 的默认配置干扰。验证 GI 是否装好用下面这组命令# 以 grid 用户执行 crsctl check cluster -all crsctl status resource -t正常能看到 ora.cssd、ora.diskmon、ora.evmd 等资源在两边节点都是 ONLINE。如果只有一边 ONLINE先看$ORACLE_HOME/log/下的 alert 日志再检查 private 网络互通。4. 从 ASM 磁盘组到 19c 数据库实例dbca 建库的完整参数链路4.1 先理解 19c RAC 的两个 HomeGrid Home 和 DB Home19c 的软件布局沿用了 18c 的拆分方式——GI 的 Oracle Home 只负责集群和 ASM数据库软件的 Home 单独一套。这意味着你在系统里会看到两个 ORACLE_HOME一个属于 grid 用户通常是/u01/app/19.0.0/grid另一个属于 oracle 用户通常是/u01/app/oracle/product/19.0.0/dbhome_1。这一拆分带来的直接影响是环境变量的设置必须严格区分。很多人在两个 Home 切换时把 ORACLE_HOME 指错然后在sqlplus里连接的时候报ORA-12547或者直接找不到libclntsh.so。我的习惯是给每个用户单独写一个.bash_profilegrid 用户只指向 GI 的 Homeoracle 用户只指向 DB 的 Home避免交叉。4.2 用 asmca 创建 DATA 和 FRA 磁盘组GI 装完后ASM 实例已经在跑了但还没有可用的磁盘组。使用 asmca 的图形界面能比较直观地建磁盘组但同样可以通过命令行的asmca -silent完成。下面的命令建立一个外部冗余的 DATA 磁盘组和一个外部冗余的 FRA 磁盘组# 以 grid 用户执行-silent 参数避免图形界面 asmca -silent \ -createDiskGroup -diskGroupName DATA \ -diskList /dev/sdb1,/dev/sdc1,/dev/sdd1 \ -redundancy EXTERNAL \ -auSize 4 \ -sysAsmPassword YourPassw0rd \ -asmsnmpPassword YourPassw0rd asmca -silent \ -createDiskGroup -diskGroupName FRA \ -diskList /dev/sde1,/dev/sdf1 \ -redundancy EXTERNAL \ -auSize 4 \ -sysAsmPassword YourPassw0rd \ -asmsnmpPassword YourPassw0rd参数说明-auSize 4表示 ASM 分配单元大小是 4MB19c 默认就是 4MB这个是针对 OLTP 类随机 IO 的推荐值如果你要跑数仓类的顺序大文件auSize 可以改成 8 或 16。-redundancy EXTERNAL意味着这块磁盘组里任何一块盘挂了数据就真没了生产中至少要用 NORMAL需要至少三块盘。FRA 磁盘组是专门给归档日志和闪回用的大小建议为数据总量的两倍理论上越大越灵活。4.3 dbca 静默建 RAC 数据库参数选型和实测要点数据库实例的创建在 19c 里依然可以用 dbca 的图形向导但静默方式更适合脚本化交付。常见做法是写一个 dbca.rsp 响应文件然后执行dbca -silent \ -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -numberOfPDBs 1 \ -pdbName orclpdb \ -systemPassword YourPassw0rd \ -sysPassword YourPassw0rd \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaDiskGroup FRA \ -recoveryAreaSize 200G \ -totalMemory 8G \ -characterset AL32UTF8 \ -nationalCharacterSet UTF8 \ -sampleSchema false \ -databaseType OLTP \ -nodeList db1,db2各参数的含义和修改逻辑-numberOfPDBs 1会在容器数据库里自动创建一个可插拔库19c 是默认多租户架构单实例也可以选择非 CDB 模式但 RAC 建议直接上 CDB 方便后续运维。-totalMemory 8G是给数据库实例的 SGAPGA 的合计上限如果节点本身只有 16G 内存这个值超过 10G 就可能跟 GI 抢内存。-recoveryAreaSize 200G要匹配 FRA 磁盘组的实际容量设大了 dbca 会报警设小了归档日志容易被撑满。建库完成后验证数据库实例在两个节点上都能打开# 以 oracle 用户执行 srvctl status database -d orcl srvctl start database -d orcl4.4 19c 的新特性在 RAC 安装里的实际影响19c 在 RAC 安装链路上有几个地方和老版本有明显差异。一个是前面说的 Oracle Home 分离另一个是安装介质的解压结构变化——19c 的 DB 和 GI 安装包下载下来是 zip 文件解压后结构完全不同GI 的解压目录直接就是安装程序所在目录而 DB 的解压目录下要再分Database子目录才找得到安装程序。还有一个对运维影响大的点是 19c 的srvctl命令支持了更多的资源属性。例如管理 PDB 时直接用srvctl add service -db orcl -pdb orclpdb就能注册一个服务指向特定 PDB这在 12c 时代还要手工改服务名。另外19c 里crsctl status resource的输出比 11g 长很多你会在其中看到许多名字里带.pxp、.gns的资源——这是 GI 自带的 GNS 和 PX 协议组件如果没配置 DNS这些资源的状态会是 OFFLINE但通常不影响集群整体功能。5. RAC 部署避坑实录常见问题的现象、原因与解法5.1 安装前检查时 cluvfy 报共享存储不可见现象runcluvfy.sh stage -pre crsinst执行到共享存储检查步骤时报错提示找不到候选磁盘或者盘在节点一能看到、节点二看不到。原因这类问题多数不是磁盘真没接好而是多路径软件没有配或者 ASM 使用的磁盘设备名不一致。比如节点一上 ASM 盘是/dev/sdb1节点二上同一个 LUN 却变成了/dev/sdc1。也可能是没有安装cvuqdisk导致 GI 无法通过驱动枚举共享盘。解决先统一两节点的设备名最好的办法是用/dev/mapper/下的设备名或data的盘符ID绑定。检查两节点/dev/mapper下是否有相同名称的映射如果没有用multipath -ll确认多路径是否生效。临时做法是把 ASM 盘的 owner 改成 grid:asmadmin 并把权限设为 660再用asmcmd lsdsk确认。5.2 root.sh 在第二个节点执行失败提示 CSS 无法启动现象GI 安装过程中第一个节点的 root.sh 正常结束但第二个节点执行 root.sh 时提示CRS-5010或ohasd failed to start之后crsctl check cluster显示只有一个节点的组件是 ONLINE。原因最常见的是两个节点之间的 SSH 互信没有完全建立导致第二个节点向第一个节点请求集群配置时被拒绝。另一个高频原因是第二个节点的主机名解析到了错误的 IP 或/etc/hosts里写了多余条目导致 GI 无法识别这是同一套集群的第二个成员。解决重新用ssh-keygen和ssh-copy-id重建两个节点 grid 和 oracle 用户的互信。然后逐行检查/etc/hosts确保只有一套主机名映射。最后在第二个节点以 grid 用户执行crsctl start crs看具体报错配合$ORACLE_HOME/log/db1/agent/下的ohasd日志定位根因。5.3 ASM 磁盘组磁盘头损坏或 ASM 实例起不来现象机器重启后crsctl status resource -t里ora.asm是 OFFLINE通过crsctl start resource ora.asm启动时报从磁盘组读取失败或磁盘头无效错误。原因ASM 磁盘头损坏通常不是硬件问题而是磁盘组里某块盘被操作系统重新分区或格式化导致 disk header 被覆盖也可能是/dev/sdX设备名刷新后 ASM 无法通过设备名定位到盘。解决先用kfed read /dev/sdb1查看磁盘头内容确认 AU size、磁盘组名以及盘在组内的编号。如果确实是磁盘头被抹掉可以用kfed repair恢复但前提是你手里有另一块同组盘的完好头部信息作参考。更稳的做法是在恢复前先用dd备份坏盘的前 100MB再尝试修复这样即便kfed repair失败也有后悔药。5.4 数据库实例能起但只有单个节点注册了服务现象srvctl status service -d orcl显示服务只在 db1 上运行db2 上的实例启动了但服务没有注册。原因这通常不是故障而是服务的 TAF 策略配置问题。默认策略下服务只在一个实例上运行另一个节点作为备用。DBA 误以为 RAC 的服务必须在所有节点都启动。解决确认业务需要的模式。如果是负载均衡型可以用srvctl modify service -d orcl -s orcl_service -availpolicy balance -preferred db1,db2改配置。如果是 failover 型保持当前配置即可。这个坑之所以常见是因为很多 DBA 从单实例切到 RAC 后对服务管理模型没有切换过来。5.5 SCAN IP 解析失败导致 JDBC 连接报 ORA-12545现象应用通过 SCAN 连接数据库报ORA-12545: Connect failed because target host or object does not exist但直接连节点 IP 可以正常连接。原因SCAN 的解析可能落在了只有一个节点 IP 的 hosts 文件上或者 SCAN VIP 在 DNS 中没有正确注册。19c 里如果使用 GNSSCAN 由 GNS 自动管理如果没有 GNS你必须手动维护 DNS 或 hosts 内的 SCAN 解析。解决测试环境最简单的方式是确保 SCAN 的三个 IP 都写进/etc/hosts并且每个节点看到的解析一致。生产环境建议把 SCAN 三个 IP 和对应主机名配到 DNS 的 round-robin 记录里排查时用nslookup scan-cluster.example.com和ping scan-cluster.example.com验证解析结果。还要检查 listener 是否正确注册了 SCAN listener用lsnrctl status LISTENER_SCAN1查看。6. 留给维护期的一个技巧用 asmcmd 和 crsctl 快速确认集群健康度进入维护期后你最有用的工具不是 GUI 控制台而是命令行。我日常巡检 RAC 的第一件事是执行crsctl status resource -t但这条输出太长了我不会每条细看直接拉关键项crsctl status resource -t | grep -E ora.(asm|cssd|evmd|diskmon|scan) | \ grep -E ONLINE|OFFLINE | sort | uniq -c这个命令的意图是把所有集群核心资源的在线状态汇总成一个统计输出。ora.asm表示 ASM 实例资源ora.cssd是 Cluster Synchronization Serviceora.evmd是事件管理守护进程ora.scan是 SCAN listener。如果某个资源在两节点上只有一个 ONLINE说明集群有隐患。ASM 磁盘组的状态是另一个巡检重点。用asmcmd能一目了然地看到磁盘组的挂载状态和可用空间asmcmd -p lsdg输出里关注 USABLE_FILE_MB 如果持续低于 10%就该考虑扩容或清理归档。注意asmcmd默认要用 grid 用户执行而且环境变量 ORACLE_SID 要设为ASM1节点一或ASM2节点二。如果你的 oracle 用户也能执行那多半是之前提到的属组配置有问题。最后分享一个我在维护 RAC 时的习惯每次装完 19c RAC都会把响应文件、/etc/hosts备份、cvuqdisk的 RPM 包放到一个独立目录里并且在两台节点上再各存一份。这个习惯救过我不少次——有次因为存储整列损坏要重搭集群我没有重新解压安装包直接用备份的响应文件和命令脚本在半小时内恢复了 GI。把整套安装过程整理成可重复执行的脚本而不是依赖点鼠标的记忆是 RAC 运维里最值得投入的一件事。希望这些经验帮到你。本文还有配套的精品资源点击获取
返回列表