副本类型和功能
HA 部署中使用的不同类型的副本是什么？
高可用性 (HA) 部署中有三种类型的副本：
-
被动副本
-
活动副本
-
缓存副本（称为存储库缓存）。
**被动副本** 只是从主实例同步数据，并且不会处理任何 GitHub 流量。 但是，如果需要，操作员可以将被动副本提升为主副本。 **异地副本**是**活动副本**的一个示例（这些术语通常可互换使用）。 活动副本从主副本同步数据。 活动副本还可以直接处理 GitHub 流量，或将其代理到主要副本。 **缓存副本** 从主要副本同步 Git 和 Git 大型文件存储（Git LFS）数据。 缓存副本专为读取密集型场景设计，例如 CI 场。 它们仅接受对其具有本地副本的存储库的读取/提取/克隆。 对于任何其他存储库，它们将返回错误。 它们始终使用失败消息拒绝推送。
所有副本类型都可以提升为主节点吗？
仅被动和主动副本可以提升为主节点。 缓存副本无法提升为主副本。
单个部署是否可以包含所有副本？
单个部署可以同时包括主动副本、被动副本和缓存副本。
主实例是否会等待副本完成写入操作？
主实例在进行写入操作时不会等待副本的响应。 在 HA 中，推送会写入主节点以及所有被动和主动副本。 但是，由于主节点是唯一的投票节点，当推送在主节点上成功时，即被视为已接受。
通信和网络要求
哪些实体可以与主动副本通信？
主实例与活动副本通信以进行数据同步，并处理由活动副本代理返回给主实例的任何请求。 GitHub Web、API 和 Git 流量（来自人工和自动化）可以直接路由到主动副本。 因此配置 DNS 非常重要，以便用于活动副本的流量实际上到达它。
哪些实体可以与被动副本通信？
主实例与被动副本通信以同步数据。 被动副本不会接收或处理任何其他 GitHub 流量。
哪些实体可以与缓存副本通信？
只读 Git 流量（主要来自 CI 场等自动化）可以路由到缓存副本并由其处理。 若要启用此功能，应将 DNS 配置为将相关流量定向到缓存副本。 缓存副本并非设计用于服务用户流量或推送流量。
副本是否应与主要副本并置？
无需将副本与主副本并置。 根据定义，异地副本在地理上与主要副本相距，而不是在同一数据中心。 缓存副本也没有任何共同位置要求。
但是，建议至少有一个被动副本与同一数据中心的主副本共存，以便在主服务中断期间更快地进行故障转移。 在整个数据中心中断的情况下，你可以提升地理分布的被动副本。
主和副本之间的延迟要求是什么？
主副本和活动副本具有严格的延迟要求。 主要副本和被动副本以及主要副本和缓存副本都有建议的延迟要求。 有关详细信息，请参阅 创建高可用性副本 和 监视高可用性系统配置。 超出所需值和建议值的网络延迟可能会导致副本不断滞后。
管理访问和监控
副本上是否提供 管理控制台？
管理控制台 在被动副本和缓存副本中不可用。 它仅适用于活动副本（活动副本将大部分请求转发到主副本）。
是否可以通过 SSH 连接到副本？
具有管理外壳访问权限的操作员可以通过 SSH 连接到任何副本。 在将副本添加到集群之前，管理员可以通过 数据变量.enterprise.management_console %} 将其公钥添加到新副本中。 有关详细信息，请参阅“访问管理 shell (SSH)”。
副本的支持捆绑包如何工作？
可以生成群集捆绑包或特定于节点的捆绑包。 群集捆绑包包括 HA 部署中所有节点的捆绑包，而特定于节点的捆绑包仅包含来自一个节点的数据。
副本能被监控吗？如何实现监控？
可以对所有副本进行监控。 主实例上的 管理控制台 为所有节点提供仪表板，包括部署中的被动和主动副本节点。
此外，还可以将部署中的所有节点的指标和日志导出到第三方监视平台。
若要了解如何监视副本节点之间的数据复制状态，请参阅 监视高可用性系统配置。
副本和备份之间的差异
副本和备份是否相同？
副本和备份不同。 它们服务于不同的目的。
备份用于创建可还原到另一个 GitHub Enterprise Server 环境的数据副本。 客户通常使用备份从灾难中恢复，或创建新的安装。 简而言之，备份数据用于还原另一个 GitHub Enterprise Server 实例，而副本专为实时高可用性和冗余设计。
副本本身是 GitHub Enterprise Server 实例。 备份主机不是 GitHub Enterprise Server 安装。
哪些软件在副本上运行？
副本是 GitHub Enterprise Server 的单独安装。 主实例和所有副本应运行相同版本的 GitHub Enterprise Server。
维护操作
推荐的升级操作顺序是什么？
- 在主数据库和所有副本上启动维护窗口。
- 停止所有副本上的复制。
- 将主数据库升级到目标版本。
- 将副本升级到同一目标版本。 可以并行升级所有副本。
- 完成所有升级后，重启复制过程。
- 关闭维护窗口。
有时，客户可能希望将副本升级推迟到以后。 在这种情况下，请从部署中删除副本节点，并将其转换为独立节点。 将其升级到与主数据库相同的版本，然后将其添加回部署。
热补丁的推荐操作顺序是什么？
热补丁可以最小中断执行。 可以先对主节点进行热修补，然后再对副本进行热修补。
选择正确的副本类型
何时使用被动副本？
如果你需要高可用性，并希望在主节点故障时可以故障转移到最新实例，被动副本是最佳选择。 我们的大多数客户都使用备用副本。
何时使用异地副本？
如果你有地理分散的开发人员员工，则设置异地副本可以帮助特定区域中的用户。 例如，假设一家跨国公司在北美、欧洲和亚洲拥有工程团队。 如果主实例位于美国，则在欧洲部署异地副本可以显著提高欧洲用户读取作的性能。 然而，对于写操作而言，情况并非如此。 所有写入必须在操作完成前同时到达地理副本和主节点。 主副本和副本之间的地理距离会增加延迟，这可能会降低写入操作的速度。
何时使用缓存副本？
如果您的使用场景是读取密集型操作，例如 CI 集群，那么缓存副本更为适合。 下面是缓存副本有意义的几种方案：
- 一家在区域拥有小型卫星办公室的公司，其带宽有限，主要数据中心的开发人员需要更快地访问存储库，但不需要写入访问权限。
- 在远程数据中心运行 CI/CD 作业的组织，需要频繁克隆存储库，并希望将网络流量降到主实例。
设计上，缓存副本具有一些内在的权衡。 缓存副本最终是一致的，并不总是提供最新的存储库内容。 但是，当最新更改到达副本时，会有 Webhook，以便可以启动相关的 CI/CD 作业。 很少有 GitHub 客户使用缓存副本。