PostgreSQL 버전 관리

일반적으로 PostgreSQL Global Development Group은 매년 PostgreSQL의 주요 버전을 릴리스합니다. 일반적으로 이는 3분기에 이루어집니다. 우리의 목표는 새로운 PostgreSQL 기능을 지원하고 채택하는 것과 사용자의 업그레이드로 인한 다운타임 및 관리 비용을 균형있게 유지하는 것입니다. GitLab은 언제나 두 가지 버전의 PostgreSQL을 지원하고자 합니다. 이는 새로운 PostgreSQL 버전을 추가하기 전에, 지원하는 가장 오래된 PostgreSQL 버전을 제거하고, PostgreSQL 최소 요구 버전을 한 주요 버전 올린 후에 진행됩니다. 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개의 릴리스 내에 제거될 버전이라면 PostgreSQL을 Omnibus로 관리되는 데이터베이스이거나 외부 데이터베이스인지에 관계 없이 GitLab 업그레이드 과정 중 Admin 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. GitLab을 10k 참조 아키텍처 스케일에서 새로운 PostgreSQL 버전에서 실행 및 성능 회귀 확인

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

  1. 단일 노드
  2. Omnibus가 관리하는 별도의 데이터베이스 노드와 함께 설치
  3. 클러스터 내 3개 이상의 데이터베이스 노드를 가진 HA 데이터베이스 클러스터
  4. 단일 노드 프라이머리 및 단일 노드 세컨더리로 구성된 Geo 설치 (postgresql 및 geo-postgresql을 동일한 세컨더리 노드에 설치)
  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 업그레이드가 비활성화됩니다.