Эта версия GitHub Enterprise Server была прекращена 2024-03-26. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Известные проблемы с обновлением экземпляра

Общие сведения о обходных решениях проблем, влияющих на процесс обновления для GitHub Enterprise Server, или влияют на экземпляр после завершения обновления.

В этой статье

О известных проблемах с обновлениями GitHub Enterprise Server

GitHub знает о следующих проблемах, которые могут повлиять на обновления до новых выпусков GitHub Enterprise Server. Дополнительные сведения см. в разделе "Известные проблемы" в заметках о выпуске GitHub Enterprise Server.

GitHub настоятельно рекомендует регулярные резервные копии конфигурации и данных экземпляра. Прежде чем продолжить обновление, создайте резервную копию экземпляра, а затем проверьте резервную копию в промежуточной среде. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Настройка резервных копий в экземпляре](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance)".

Увеличение использования операций ввода-вывода из Обновления MySQL 8 в GitHub Enterprise Server 3.9 или более поздней версии

При обновлении с GitHub Enterprise Server 3.7 или 3.8 до 3.9 или более поздней версии обновление до программного обеспечения базы данных в экземпляре увеличит использование операций ввода-вывода. В некоторых случаях это может повлиять на производительность экземпляра.

GitHub Enterprise Server включает сервер базы данных MySQL, поддерживаемый подсистемой хранилища InnoDB. GitHub Enterprise Server 3.8 и более ранних версий используют MySQL 5.7. В октябре 2023 года Oracle завершит расширенную поддержку MySQL 5.7. Дополнительные сведения см. в статье "Политика поддержки времени существования Oracle" на веб-сайте поддержки Oracle.

Для дальнейшего подтверждения GitHub Enterprise Server и предоставления последних обновлений системы безопасности, исправлений ошибок и повышения производительности GitHub Enterprise Server 3.9 и более поздних версий используйте MySQL 8.0. MySQL 8.0 достигает большего количества запросов в секунду (QPS) из-за обновленного журнала REDO. Дополнительные сведения см. в статье "Производительность MySQL: 8.0" повторно разработан журнал REDO и масштабируемость рабочих нагрузок ReadWrite в веб-журнале DimitriK (dim).

После обновления до GitHub Enterprise Server 3.9, если вы испытываете неприемлемое снижение производительности экземпляра, вы можете собирать данные с панели мониторинга вашего экземпляра, чтобы подтвердить влияние. Вы можете попытаться устранить проблему, и вы можете предоставить данные Служба поддержки GitHub, чтобы помочь профилировать и сообщить о реальных последствиях этого изменения.

Предупреждение. Из-за характера этого обновления создайте резервную копию конфигурации и данных экземпляра перед продолжением. Проверьте резервную копию в промежуточной среде. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Настройка резервных копий в экземпляре](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance)".

Сбор базовых данных об использовании операций ввода-вывода перед обновлением MySQL

Сбор базовых данных перед обновлением до GitHub Enterprise Server 3.9 или более поздней версии. Для сбора базовых данных GitHub рекомендует настроить промежуточный экземпляр GitHub Enterprise Server под управлением 3.7 или 3.8 и восстановить данные из рабочего экземпляра с помощью GitHub Enterprise Server Backup Utilities. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Настройка промежуточного экземпляра](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance)".

Возможно, вы не сможете имитировать нагрузку, которую выполняет ваш экземпляр в рабочей среде. Однако полезно, если вы можете собирать базовые данные при имитации шаблонов использования из рабочей среды в промежуточный экземпляр.

  1. Перейдите на панель мониторинга мониторинга экземпляра. Дополнительные сведения см. в разделе Доступ к панели мониторинга.

  2. На панели мониторинга монитора отслеживайте соответствующие графы.

    • В разделе "Процессы" отслеживайте графики операций ввода-вывода (операции ввода-вывода (операции чтения операций ввода-вывода)" и "Операции ввода-вывода (операции ввода-вывода (операции ввода-вывода)", фильтрация для mysqld. Эти графы отображают операции ввода-вывода для всех служб узла.
    • В разделе "служба хранилища" отслеживайте график использования дисков (идентификатор устройства данных)". На этом графике отображается время, затраченное на все операции ввода-вывода узла.

Просмотр данных об использовании операций ввода-вывода после обновления MySQL

После обновления до GitHub Enterprise Server 3.9 просмотрите использование ввода-вывода экземпляра. GitHub рекомендует обновить промежуточный экземпляр GitHub Enterprise Server под управлением 3.7 или 3.8, включая восстановленные данные из рабочего экземпляра или восстановить данные из рабочего экземпляра до новой промежуточный экземпляр с 3.9. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Настройка промежуточного экземпляра](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance)".

  1. Перейдите на панель мониторинга мониторинга экземпляра. Дополнительные сведения см. в разделе Доступ к панели мониторинга.

  2. На панели мониторинга монитора отслеживайте соответствующие графы.

    • В разделе "Процессы" отслеживайте графики операций ввода-вывода (операции ввода-вывода (операции чтения операций ввода-вывода)" и "Операции ввода-вывода (операции ввода-вывода (операции ввода-вывода)", фильтрация для mysqld. Эти графы отображают операции ввода-вывода для всех служб узла.
    • В разделе "служба хранилища" отслеживайте графики использования дисков (идентификатор устройства данных)" и "Задержка диска (идентификатор устройства данных)". На этом графике отображается время, затраченное на все операции ввода-вывода узла, а также общую задержку диска.
      • Значительное увеличение задержки на диске может указывать на то, что экземпляр заставляет операций ввода-вывода в секунду ждать завершения операций ввода-вывода в секунду.
      • Вы можете подтвердить наблюдение за увеличением задержки, просмотрев граф "Операции ожидания диска (идентификатор устройства данных)", что может указывать на то, что диск не может достаточно решать все операции.

Устранение последствий обновления MySQL

Для решения неприемлемого снижения производительности GitHub рекомендует следующие решения.

Прежде чем протестировать любую процедуру устранения рисков в рабочей среде, создайте резервную копию, проверьте резервную копию, а затем протестируйте процедуру в промежуточной среде. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Настройка резервных копий в экземпляре](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance)".

Настройка метода очистки InnoDB

Чтобы устранить влияние на производительность, можно настроить метод очистки InnoDB, чтобы пропустить fsync() системный вызов после каждой операции записи. Дополнительные сведения см innodb_flush_method . в руководстве по MySQL 8.0.

Следующие инструкции предназначены только для GitHub Enterprise Server 3.9 и более поздних версий.

Предупреждение. Для корректировки метода очистки требуется, чтобы устройство хранения экземпляра было кэшем с поддержкой батареи. Если кэш устройства не поддерживается от батареи, вы рискуете потерять данные.

  • Если вы размещаете экземпляр с помощью гипервизора виртуализации в локальном центре обработки данных, просмотрите спецификации хранилища, чтобы подтвердить.
  • Если вы размещаете экземпляр в общедоступной облачной службе, обратитесь к документации или группе поддержки вашего поставщика, чтобы подтвердить.

  1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME

  2. Чтобы проверить текущий метод очистки для InnoDB, выполните следующую команду.

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

    По умолчанию команда возвращается false, указывая, что экземпляр выполняет системный вызов после каждой fsync() операции записи.

  3. Чтобы настроить InnoDB для пропуска системного fsync() вызова после каждой операции записи, выполните следующую команду.

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

  4. Чтобы применить конфигурацию, выполните следующую команду.

    Примечание. Во время выполнения конфигурации службы на ваш экземпляр GitHub Enterprise Server могут перезапуститься, что может привести к краткому простою для пользователей.

    Shell
    ghe-config-apply

  5. Подождите завершения запуска конфигурации.

Обновление хранилища экземпляра

Вы можете сократить ожидающие операции, увеличить число операций ввода-вывода в секунду и повысить производительность, подготовив более быстрое хранилище для узлов экземпляра. Чтобы обновить хранилище экземпляра, создайте резервную копию и восстановите резервную копию до нового экземпляра замены. Дополнительные сведения см. в разделе Настройка резервных копий в экземпляре.

Совместное использование данных с помощью GitHub

Наконец, если вы готовы помочь GitHub понять реальное влияние обновления до MySQL 8, вы можете предоставить собранные данные до Служба поддержки GitHub. Предоставьте базовые и после обновления наблюдения на панели мониторинга, а также пакет поддержки, охватывающий период сбора данных. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Сведения о поддержке GitHub](/support/contacting-github-support/providing-data-to-github-support)".

Предоставленные данные помогают GitHub продолжать предоставлять продукт, но GitHub не гарантирует никаких дополнительных действий по устранению рисков или изменений в продукте в результате предоставленных данных.

MySQL не запускается после обновления до GitHub Enterprise Server 3.9 или 3.10

Во время обновления до GitHub Enterprise Server 3.9 (с 3.7 или 3.8) или 3.10 (только с 3.8), если MySQL не завершил работу во время завершения работы экземпляра GitHub Enterprise Server 3.7 или 3.8, 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

Избегайте этой проблемы

Мы настоятельно рекомендуем обновить экземпляр GitHub Enterprise Server до последней версии исправления (3.7.14 или более поздней версии или 3.8.7 или более поздней) перед обновлением до версии 3.9 или 3.10. Эти версии содержат исправление проблемы обновления.

Если не удается обновить ваш экземпляр GitHub Enterprise Server, можно избежать проблемы, обновив время ожидания кочевого устройства для MySQL перед началом обновления до GitHub Enterprise Server 3.9 (от 3.7 или 3.8) или 3.10 (только от 3.8).

  1. Поместите экземпляр в режим обслуживания:

    Shell
    ghe-maintenance -s

  2. Обновление шаблона consul для кочевников:

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

  3. Шаблон 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 обновлено, можно обновить экземпляр GitHub Enterprise Server до 3.9.

Устранение неудачной перезагрузки MySQL

Если вы столкнулись с этой проблемой, восстановите экземпляр GitHub Enterprise Server в состояние, которое было выполнено до попытки обновления, а затем выполните действия из предыдущего раздела.

Дополнительные сведения о восстановлении после сбоя обновления см. в разделе "Обновление GitHub Enterprise Server".