이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-09-25. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

인스턴스로의 업그레이드와 관련된 알려진 문제

GitHub Enterprise Server의 업그레이드 프로세스에 영향을 주거나 업그레이드 완료 후 인스턴스에 영향을 주는 문제 해결 방법에 대한 개요를 확인하세요.

이 문서의 내용

GitHub Enterprise Server 업그레이드와 관련된 알려진 문제 정보

GitHub은(는) GitHub Enterprise Server의 새 릴리스로 업그레이드하는 데 영향을 줄 수 있는 다음과 같은 문제를 알고 있습니다. 자세한 내용은 [은(는) 인스턴스의 구성 및 데이터를 정기적으로 백업하도록 권장합니다. 업그레이드를 진행하기 전에 인스턴스를 백업한 다음 스테이징 환경에서 백업의 유효성을 검사합니다. 자세한 내용은 "인스턴스에서 백업 구성" 및 "스테이징 인스턴스 설정"을(를) 참조하세요.

GitHub Enterprise Server 3.9 혹은 그 이상의 MySQL 8 업그레이드로 I/O 사용률 증가

GitHub Enterprise Server 3.7 또는 3.8 이상에서 3.9 이상으로 업그레이드하는 경우 인스턴스의 데이터베이스 소프트웨어로 업그레이드하면 I/O 사용률이 증가합니다. 경우에 따라 인스턴스의 성능에 영향을 줄 수 있습니다.

GitHub Enterprise Server에는 InnoDB 스토리지 엔진에서 지원하는 MySQL 데이터베이스 서버가 포함되어 있습니다. GitHub Enterprise Server 3.8 이하의 경우 MySQL 5.7을 사용합니다. 2023년 10월에 Oracle은 MySQL 5.7에 대한 추가 지원을 종료합니다. 자세한 내용은 Oracle 지원 웹 사이트의 Oracle 수명 지원 정책을 참조하세요.

GitHub Enterprise Server의 미래 경쟁력을 보장하고 최신 보안 업데이트, 버그 수정, 성능 향상을 지원하기 위해 GitHub Enterprise Server 3.9 이상은 MySQL 8.0을 사용합니다. MySQL 8.0은 재설계된 REDO 로그로 QPS(초당 쿼리 수)가 더 높습니다. 자세한 내용은 DimitriK's (dim) Weblog의 MySQL 성능: 8.0의 다시 실행 로그 및 ReadWrite 워크로드 재설계를 참조하세요.

GitHub Enterprise Server 3.9로 업그레이드한 후 인스턴스 성능이 허용할 수 없는 수준으로 저하된 경우 인스턴스의 모니터 대시보드에서 데이터를 수집하여 이러한 영향을 확인할 수 있습니다. 문제를 완화하는 시도를 하고 이 변경의 실제 영향을 프로파일링하고 전달하는 데 도움이 되도록 GitHub 지원에 해당 데이터를 제공할 수 있습니다.

경고: 이 업그레이드의 특성상 계속 진행하기 전에 인스턴스의 구성 및 데이터를 백업하세요. 스테이징 환경에서 백업의 유효성을 검사합니다. 자세한 내용은 "인스턴스에서 백업 구성" 및 "스테이징 인스턴스 설정"을(를) 참조하세요.

MySQL 업그레이드 전에 기준 I/O 사용률 데이터 수집

GitHub Enterprise Server 3.9 이상으로 업그레이드하기 전에 기준 데이터를 수집합니다. 기준 데이터 수집과 관련하여 GitHub은(는) 3.7 또는 3.8을 실행하는 GitHub Enterprise Server의 스테이징 인스턴스 설정하고 GitHub Enterprise Server Backup Utilities를 사용하여 생산 인스턴스에서 데이터를 복원하는 것이 좋습니다. 자세한 내용은 "스테이징 인스턴스 설정" 및 "인스턴스에서 백업 구성"을(를) 참조하세요.

프로덕션 환경에서 인스턴스가 경험하는 부하를 시뮬레이션하지 못할 수 있습니다. 그러나 스테이징 인스턴스의 프로덕션 환경에서 사용 패턴을 시뮬레이션하는 동안 기준 데이터를 수집할 수 있는 경우에 유용합니다.

  1. 인스턴스의 모니터 대시보드로 이동합니다. 자세한 내용은 "모니터 대시보드 액세스"을(를) 참조하세요.

  2. 모니터 대시보드에서 관련 그래프를 모니터링합니다.

    • "프로세스"에서 "I/O 작업(IOPS 읽기)" 및 "I/O 작업(쓰기 IOPS)" 그래프를 모니터링하고 mysqld에 대해 필터링합니다. 이 그래프는 노드의 모든 서비스에 대한 I/O 작업을 표시합니다.
    • "스토리지"에서 "디스크 사용률(데이터 디바이스 DEVICE-ID)" 그래프를 모니터링합니다. 이 그래프는 노드의 모든 I/O 작업에 소요된 시간을 표시합니다.

MySQL 업그레이드 후 I/O 사용률 데이터 검토

GitHub Enterprise Server 3.9로 업그레이드한 후 인스턴스의 I/O 사용률을 검토합니다. GitHub은(는) 생산 인스턴스에서 복원된 데이터를 포함하며 3.7 또는 3.8을 실행하는 GitHub Enterprise Server의 스테이징 인스턴스를 업그레이드하거나 생산 인스턴스의 데이터를 3.9를 실행하는 새 스테이징 인스턴스로 복원할 것을 권장합니다. 자세한 내용은 "스테이징 인스턴스 설정" 및 "인스턴스에서 백업 구성"을(를) 참조하세요.

  1. 인스턴스의 모니터 대시보드로 이동합니다. 자세한 내용은 "모니터 대시보드 액세스"을(를) 참조하세요.

  2. 모니터 대시보드에서 관련 그래프를 모니터링합니다.

    • "프로세스"에서 "I/O 작업(IOPS 읽기)" 및 "I/O 작업(쓰기 IOPS)" 그래프를 모니터링하고 mysqld에 대해 필터링합니다. 이 그래프는 노드의 모든 서비스에 대한 I/O 작업을 표시합니다.
    • "스토리지"에서 "디스크 사용률(데이터 디바이스 DEVICE ID)" 및 "디스크 대기 시간(데이터 DEVICE-ID)" 그래프를 모니터링합니다. 이 그래프는 전체 디스크의 대기 시간뿐만 아니라 노드의 모든 I/O 작업에 소요된 시간을 표시합니다.
      • 디스크 대기 시간이 많이 증가하면 인스턴스가 디스크 IOPS를 완료될 때까지 대기하도록 강제하는 것일 수 있습니다.
      • 디스크가 모든 작업을 충분히 처리할 수 없음을 나타내는 것일 수 있는 "디스크 보류 작업(데이터 디바이스 DEVICE-ID)" 그래프를 검토하여 대기 시간의 증가를 확인할 수 있습니다.

MySQL 업그레이드의 영향 완화

허용할 수 없는 성능 저하 문제를 해결하기 위해 GitHub은(는) 다음 솔루션을 권장합니다.

프로덕션 환경에서 완화 절차를 테스트하기 전에 인스턴스를 백업하고 백업의 유효성을 검사한 다음 스테이징 환경에서 절차를 테스트합니다. 자세한 내용은 "인스턴스에서 백업 구성" 및 "스테이징 인스턴스 설정"을(를) 참조하세요.

InnoDB의 플러시 메서드 조정

성능 영향 완화를 위해 각 쓰기 작업 후에 InnoDB의 플러시 메서드를 조정하여 fsync() 시스템을 건너뛸 수 있습니다. 자세한 내용은 MySQL 8.0 참조 설명서의 innodb_flush_method을 참조하세요.

다음 지침은 GitHub Enterprise Server 3.9 이상만 대상으로 합니다.

경고: 플러시 방법을 조정하려면 인스턴스의 저장 장치에 배터리 지원 캐시가 있어야 합니다. 디바이스의 캐시가 배터리로 지원되지 않으면 데이터 손실이 발생할 수 있습니다.

  • 온프레미스 데이터 센터 내에서 가상화 하이퍼바이저를 사용하여 인스턴스를 호스트하는 경우 스토리지 사양을 검토하고 확인합니다.
  • 퍼블릭 클라우드 서비스에서 인스턴스를 호스트하는 경우 공급자의 설명서 또는 지원 팀에 문의하여 확인합니다.

  1. 에 SSH합니다. 인스턴스가 여러 노드로 구성된 경우(예: 고가용성 또는 지역 복제가 구성된 경우) 주 노드에 대한 SSH를 수행합니다. 클러스터를 사용하는 경우 임의 노드에 대해 SSH를 수행할 수 있습니다. HOSTNAME을 인스턴스의 호스트 이름 또는 노드의 호스트 이름이나 IP 주소로 바꿉니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.

    Shell
    ssh -p 122 admin@HOSTNAME

  2. InnoDB에 대한 현재 플러시 메서드의 유효성을 검사하려면 다음 명령을 실행합니다.

    Shell
    ghe-config mysql.innodb-flush-no-fsync

    기본적으로 명령은 각 쓰기 작업 후에 인스턴스가 fsync()시스템 호출을 수행함을 나타내는 false를 반환합니다.

  3. 각 쓰기 작업 후에 fsync() 시스템 호출을 건너뛰도록 InnoDB를 구성하려면 다음 명령을 실행합니다.

    Shell
    ghe-config mysql.innodb-flush-no-fsync true

  4. 구성을 적용하려면 다음 명령을 실행합니다.

    참고: 구성을 실행하는 동안 의 서비스가 다시 시작될 수 있으므로 짧은 가동 중지 시간이 발생할 수 있습니다.

    Shell
    ghe-config-apply

  5. 구성 실행이 완료될 때까지 기다립니다.

인스턴스의 스토리지 업그레이드

인스턴스 노드에 더 빠른 스토리지를 프로비전하여 보류 중인 작업을 줄이고, IOPS는 늘리고, 성능을 개선할수 있습니다. 인스턴스의 스토리지를 업그레이드하려면 인스턴스를 백업하고 백업을 새 대체 인스턴스로 복원합니다. 자세한 내용은 "인스턴스에서 백업 구성"을(를) 참조하세요.

GitHub과(와) 데이터 공유

마지막으로 GitHub이(가) MySQL 8로 업그레이드할 때의 실제 영향을 이해하도록 돕고자 하는 경우 수집한 데이터를 GitHub 지원에 제공할 수 있습니다. 데이터를 수집한 기간에 사용한 지원 번들과 함께 모니터 대시보드에서 기준과 업그레이드 후 관찰 내용을 제공합니다. 자세한 내용은 "GitHub 지원 정보" 및 "GitHub 지원에 데이터 제공"을(를) 참조하세요.

제출하는 데이터는 GitHub이(가) 계속해서 우수한 성능의 제품을 제공하는 데 도움이 되지만 GitHub은(는) 사용자가 제공한 데이터의 결과로 제품에 대한 추가 완화 단계 또는 변경을 보장하지 않습니다.

GitHub Enterprise Server 3.9 또는 3.10으로 업그레이드 후 MySQL이 시작되지 않음

GitHub Enterprise Server 3.9(3.7 또는 3.8에서) 또는 3.10(3.8에서만 해당)로 업그레이드하는 중에 GitHub Enterprise Server 3.7 또는 3.8 인스턴스가 종료되는 동안 MySQL이 정상적으로 종료되지 않은 경우 MySQL은 GitHub Enterprise Server 3.9 또는 3.10 인스턴스가 시작될 때 크래시 복구를 시도합니다. GitHub Enterprise Server 3.7 및 3.8에서는 MySQL 5.7을 사용하고 GitHub Enterprise Server 3.9 및 3.10이 MySQL 8.0으로 업그레이드되었으므로 MySQL은 충돌 복구를 완료할 수 없습니다.

GitHub Enterprise Server 3.9에서 3.10으로 업그레이드하는 경우 인스턴스에서 MySQL이 이미 5.7에서 8.0으로 업그레이드되었으므로 이 문제의 영향을 받지 않습니다.

이 문제가 발생하면 mysql 오류 로그(/var/log/mysql/mysql.err)에 다음 오류가 발생합니다.

Shell
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

이 문제 방지하기

3.9 또는 3.10으로 업그레이드하기 전에 GitHub Enterprise Server 인스턴스를 최신 패치 버전(3.7.14 이상 또는 3.8.7 이상)으로 업그레이드하는 것이 좋습니다. 해당 버전은 업그레이드 문제에 대한 수정 사항이 적용되었습니다.

GitHub Enterprise Server 인스턴스을(를) 업그레이드할 수 없는 경우 GitHub Enterprise Server 3.9(3.7 또는 3.8에서) 또는 3.10(3.8에서만 해당)으로 업그레이드하기 전에 MySQL의 Nomad 시간 제한을 업데이트하여 문제를 방지할 수 있습니다.

  1. 인스턴스를 유지 관리 모드로 전환합니다.

    Shell
    ghe-maintenance -s

  2. Nomad의 Consul 템플릿을 업데이트합니다.

    Shell
    sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl

  3. Nomad의 Consul 템플릿을 렌더링합니다.

    Shell
    sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl

  4. 현재 kill_timeout 설정 확인

    Shell
    nomad job inspect mysql | grep KillTimeout

    예상 응답:

    Shell
    "KillTimeout": 5000000000

  5. MySQL을 중지합니다.

    Shell
    nomad job stop mysql

  6. 새 MySQL 작업을 실행합니다.

    Shell
    nomad job run /etc/nomad-jobs/mysql/mysql.hcl

  7. kill_timeout이 업데이트되었는지 확인합니다.

    Shell
    nomad job inspect mysql | grep KillTimeout

    예상 응답:

    Shell
    "KillTimeout": 600000000000,

  8. 인스턴스를 유지 관리 모드에서 제외합니다.

    Shell
    ghe-maintenance -u

이제 MySQL의 Nomad 시간 제한이 업데이트되어 GitHub Enterprise Server 인스턴스를 3.9로 업그레이드할 수 있습니다.

MySQL의 다시 시작 실패 문제 완화

이 문제의 영향을 받는 경우 GitHub Enterprise Server 인스턴스를 업그레이드 시도 전 상태로 복원한 다음 이전 섹션의 단계를 따릅니다.

실패한 업그레이드에서 복원하는 방법에 대한 자세한 내용은 "실패한 업그레이드에서 복원"을(를) 참조하세요.