PostgreSQL 버전 관리

PostgreSQL Global Development 그룹은 일반적으로 매년 PostgreSQL의 주요 버전 하나를 출시합니다. 이는 일반적으로 3분기에 이루어집니다. 우리의 목표는 새로운 PostgreSQL 기능을 지원하고 채택하는 것과 사용자 업그레이드로 인한 다운타임 및 관리 비용을 균형있게 유지하는 것입니다. GitLab은 언제나 두 가지 버전의 PostgreSQL을 지원하려고 노력합니다. 이는 새 버전의 PostgreSQL을 추가하기 전에 기존에 지원하는 가장 오래된 버전을 제거하고, 최소한의 필수 PostgreSQL 버전을 하나의 주요 버전 올려야 한다는 것을 의미합니다. PostgreSQL 제거는 주요 GitLab 릴리스에서만 이루어집니다.

소프트웨어 정의

소프트웨어 정의는 다음 위치에 있습니다:

  • config/software/postgresql_old.rb
  • config/software/postgresql.rb
  • config/software/postgresql_new.rb

기본 버전

기본적으로 설치해야 하는 버전은 ‘링크 바이너리 파일’ 단계를 사용하여 제어됩니다. 이 단계를 갖는 소프트웨어 정의는 새로운 설치에서 사용됩니다.

업그레이드

gitlab-ctl pg-upgrade 명령어를 사용하여 postgresql_old 또는 postgresql에서 postgresql_new로 업그레이드합니다. 사용 방법은 이 문서를 참조하세요.

자동 업그레이드

모든 업그레이드 과정에서 gitlab-ctl pg-upgrade 명령어가 실행됩니다. 업그레이드 및 회귀 프로세스 중에 사용할 기본 PostgreSQL 버전을 변경하려면 설정을 조정하여 설치 중에 자동으로 업그레이드될 PostgreSQL 버전을 지정해야 합니다.

오래된 버전 제거

오래된 버전을 제거할 때 다음을 추적하는 에픽과 이슈를 만드세요:

  1. Omnibus에서 오래된 버전 제거
  2. Helm 설치에서 오래된 버전 제거
  3. CI 비용을 최소화하기 위해 테스트 스위트에서 오래된 버전 제거(이를 하기 전에 .com이 여전히 오래된 버전을 사용하지는 않았는지 확인하세요)
  4. GitLab 사용자 설명서에서 해당 버전의 PostgreSQL에 대한 참조 제거
  5. 주요 PostgreSQL 버전이 제거되기 3개의 GitLab 릴리스 이전에 폐지 공지 사항을 게시합니다. PostgreSQL 버전이 세 개의 릴리스 내에서 제거될 것인 경우에는 Omnibus에서 관리되는 PostgreSQL 데이터베이스이거나 외부 데이터베이스인지에 관계없이 GitLab 업그레이드 프로세스 및 관리자 UI에서 가장된 폐지 공지 사항을 게시합니다.

제거 작업을 위해 다음 단계를 수행하세요:

  1. git rm config/software/postgresql_old.rb 실행
  2. git mv config/software/postgresql{,_old}.rb 실행
  3. config/software/postgresql_old.rb를 열어서 postgresql를 postgresql_old로 이름을 변경하세요
  4. git mv config/software/postgresql{_new,}.rb 실행
  5. config/software/postgresql.rb를 열어서 postgresql_new를 postgresql로 이름을 변경하세요

새로운 버전 추가

  1. git cp config/software/postgresql{,_new}.rb 실행

  2. config/software/postgresql_new.rb를 열어서 다음을 업데이트하세요:

    1. name을 postgresql_new로 업데이트
    2. default_version을 새 버전으로 변경
    3. version에서 새로운 버전 및 sha256를 업데이트
    4. 필요한 경우 major_version 업데이트
  3. 새로운 PostgreSQL 버전을 전체 테스트 스위트에 추가합니다.
  4. gitlab-org/gitlab 저장소에 대해 새로운 버전의 PostgreSQL에서 매일 테스트를 실행합니다.
  5. 패키지 빌드가 두 가지 버전의 PostgreSQL을 모두 포함하도록 합니다.
  6. Helm 설치에서 기본 PostgreSQL 차트 버전을 업데이트하도록 합니다.
  7. 사용자 설명서를 업데이트하세요.

테스트

  1. GitLab이 새 버전의 PostgreSQL에서 실행됩니다.
  2. 10k 참조 아키텍처 규모로 새로운 PostgreSQL 버전에서 GitLab을 실행하고 성능 하락 여부를 확인하시고 확인하세요.

다음 환경에 대한 업그레이드와 새로운 설치를 테스트합니다:

  1. 단일 노드
  2. Omnibus에서 관리되는 별도의 데이터베이스 노드로 설치
  3. 클러스터 내부에 3개 이상의 데이터베이스 노드를 보유한 HA 데이터베이스 클러스터
  4. 단일 노드 기본 및 단일 노드 보조(두 번째 노드에 postgresql 및 geo-postgresql 있는 Geo 설치)
  5. 주요 클러스터에 HA 데이터베이스 클러스터가 있는 Geo 설치
  6. 두 번째 노드에 별도의 데이터베이스와 별도의 추적 데이터베이스가 있는 Geo 설치
  7. Helm 설치
  8. 최신 버전으로 업그레이드가 작동하는지 확인하고 revert-pg-upgrade가 이전에 사용된 버전으로 성공적으로 다운그레이드되는지 확인하기
  9. 기본 PostgreSQL 버전이 변경되었다면, 외부 PostgreSQL 데이터베이스에서 GitLab 업그레이드를 테스트합니다.

  10. 백업 및 복원 기본 PostgreSQL 버전이 변경된다면:

  11. 단일 노드 설치, 별도의 데이터베이스 노드, HA 클러스터에서 자동 업그레이드
  12. 외부 PostgreSQL 데이터베이스가 사용되는 자동 업그레이드
  13. Geo 설치는 자동 업그레이드되지 않습니다.

최소 필수 버전이 변경된다면:

  1. 예전 버전의 Omnibus에서 관리되는 PostgreSQL이 아직 설치되어 있는 경우 GitLab 업그레이드에서 오류가 발생합니다.

위의 테스트들이 수동으로 진행된다면, 수동 테스트가 완료된 후에 도입된 중단 변경사항을 인지할 위험이 있습니다. 가능한 많은 테스트를 자동화해야 합니다.

  1. 패키지 빌드가 두 가지 버전의 PostgreSQL을 모두 포함하는지 확인
  2. gitlab-ctl pg-upgrade가 작동하는지 확인

libpq의 경우

pyscopg2를 포함한 일부 모듈들은 PostgreSQL 클라이언트 라이브러리인 libpq에 의존합니다. 항상 최신 번들 버전에 링크해야 합니다. 최신 버전을 사용함으로써 libpq의 역호환성에 의존합니다.

알려진 이슈

Geo에서는 스트리밍 복제를 사용하는데, 주요 PostgreSQL 업그레이드 이후에는 전체 보조 데이터베이스를 동기화해야 합니다. 이로 인해 몇 시간 또는 며칠 동안 다운타임이 발생할 수 있으며, 그러므로 Geo 고객에게 자동 업그레이드를 권장하지 않습니다. 12.10부터 Geo가 감지되면 자동 PostgreSQL 업그레이드가 비활성화됩니다.