PostgreSQL 버전 관리

PostgreSQL 글로벌 개발 그룹은 보통 매년 1회 PostgreSQL 주요 버전을 릴리스합니다. 일반적으로 이는 3분기에 이루어집니다. 저희의 목표는 새로운 PostgreSQL 기능을 지원하고 채택하는 것과 사용자의 업그레이드 다운타임 및 관리 비용 간의 균형을 맞추는 것입니다. GitLab은 언제나 PostgreSQL의 두 버전을 지원하는 것을 목표로 하고 있습니다. 이는 새로운 PostgreSQL 버전을 추가하기 전에 우리가 지원하는 가장 오래된 버전을 제거하고, PostgreSQL의 최소 요구 버전을 1개의 주요 버전 올려야 한다는 것을 의미합니다. PostgreSQL 제거는 주요 GitLab 릴리스에서만 이루어집니다.

소프트웨어 정의

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

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

기본 버전

기본으로 설치해야 하는 버전은 ‘link bin files’ 단계를 사용하여 제어됩니다. 이 단계를 가진 소프트웨어 정의는 새 설치에 사용됩니다.

업그레이드

gitlab-ctl pg-upgrade 명령어는 postgresql_old 또는 postgresql에서 postgresql_new로 업그레이드하는 데 사용됩니다. 사용 방법은 문서를 참조하십시오.

자동 업그레이드

모든 업그레이드 시 gitlab-ctl pg-upgrade 명령어가 실행됩니다. 업그레이드 및 되돌리기 명령에 사용되는 기본 버전을 변경하려면 설치 중에 PostgreSQL 버전을 자동으로 업그레이드하고 싶을 때 해당 명령어를 변경해야 합니다.

오래된 버전 제거

오래된 버전을 제거할 시에는 다음을 추적하는 이슈가 있는 epic을 만들어야 합니다:

  1. 오래된 버전을 Omnibus에서 제거합니다.
  2. Helm 설치에서 오래된 버전을 제거합니다.
  3. CI 비용을 최소화하기 위해 테스트 스위트에서 오래된 버전을 제거합니다 (이전에 .com에서 아직 사용 중인지 확인하세요).
  4. GitLab 사용자 문서에서 해당 PostgreSQL 버전에 대한 참조를 제거합니다.
  5. 주요 PostgreSQL 버전이 제거되기 3개의 GitLab 버전 이전에 릴리스 포스트에 제거 알림을 출력합니다. PostgreSQL 버전이 3개의 릴리스 내에서 제거될 버전이면 Omnibus에서 관리되는 PostgreSQL 데이터베이스이든 외부 데이터베이스이든 GitLab 업그레이드 프로세스 중에 관리자 UI 및 PostgreSQL 버전에 관한 알림을 출력합니다.

제거 과정은 다음을 수행합니다:

  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. 패키지 빌드가 두 버전 모두를 포함하도록 합니다.
  6. Helm 설치의 경우, 기본 PostgreSQL 차트 버전을 변경하려면 업데이트합니다.
  7. 사용자 문서를 업데이트합니다.

테스트

  1. GitLab이 새 버전의 PostgreSQL에서 실행됩니다.
  2. 10,000 참조 아키텍처 규모에서 새 PostgreSQL 버전에서 GitLab을 실행하고 성능 이상 유무를 확인합니다.

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

  1. 단일 노드
  2. Omnibus에서 관리되는 별도의 데이터베이스 노드로 설치
  3. 3개 이상의 데이터베이스 노드로 구성된 HA 데이터베이스 클러스터
  4. 단일 노드 프라이머리 및 단일 노드 세컨더리 (두 번째 노드에서 postgresql 및 geo-postgresql가 동일하게 실행)를 가진 Geo 설치
  5. 프라이머리에서 HA 데이터베이스 클러스터를 가진 Geo 설치
  6. 세컨더리에는 별도의 데이터베이스와 별도의 트래킹 데이터베이스가 있는 Geo 설치
  7. Helm 설치
  8. 최신 버전으로의 업그레이드가 작동하는지 확인하고, revert-pg-upgrade가 이전에 사용된 버전으로 성공적으로 다운그레이드되는지 확인합니다. 이는 Geo의 세컨더리 독립형 트래킹 데이터베이스에서도 마찬가지입니다.
  9. 기본 PostgreSQL 버전이 변경되면 외부 PostgreSQL 데이터베이스에서 GitLab 업그레이드를 테스트합니다.

  10. 백업 및 복원 기본으로 설치되는 PostgreSQL 버전이 변경되는 경우:

  11. 단일 노드 설치 및 외부 데이터베이스를 사용하는 경우 자동 업그레이드
  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의 자동 업그레이드가 비활성화됩니다.