CM 7.11.3.2 → 7.11.3.39 로 업그레이드했다가 다시 7.11.3.2 로 패키지를 내린 뒤 cloudera-scm-server 가 exclusive_lock_version 컬럼 관련 오류로 기동하지 않았다. 바이너리는 구버전(7.11.3.2)인데 scm DB 스키마는 신버전(7.11.3.39)으로 올라간 상태였다. CM 은 DB 스키마를 자동으로 낮춰 주지 않으므로 구버전 바이너리는 신 스키마 위에서 계속 실패한다.
yum history list cloudera-manager-server # 어느 방향으로 바뀌었는지
yum history info <transaction-id>
rpm -qa 'cloudera-manager-*'
psql(scm DB)에서 SELECT version, old_version FROM schema_version; 과 \d services 로 신버전에서 추가된 컬럼 존재 여부를 본다. SCHEMA_VERSION 값은 내부 번호라 rpm 버전과 1:1 로 맞지 않으며, 결정적 근거는 신버전 전용 컬럼의 실재 여부다.
작업 전 반드시 현재 DB 를 덤프한다. 접속 정보는 /etc/cloudera-scm-server/db.properties 에 있다.
pg_dump -U ${DB_USER} -h <db-host> -Fc scm -f scm_before_reupgrade.dump
재업그레이드 절차는 다음과 같다.
systemctl stop cloudera-scm-server
# /etc/yum.repos.d/cloudera-manager.repo 의 baseurl 을 목표 버전 트리로 교체
yum clean all
yum list cloudera-manager-server --showduplicates
yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent
rpm -qa 'cloudera-manager-*'
systemctl start cloudera-scm-server
tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log
기동 후 psql 에서 \d services 에 exclusive_lock_version 이 보이면 정상이다. 모든 호스트의 cloudera-manager-agent 도 같은 버전으로 통일하고 agent → Cloudera Management Service 순으로 올린다. subscription-manager 경고는 무관하다.
Cloudera 는 CM 다운그레이드를 고급 작업으로 분류하며, 정식 롤백은 업그레이드 전에 받아 둔 CM 저장소 디렉터리·CM DB·서비스 DB 백업에 의존한다. HDFS 업그레이드를 finalize 했거나 Compute 클러스터라면 롤백 자체가 불가하다. 업그레이드가 실패해 서버가 뜨지 않은 경우는 "동일 버전 재설치" 절차로 더 간단하며, 서버 로그의 Updated Schema Version to ... 유무로 스키마 갱신 여부를 판단한다.
ALTER TABLE ... ADD COLUMN exclusive_lock_version 식으로 컬럼을 수동 추가하지 않는다. 신 스키마는 여러 변경을 포함한다.