PostgreSQL 버전 관리

PostgreSQL 글로벌 개발 그룹은 일반적으로 매년 하나의 주요 PostgreSQL 버전을 출시하며, 보통 3분기에 출시됩니다. 우리의 목표는 새로운 PostgreSQL 기능의 지원과 채택, 사용자 업그레이드의 다운타임 및 관리 비용 간의 균형을 맞추는 것입니다. GitLab은 항상 두 개의 PostgreSQL 버전을 지원하는 것을 목표로 합니다. 이는 새로운 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 버전이 3개 릴리스 내에 제거될 버전이라면, Omnibus 관리 PostgreSQL 데이터베이스인지 외부 데이터베이스인지에 관계없이 관리 UI 및 GitLab 업그레이드 프로세스 중에 폐기 통지를 인쇄하세요.

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

  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. 새로운 PostgreSQL 버전에 대한 gitlab-org/gitlab 레포의 야간 테스트를 실행합니다.
  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가 이전에 사용된 버전으로 성공적으로 다운그레이드되는지 확인합니다. Geo 보조 독립형 추적 데이터베이스에서도 포함됩니다.
  9. 기본 PostgreSQL 버전이 변경되는 경우, 외부 PostgreSQL 데이터베이스로 GitLab 업그레이드를 테스트합니다.
  10. 백업 및 복원.

기본 PostgreSQL 버전이 변경되는 경우:

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

최소 요구 버전이 변경되는 경우:

  1. 오래된 버전의 Omnibus 관리 PostgreSQL이 여전히 설치되어 있으면 GitLab 업그레이드가 실패합니다.

위의 테스트가 수동인 경우, 수동 테스트가 수행된 후 도입된 파손 변경 사항을 놓칠 위험이 있습니다. 가능한 한 많은 테스트를 자동화해야 합니다.

  1. 패키지 빌드는 PostgreSQL의 두 버전을 포함합니다.
  2. gitlab-ctl pg-upgrade 실행이 작동합니다.

libpq의 경우

일부 모듈, 예를 들어 pyscopg2는 PostgreSQL 클라이언트 라이브러리인 libpq에 의존합니다. 항상 최신 번들 버전에 연결되어 있어야 합니다. 최신 버전을 사용함으로써 libpq의 하위 호환성에 의존합니다.

알려진 문제

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