Oracle RAC 일상 운영과 장애 시나리오
Oracle난이도: 고급소요 시간: 15분 – 3시간(시나리오에 따라)설치되어 운영 중인 Oracle RAC(Grid Infrastructure 19c) 클러스터의 일상 운영과 장애 대응: 상태 점검, node eviction 진단, 노드 유지보수 전환, 클러스터 전체 계획 종료와 기동, 노드 추가와 제거, 서비스 관리(preferred/available, AC/TAC), SCAN/VIP/포트/interconnect 변경, OCR/OLR 백업과 복원, OCR과 voting 파일 이전. 설치 가이드가 아닙니다(먼저 RAC 설치). 패치는 RAC rolling patch, 디스크 그룹 작업은 ASM 일상 운영을 참조하십시오. 각 시나리오는 진단 → 안전장치 → 적용 → 검증 → 사후 작업 순서로 진행됩니다.
구성: 기존 2–8 노드 RAC(Grid Infrastructure 19c, 23ai/26ai 차이는 참고 사항에)
시나리오
- 클러스터 상태 점검(일상 / 유지보수 전) — 아무것도 변경하지 않습니다. Clusterware 스택, 리소스, OCR/voting, ASM, interconnect, 시간, 최근 경고를 점검합니다. 일상 점검, 모든 유지보수와 패치 전, 그리고 문제가 보고되었을 때 가장 먼저 선택하십시오.
- 노드가 클러스터에서 축출되었거나 스스로 재시작됨(eviction 진단) — 읽기 전용: 노드가 예기치 않게 재시작되었거나 클러스터에서 축출되었을 때 선택하십시오. Clusterware alert log, ocssd.trc, 운영체제 로그, misscount/disktimeout 값으로 근본 원인이 네트워크인지, 디스크인지, 운영체제인지 찾습니다.
- 유지보수를 위해 노드 중지 후 재기동 — 한 노드에서 운영체제 패치, 커널 또는 하드웨어 유지보수를 할 때 선택하십시오. 다른 노드는 계속 동작합니다. 해당 노드 인스턴스의 서비스는 이전되고, 세션은 drain 시간이 끝나면 종료됩니다.
- 클러스터 전체 계획 종료와 기동 — SAN 또는 데이터센터 유지보수처럼 모든 노드를 동시에 종료해야 할 때 선택하십시오. 전체 다운타임: 모든 노드에서 모든 데이터베이스, ASM, Clusterware가 중지됩니다.
- 클러스터에 새 노드 추가 — 새 서버를 클러스터에 합류시킬 때 선택하십시오(용량 증설, 하드웨어 교체). 무중단: 사전 점검(cluvfy), Grid home(addnode.sh), DB home과 새 인스턴스(dbca -addInstance).
- 클러스터에서 노드 제거 — 서버를 클러스터에서 영구적으로 제거할 때 선택하십시오(반납, 하드웨어 장애). 인스턴스를 삭제하고, 해당 노드에서 DB home과 Grid home을 제거한 뒤, 노드를 클러스터에서 삭제합니다. 다른 노드는 계속 열려 있습니다.
- 서비스 추가, 변경, 이전 또는 삭제 — 애플리케이션이 접속하는 서비스를 정의하거나, 배치(preferred/available) 또는 failover 설정(TAF/Application Continuity)을 변경하거나, 실행 중인 서비스를 다른 인스턴스로 옮길 때 선택하십시오. 데이터베이스는 계속 열려 있습니다.
- SCAN, VIP, 리스너 포트 또는 interconnect 변경 — SCAN 이름/IP, 노드 VIP, 리스너 포트 또는 private 네트워크(interconnect)를 변경할 때 선택하십시오. interconnect 변경은 클러스터 전체 중지가 필요하고, 나머지는 짧은 연결 중단만 발생합니다.
- OCR과 OLR 백업 및 백업 확인 — 무중단: 수동 OCR 백업, 각 노드의 OLR 백업, 백업을 클러스터 디스크 밖으로 복사. 패치, 노드 추가/제거, 네트워크 변경 같은 위험한 작업 전에 항상 선택하십시오.
- OCR 손상 또는 CRS 디스크 그룹 손실: 백업에서 복원 — ocrcheck가 손상을 보고하거나, CRSD가 기동되지 않거나(PROT-/PROC- 오류), CRS 디스크 그룹이 완전히 손실되었을 때 선택하십시오. 클러스터 전체가 중지됩니다. OCR을 exclusive 모드에서 백업으로 복원하며, 디스크 그룹이 손실되었으면 디스크 그룹, voting 파일, ASM spfile을 다시 생성합니다.
- 한 노드에서 Clusterware가 기동되지 않음: OLR 손상 — 다른 노드는 정상인데 한 노드에서만 crsctl start crs가 OHASD를 기동하지 못하고 ocrcheck -local이 OLR 오류를 보고할 때 선택하십시오. 해당 노드만 영향을 받으며, OLR을 백업에서 복원합니다.
- OCR과 voting 파일을 다른 디스크 그룹으로 이전 — 무중단: ocrconfig -add/-delete와 crsctl replace votedisk. 스토리지(SAN) 교체, CRS 디스크 그룹의 이중화 수준 상향, 또는 OCR을 두 번째 디스크 그룹에도 기록하려 할 때 선택하십시오.
시작하기 전에
- 모든 노드에 root 권한이 있고 grid/oracle 사용자로 login shell(sudo -iu grid)을 열 수 있으며, grid와 oracle 프로파일이 Grid/DB home 환경을 로드합니다.
- 시작 전에 클러스터가 정상입니다. 모든 노드에서 CRS가 online이고, 열려 있어야 하는데 중지된 리소스가 없습니다. 그렇지 않으면 먼저 상태 점검으로 문제를 해결하십시오.
- 유지보수 시간과 변경 요청이 승인되었고, 애플리케이션 팀에 공지했으며, 모니터링 시스템에서 blackout을 설정했습니다. …이 작업은 전체 다운타임을 발생시킵니다.…
- 데이터베이스의 최신 RMAN 백업과 아카이브 로그 백업이 있습니다…(인스턴스 추가/삭제는 redo thread와 undo 테이블스페이스를 변경함)….
- 클러스터 디스크 밖에 보관한 OCR 백업(…)이 있거나, 정상 디스크 그룹에 있는 자동 백업의 경로를 알고 있습니다. …CRS 디스크 그룹용으로 … 이중화에 충분한 수의, 모든 노드에서 보이는 빈 디스크가 준비되어 있습니다.…
- 새 노드(…)가 기존 노드와 같은 운영체제 버전과 커널이며, RAC 설치의 운영체제 준비와 스토리지 준비를 마쳤습니다. public/private 인터페이스 이름이 같고, 공유 LUN이 이 노드에도 제공되었으며, VIP 주소 …는 사용되지 않고 있습니다.
- 장애 발생 시각을 대략 알고 있습니다. AHF(TFA)가 설치되어 있으면 진단 수집은 명령 하나로 끝나며, 없으면 로그를 직접 확인합니다.
가이드 단계
- 클러스터 상태 점검 — 모든 노드에서 Clusterware 스택 점검 · 리소스 상태 나열 · 데이터베이스, 서비스, 리스너 상태 점검 · OCR, voting, OLR 무결성 점검 · ASM과 디스크 그룹 사용률 점검 · 네트워크 구성과 시간 동기화 점검 …
- 클러스터 전체 중지 — 중지 전 상태 기록 · OCR 수동 백업(안전장치) · 모든 데이터베이스 중지 · 모든 노드에서 Clusterware 중지 · OHASD 중지(…) · 유지보수 작업 수행
- 클러스터 전체 기동 — Clusterware 시작(…) · 모든 노드의 클러스터 합류 대기 · 데이터베이스 기동 확인 · 기동 후 리소스 비교
- 새 노드 준비와 사전 점검 — 현재 클러스터 구성 기록 · 새 노드의 운영체제 준비 확인 · /etc/hosts에 새 노드 추가(…) · grid 사용자의 SSH 등가성을 새 노드로 확장 · oracle 사용자의 SSH 등가성을 새 노드로 확장 · cvuqdisk RPM을 새 노드로 전송 …
- Grid Infrastructure를 새 노드로 확장 — OCR 수동 백업(안전장치) · Grid home을 새 노드로 확장(addnode.sh) · orainstRoot.sh 실행(새 노드) · root.sh 실행(새 노드) · 새 노드에서 grid 환경 설정 · 새 노드를 클러스터에서 검증
- DB home과 새 인스턴스 — DB home을 새 노드로 확장 · DB home root.sh 실행(새 노드) · 새 노드에서 oracle 환경 설정 · 새 인스턴스 추가(dbca -addInstance) · 서비스 구성에 새 인스턴스 추가 · 새 인스턴스 검증
- 노드 추가 후 작업 — 새 노드의 OLR 백업 · 새 구성의 OCR 백업 · 모니터링, 백업, 운영 작업 갱신
- 인스턴스와 DB home 제거 — …에서 서비스 비우기(인스턴스는 열린 상태 유지) · 인스턴스 삭제(dbca -deleteInstance) · DB home 인벤토리를 대상 노드로 축소(…) · DB home 제거(deinstall -local)(…) · 남은 노드에서 DB home 인벤토리 갱신
- 대상 노드에서 Clusterware 제거 — Pin 상태 확인, 필요하면 해제 · Grid home 제거(deinstall -local)(…) · 클러스터 정의에서 노드 삭제 · 삭제 검증 및 남은 VIP 제거
- 노드 제거 후 작업 — 새 구성의 OCR 백업 · 잔여물 정리 및 기록 갱신
- 서비스: 진단 — 서비스의 현재 구성 표시
- 서비스: 적용 — 서비스 추가 및 시작 · 서비스 배치와 설정 변경 · 새 배치에 따라 서비스 시작 · 서비스를 다른 인스턴스로 이전 · 서비스 중지 및 삭제
- 서비스: 검증 — 서비스가 데이터베이스와 리스너에 보이는지 확인
- 네트워크 변경: 진단과 안전장치 — 현재 네트워크 구성 기록 · OCR 수동 백업(안전장치) · GPnP 프로파일 백업(…)
- SCAN 이름 / IP 변경 — 새 SCAN 이름 해석 확인 · SCAN VIP와 리스너를 새 값으로 재생성 · 데이터베이스의 remote_listener 설정 갱신 · SCAN을 통한 연결 확인
- OCR과 OLR 백업 — 현재 OCR 백업과 백업 위치 표시 · OCR 수동 백업 · 최신 수동 백업을 클러스터 밖으로 복사하고 검증 · OLR 수동 백업(…) · ASM spfile과 비밀번호 파일도 백업
- OCR 복원: 진단 — OCR 상태와 Clusterware 점검 · ASM 쪽에서 디스크 그룹과 디스크 점검 · 복원할 백업 검증
- OCR 복원: 적용 — Clusterware 중지(…) · 1번 노드에서 Clusterware를 exclusive 모드로 시작 · 임시 파라미터 파일로 ASM 시작(spfile 손실 시) · … 디스크 그룹 재생성 · 백업에서 OCR 복원 · Voting 파일 재생성 …
- OCR 복원: 검증과 사후 작업 — 클러스터와 OCR 검증 · 백업 이후 변경분 확인 · 새 OCR 백업 및 근본 원인 해결