Help us learn about your current experience with the documentation. Take the survey.

使用 Linux 包的 Redis 复制和故障转移

  • Tier: Premium, Ultimate
  • Offering: GitLab Self-Managed

本文档适用于 Linux 包。要使用您自己的非捆绑 Redis，请参阅 使用自己的实例进行 Redis 复制和故障转移。

在 Redis 术语中，primary 被称为 master。在本文档中，我们使用 primary 而不是 master，除非在需要 master 的设置中。

在可扩展环境中使用 Redis 可以通过 主节点 x 副本 拓扑实现，并使用 Redis Sentinel 服务来监控并自动启动故障转移过程。

如果与 Sentinel 一起使用，Redis 需要身份验证。有关更多信息，请参阅 Redis 安全性 文档。我们建议使用 Redis 密码和严格的防火墙规则组合来保护您的 Redis 服务。 强烈建议您在配置 Redis 与 GitLab 之前阅读 Redis Sentinel 文档，以完全理解拓扑和架构。

在深入了解为复制拓扑设置 Redis 和 Redis Sentinel 的细节之前，请确保您通读整篇文档，以便更好地理解组件如何协同工作。

您至少需要 3 台独立的机器：物理机或在不同物理机上运行的虚拟机。至关重要的是，所有主节点和副本 Redis 实例必须在不同的机器上运行。如果您未能以这种方式配置机器，共享环境中的任何问题都可能导致整个设置崩溃。

可以在主节点或副本 Redis 实例旁边运行 Sentinel。但在同一台机器上不应有超过一个 Sentinel。

您还需要考虑底层网络拓扑，确保 Redis / Sentinel 和 GitLab 实例之间有冗余连接，否则网络将成为单点故障。

在扩展环境中运行 Redis 需要几个条件：

  • 多个 Redis 实例
  • 在 主节点 x 副本 拓扑中运行 Redis
  • 多个 Sentinel 实例
  • 应用程序对所有 Sentinel 和 Redis 实例的支持和可见性

Redis Sentinel 可以处理高可用环境中的最重要任务，即帮助服务器保持在线状态，实现最小或零停机时间。Redis Sentinel：

  • 监控 主节点 和 副本 实例以查看它们是否可用
  • 当 主节点 故障时，将 副本 提升为 主节点
  • 当故障的 主节点 恢复在线时，将其降级为 副本 （以防止数据分区）
  • 可以被应用程序查询，以始终连接到当前的 主节点 服务器

当 主节点 无法响应时，是应用程序的责任 （在我们的案例中是 GitLab）处理超时和重新连接（查询 Sentinel 以获取新的 主节点）。

为了更好地理解如何正确设置 Sentinel，请首先阅读 Redis Sentinel 文档，因为配置错误可能导致数据丢失或使整个集群崩溃，从而使故障转移工作无效。

推荐设置

对于最小设置，您需要在 3 台独立机器上安装 Linux 包，每台都配置 Redis 和 Sentinel：

  • Redis 主节点 + Sentinel
  • Redis 副本 + Sentinel
  • Redis 副本 + Sentinel

如果您不确定或不理解节点数量的来源和原因，请阅读 Redis 设置概述 和 Sentinel 设置概述。

对于能够承受更多故障的推荐设置，您需要在 5 台独立机器上安装 Linux 包，每台都配置 Redis 和 Sentinel：

  • Redis 主节点 + Sentinel
  • Redis 副本 + Sentinel
  • Redis 副本 + Sentinel
  • Redis 副本 + Sentinel
  • Redis 副本 + Sentinel

Redis 设置概述

您必须至少有 3 个 Redis 服务器：1 个主节点，2 个副本，并且它们需要各自位于独立的机器上。

您可以拥有额外的 Redis 节点，这有助于在更多节点宕机的情况下保持系统运行。当只有 2 个节点在线时，不会启动故障转移。

例如，如果您有 6 个 Redis 节点，最多可以同时有 3 个宕机。

Sentinel 节点有不同的要求。 如果将它们托管在相同的 Redis 机器上，在计算要配置的节点数量时，您可能需要考虑这些限制。有关更多信息，请参阅 Sentinel 设置概述 文档。

所有 Redis 节点应以相同方式配置，并具有相似的服务器规格，因为在故障转移情况下，任何 副本 都可以被 Sentinel 服务器提升为新的 主节点。

复制需要身份验证，因此您需要定义一个密码来保护所有 Redis 节点和 Sentinel。它们共享相同的密码，并且所有实例必须能够通过网络相互通信。

Sentinel 设置概述

Sentinel 监控其他 Sentinel 和 Redis 节点。当 Sentinel 检测到 Redis 节点没有响应时，它会向其他 Sentinel 宣布该节点的状态。Sentinel 必须达到 法定人数（同意节点宕机的最小 Sentinel 数量）才能启动故障转移。

当达到 法定人数 时，所有已知 Sentinel 节点的 多数 需要可用且可访问，以便它们能够选举 Sentinel 领导者，该领导者通过以下方式做出所有决策以恢复服务可用性：

  • 提升新的 主节点
  • 重新配置其他 副本，使它们指向新的 主节点
  • 向每个其他 Sentinel 对等节点宣布新的 主节点
  • 重新配置旧的 主节点，并在其恢复在线时降级为 副本

您必须至少有 3 个 Redis Sentinel 服务器，并且它们需要各自位于独立的机器上（这些机器被认为会独立故障），理想情况下位于不同的地理区域。

您可以在配置其他 Redis 服务器的同一台机器上配置它们，但要理解，如果整个节点宕机，您将同时失去一个 Sentinel 和一个 Redis 实例。

Sentinel 的数量理想情况下应始终是奇数，以便在发生故障时共识算法能够有效运行。

在 3 个节点的拓扑中，您只能承受 1 个 Sentinel 节点宕机。 当 Sentinel 的 多数 宕机时，网络分区保护会防止破坏性操作，并且故障转移不会启动。

以下是一些示例：

  • 有 5 或 6 个 sentinel，最多可以有 2 个宕机才能开始故障转移。
  • 有 7 个 sentinel，最多可以有 3 个节点宕机。

领导者 选举有时会在未达成 共识 时在投票轮次中失败。在这种情况下， 在 sentinel['failover_timeout']（以毫秒为单位）定义的时间后会进行新的尝试。

我们稍后会看到 sentinel['failover_timeout'] 的定义位置。

failover_timeout 变量有许多不同的用例。根据官方文档：

  • 在给定的 Sentinel 已经对同一主节点尝试过故障转移后，重新启动故障转移所需的时间是故障转移超时的两倍。

  • 根据 Sentinel 当前配置复制到错误主节点的副本，被强制复制到正确主节点所需的时间，正好是故障转移超时（从 Sentinel 检测到错误配置的时刻开始计算）。

  • 取消已经在进行中但未产生任何配置更改的故障转移所需的时间（REPLICAOF NO ONE 尚未被提升的副本确认）。

  • 正在进行的故障转移等待所有副本重新配置为新主节点的副本的最长时间。但即使在此时间之后，Sentinel 仍会重新配置副本，但不会按照指定的精确并行同步进度进行。

配置 Redis

这是安装和设置新 Redis 实例的部分。

假设您已经从头安装了 GitLab 及其所有组件。 如果您已经安装并运行了 Redis，请阅读如何 从单机安装切换。

Redis 节点（包括主节点和副本）需要在 redis['password'] 中定义相同的密码。在故障转移期间的任何时候，Sentinel 都可以重新配置节点并将其状态从主节点更改为副本，反之亦然。

要求

Redis 设置的要求如下：

  1. 按照 推荐设置 部分中的说明配置所需的最小数量的实例。
  2. 我们不建议在运行 GitLab 应用程序的同一台机器上安装 Redis 或 Redis Sentinel，因为这会削弱您的高可用配置。但是，您可以选择在同一台机器上安装 Redis 和 Sentinel。
  3. 所有 Redis 节点必须能够相互通信，并通过 Redis（6379）和 Sentinel（26379）端口接受传入连接（除非您更改默认端口）。
  4. 托管 GitLab 应用程序的服务器必须能够访问 Redis 节点。
  5. 使用防火墙保护节点免受外部网络（Internet）的访问。

从现有的单机安装切换

如果您已经有运行中的单机 GitLab 安装，您需要先从此机器进行复制，然后再停用其中的 Redis 实例。

您的单机安装是初始的 主节点，其他 3 个节点应配置为指向此机器的 副本。

复制赶上后，您需要在单机安装中停止服务，将 主节点 轮换到其中一个新节点。

在配置中进行必要的更改，然后再次重新启动新节点。

要在单机安装中禁用 Redis，请编辑 /etc/gitlab/gitlab.rb：

redis['enable'] = false

如果您没有先进行复制，可能会丢失数据（未处理的后台作业）。

步骤 1. 配置主 Redis 实例

  1. 通过 SSH 登录到 主节点 Redis 服务器。

  2. 使用 GitLab 下载页面上的 步骤 1 和 2 下载并安装 您想要的 Linux 包。

    • 确保您选择了正确的 Linux 包，与您当前安装的版本和类型（社区版、企业版）相同。
    • 不要完成下载页面上的任何其他步骤。

  3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

    # 将服务器角色指定为 'redis_master_role'
roles ['redis_master_role']

# 指向其他机器可以访问的本地 IP 的 IP 地址。
# 您也可以将 bind 设置为 '0.0.0.0'，这样会在所有接口上监听。
# 如果确实需要绑定到外部可访问的 IP，请确保添加额外的防火墙规则以防止未经授权的访问。
redis['bind'] = '10.0.0.1'

# 定义一个端口，以便 Redis 可以监听 TCP 请求，允许其他机器连接到它。
redis['port'] = 6379

# 为 Redis 设置密码身份验证（在所有节点中使用相同的密码）。
redis['password'] = 'redis-password-goes-here'

  4. 只有主 GitLab 应用程序服务器应该处理数据库迁移。要防止在升级时运行数据库迁移，请将以下配置添加到您的 /etc/gitlab/gitlab.rb 文件中：

    gitlab_rails['auto_migrate'] = false

  5. 重新配置 GitLab 以使更改生效。

您可以指定多个角色，如 sentinel 和 Redis，如下所示： roles ['redis_sentinel_role', 'redis_master_role']。 阅读更多关于 角色 的信息。

步骤 2. 配置副本 Redis 实例

  1. 通过 SSH 登录到 副本 Redis 服务器。

  2. 使用 GitLab 下载页面上的 步骤 1 和 2 下载并安装 您想要的 Linux 包。

    • 确保您选择了正确的 Linux 包，与您当前安装的版本和类型（社区版、企业版）相同。
    • 不要完成下载页面上的任何其他步骤。

  3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

    # 将服务器角色指定为 'redis_replica_role'
roles ['redis_replica_role']

# 指向其他机器可以访问的本地 IP 的 IP 地址。
# 您也可以将 bind 设置为 '0.0.0.0'，这样会在所有接口上监听。
# 如果确实需要绑定到外部可访问的 IP，请确保添加额外的防火墙规则以防止未经授权的访问。
redis['bind'] = '10.0.0.2'

# 定义一个端口，以便 Redis 可以监听 TCP 请求，允许其他机器连接到它。
redis['port'] = 6379

# 您为主节点设置的 Redis 身份验证的相同密码。
redis['password'] = 'redis-password-goes-here'

# 主 Redis 节点的 IP。
redis['master_ip'] = '10.0.0.1'

# 主 Redis 服务器的端口，取消注释以更改为非默认值。默认为 `6379`。
#redis['master_port'] = 6379

  4. 要防止在升级时自动运行重新配置，请执行：

    sudo touch /etc/gitlab/skip-auto-reconfigure

  5. 只有主 GitLab 应用程序服务器应该处理数据库迁移。要防止在升级时运行数据库迁移，请将以下配置添加到您的 /etc/gitlab/gitlab.rb 文件中：

    gitlab_rails['auto_migrate'] = false

  6. 重新配置 GitLab 以使更改生效。

  7. 为所有其他副本节点重复这些步骤。

您可以指定多个角色，如 sentinel 和 Redis，如下所示： roles ['redis_sentinel_role', 'redis_master_role']。 阅读更多关于 角色 的信息。

在 /etc/gitlab/gitlab.rb 中，这些值在故障转移后不需要再次更改，因为节点由 Sentinel 管理，即使在 gitlab-ctl reconfigure 之后，它们也会被相同的 Sentinel 恢复配置。

步骤 3. 配置 Redis Sentinel 实例

Sentinel 密码身份验证支持 是在 GitLab 16.1 中引入的。

现在 Redis 服务器都已设置完毕，让我们配置 Sentinel 服务器。

如果您不确定 Redis 服务器是否正常工作并正确复制，请阅读 故障排除复制 并在进行 Sentinel 设置之前修复它。

您必须至少有 3 个 Redis Sentinel 服务器，并且它们需要各自位于独立的机器上。您可以在配置其他 Redis 服务器的同一台机器上配置它们。

使用 GitLab 企业版，您可以使用 Linux 包在多台机器上设置 Sentinel 守护进程。

  1. 通过 SSH 登录到托管 Redis Sentinel 的服务器。

  2. 如果 Sentinel 与其他 Redis 实例托管在同一节点上，则可以省略此步骤。

    使用 GitLab 下载页面上的 步骤 1 和 2 下载并安装 Linux 企业版包。

    • 确保您选择了正确的 Linux 包，与 GitLab 应用程序运行的版本相同。
    • 不要完成下载页面上的任何其他步骤。

  3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容（如果您在与其他 Redis 实例相同的节点上安装 Sentinel，以下某些值可能是重复的）：

    roles ['redis_sentinel_role']

# 在每个 sentinel 节点中必须相同
redis['master_name'] = 'gitlab-redis'

# 您为主节点设置的 Redis 身份验证的相同密码。
redis['master_password'] = 'redis-password-goes-here'

# 主 Redis 节点的 IP。
redis['master_ip'] = '10.0.0.1'

# 定义一个端口，以便 Redis 可以监听 TCP 请求，允许其他机器连接到它。
redis['port'] = 6379

# 主 Redis 服务器的端口，取消注释以更改为非默认值。默认为 `6379`。
#redis['master_port'] = 6379

## 配置 Sentinel
sentinel['bind'] = '10.0.0.1'

## Sentinel 身份验证的可选密码。默认不需要密码。
# sentinel['password'] = 'sentinel-password-goes here'

# Sentinel 监听的端口，取消注释以更改为非默认值。默认为 `26379`。
# sentinel['port'] = 26379

## 法定人数必须反映启动故障转移所需的投票 sentinel 数量。
## 值不得大于 sentinel 的数量。
##
## 法定人数可用于以两种方式调整 Sentinel：
## 1. 如果法定人数设置为我们部署的 Sentinel 多数以下的值，
##    我们基本上使 Sentinel 对主节点故障更敏感，
##    只要少数 Sentinel 无法与主节点通信，就会触发故障转移。
## 1. 如果法定人数设置为大于 Sentinel 多数的值，
##    我们使 Sentinel 只有在大量（大于多数）连接良好的 Sentinel
##    同意主节点宕机时才能进行故障转移。
sentinel['quorum'] = 2

## 在 x 毫秒后将无响应的服务器视为宕机。
# sentinel['down_after_milliseconds'] = 10000

## 以毫秒为单位指定故障转移超时。它在许多方面使用：
##
## - 在给定的 Sentinel 已经对同一主节点尝试过故障转移后，
##   重新启动故障转移所需的时间是故障转移超时的两倍。
##
## - 根据 Sentinel 当前配置复制到错误主节点的副本，
##   被强制复制到正确主节点所需的时间，
##   正好是故障转移超时（从 Sentinel 检测到错误配置的时刻开始计算）。
##
## - 取消已经在进行中但未产生任何配置更改的故障转移所需的时间
##   （REPLICAOF NO ONE 尚未被提升的副本确认）。
##
## - 正在进行的故障转移等待所有副本重新配置为新主节点的副本的最长时间。
##   但即使在此时间之后，Sentinel 仍会重新配置副本，
##   但不会按照指定的精确并行同步进度进行。
# sentinel['failover_timeout'] = 60000

  4. 要防止在升级时运行数据库迁移，请执行：

    sudo touch /etc/gitlab/skip-auto-reconfigure

    只有主 GitLab 应用程序服务器应该处理数据库迁移。

  5. 重新配置 GitLab 以使更改生效。

  6. 为所有其他 Sentinel 节点重复这些步骤。

步骤 4. 配置 GitLab 应用程序

最后一步是通知主 GitLab 应用程序服务器 Redis Sentinel 服务器和身份验证凭据。

您可以在新安装或现有安装中随时启用或禁用 Sentinel 支持。从 GitLab 应用程序的角度来看，它只需要 Sentinel 节点的正确凭据。

虽然它不需要所有 Sentinel 节点的列表，但在发生故障时，它需要至少访问其中一个列出的节点。

以下步骤应在 GitLab 应用程序服务器中执行，对于高可用设置，理想情况下不应在其上运行 Redis 或 Sentinel。

  1. 通过 SSH 登录到安装 GitLab 应用程序的服务器。

  2. 编辑 /etc/gitlab/gitlab.rb 并添加/更改以下行：

    ## 在每个 sentinel 节点中必须相同
redis['master_name'] = 'gitlab-redis'

## 您为主节点设置的 Redis 身份验证的相同密码。
redis['master_password'] = 'redis-password-goes-here'

## 包含 `host` 和 `port` 的 sentinel 列表
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # 取消注释并设置为与 sentinel['password'] 相同的值

  3. 重新配置 GitLab 以使更改生效。

步骤 5. 启用监控

如果您启用监控，必须在所有 Redis 服务器上启用。

  1. 确保收集 CONSUL_SERVER_NODES，它们是 Consul 服务器节点的 IP 地址或 DNS 记录，以备下一步使用。请注意，它们以 Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z 的形式呈现。

  2. 创建/编辑 /etc/gitlab/gitlab.rb 并添加以下配置：

    # 为 Prometheus 启用服务发现
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

# 替换占位符
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
# 替换为 Consul 服务器节点的地址
consul['configuration'] = {
   retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
}

# 设置导出器监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

  3. 运行 sudo gitlab-ctl reconfigure 以编译配置。

1 个主节点、2 个副本和 3 个 Sentinel 的最小配置示例

在此示例中，我们假设所有服务器都有内部网络接口，IP 地址在 10.0.0.x 范围内，并且它们可以使用这些 IP 相互连接。

在实际使用中，您还需要设置防火墙规则，防止其他机器的未经授权访问，并阻止来自外部（Internet）的流量。

我们使用在 Redis 设置概述 和 Sentinel 设置概述 文档中讨论的具有 Redis + Sentinel 拓扑的相同 3 个节点。

以下是每台机器及其分配的IP的列表和描述：

  • 10.0.0.1：Redis 主节点 + Sentinel 1
  • 10.0.0.2：Redis 副本 1 + Sentinel 2
  • 10.0.0.3：Redis 副本 2 + Sentinel 3
  • 10.0.0.4：GitLab 应用程序

初始配置后，如果故障转移由 Sentinel 节点启动，Redis 节点将被重新配置，主节点将永久从一个节点更改为另一个节点（包括在 redis.conf 中），直到再次启动新的故障转移。

sentinel.conf 也会发生同样的情况，它在初始执行后被覆盖，在任何新的 sentinel 节点开始监视 主节点 后，或者故障转移提升不同的 主节点 时。

Redis 主节点和 Sentinel 1 的示例配置

在 /etc/gitlab/gitlab.rb 中：

roles ['redis_sentinel_role', 'redis_master_role']
redis['bind'] = '10.0.0.1'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_name'] = 'gitlab-redis' # 在每个 sentinel 节点中必须相同
redis['master_password'] = 'redis-password-goes-here' # 与主节点实例中 redis['password'] 定义的值相同
redis['master_ip'] = '10.0.0.1' # 初始主 redis 实例的 ip
#redis['master_port'] = 6379 # 初始主 redis 实例的端口，取消注释以更改为非默认值
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # 在每个 sentinel 节点中必须相同，取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置 GitLab 以使更改生效。

Redis 副本 1 和 Sentinel 2 的示例配置

在 /etc/gitlab/gitlab.rb 中：

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.2'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # 主 Redis 服务器的 IP
#redis['master_port'] = 6379 # 主 Redis 服务器的端口，取消注释以更改为非默认值
redis['master_name'] = 'gitlab-redis' # 在每个 sentinel 节点中必须相同
sentinel['bind'] = '10.0.0.2'
# sentinel['password'] = 'sentinel-password-goes-here' # 在每个 sentinel 节点中必须相同，取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置 GitLab 以使更改生效。

Redis 副本 2 和 Sentinel 3 的示例配置

在 /etc/gitlab/gitlab.rb 中：

roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.3'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_password'] = 'redis-password-goes-here'
redis['master_ip'] = '10.0.0.1' # 主 Redis 服务器的 IP
#redis['master_port'] = 6379 # 主 Redis 服务器的端口，取消注释以更改为非默认值
redis['master_name'] = 'gitlab-redis' # 在每个 sentinel 节点中必须相同
sentinel['bind'] = '10.0.0.3'
# sentinel['password'] = 'sentinel-password-goes-here' # 在每个 sentinel 节点中必须相同，取消注释以设置密码
# sentinel['port'] = 26379 # 取消注释以更改默认端口
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

重新配置 GitLab 以使更改生效。

GitLab 应用程序的示例配置

在 /etc/gitlab/gitlab.rb 中：

redis['master_name'] = 'gitlab-redis'
redis['master_password'] = 'redis-password-goes-here'
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # 取消注释并设置为与 sentinel['password'] 相同的值

重新配置 GitLab 以使更改生效。

高级配置

本节涵盖超出推荐和最小配置的配置选项。

运行多个 Redis 集群

Linux 包支持为不同的持久化类运行单独的 Redis 和 Sentinel 实例。

类 用途
cache 存储缓存数据。
queues 存储 Sidekiq 后台作业。
shared_state 存储会话相关和其他持久性数据。
actioncable ActionCable 的发布/订阅队列后端。
trace_chunks 存储 CI 跟踪块 数据。
rate_limiting 存储 速率限制 状态。
sessions 存储会话。
repository_cache 存储特定于仓库的缓存数据。

要使其与 Sentinel 一起工作：

  1. 根据您的需求 配置不同的 Redis/Sentinel 实例。

  2. 对于每个 Rails 应用程序实例，编辑其 /etc/gitlab/gitlab.rb 文件：

    gitlab_rails['redis_cache_instance'] = REDIS_CACHE_URL
gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
gitlab_rails['redis_actioncable_instance'] = REDIS_ACTIONCABLE_URL
gitlab_rails['redis_trace_chunks_instance'] = REDIS_TRACE_CHUNKS_URL
gitlab_rails['redis_rate_limiting_instance'] = REDIS_RATE_LIMITING_URL
gitlab_rails['redis_sessions_instance'] = REDIS_SESSIONS_URL
gitlab_rails['redis_repository_cache_instance'] = REDIS_REPOSITORY_CACHE_URL

# 配置 Sentinel
gitlab_rails['redis_cache_sentinels'] = [
  { host: REDIS_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REDIS_CACHE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_queues_sentinels'] = [
  { host: REDIS_QUEUES_SENTINEL_HOST, port: 26379 },
  { host: REDIS_QUEUES_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_shared_state_sentinels'] = [
  { host: SHARED_STATE_SENTINEL_HOST, port: 26379 },
  { host: SHARED_STATE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_actioncable_sentinels'] = [
  { host: ACTIONCABLE_SENTINEL_HOST, port: 26379 },
  { host: ACTIONCABLE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_trace_chunks_sentinels'] = [
  { host: TRACE_CHUNKS_SENTINEL_HOST, port: 26379 },
  { host: TRACE_CHUNKS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_rate_limiting_sentinels'] = [
  { host: RATE_LIMITING_SENTINEL_HOST, port: 26379 },
  { host: RATE_LIMITING_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_sessions_sentinels'] = [
  { host: SESSIONS_SENTINEL_HOST, port: 26379 },
  { host: SESSIONS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_repository_cache_sentinels'] = [
  { host: REPOSITORY_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REPOSITORY_CACHE_SENTINEL_HOST2, port: 26379 }
]

# gitlab_rails['redis_cache_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-password-goes-here'
# gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-password-goes-here'
    • Redis URL 应采用以下格式：redis://:PASSWORD@SENTINEL_PRIMARY_NAME，其中：
      • PASSWORD 是 Redis 实例的明文密码。
      • SENTINEL_PRIMARY_NAME 是使用 redis['master_name'] 设置的 Sentinel 主节点名称，例如 gitlab-redis-cache。

  3. 保存文件并重新配置 GitLab 以使更改生效：

    sudo gitlab-ctl reconfigure

对于每个持久化类，除非被前面描述的设置覆盖，否则 GitLab 默认使用 gitlab_rails['redis_sentinels'] 中指定的配置。

控制运行服务

在前面的示例中，我们使用了 redis_sentinel_role 和 redis_master_role，这简化了配置更改的数量。

如果您想要更多控制，以下是每个角色在启用时自动为您设置的内容：

## Redis Sentinel 角色
redis_sentinel_role['enable'] = true

# 当启用 Sentinel 角色时，以下服务也会启用
sentinel['enable'] = true

# 以下服务被禁用
redis['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

-------

## Redis 主节点/副本角色
redis_master_role['enable'] = true # 只启用其中一个
redis_replica_role['enable'] = true # 只启用其中一个

# 当启用 Redis 主节点或副本角色时，以下服务会被启用/禁用。
# 如果 Redis 和 Sentinel 角色结合使用，则两个服务都会启用。

# 以下服务被禁用
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# 对于 Redis 副本角色，还要将此设置从默认的 'true' 更改为 'false'：
redis['master'] = false

您可以在 gitlab_rails.rb 中找到定义的相关属性。

控制启动行为

要防止捆绑的 Redis 服务在启动时启动或在更改其配置后重新启动：

  1. 编辑 /etc/gitlab/gitlab.rb：

    redis['start_down'] = true

  2. 重新配置 GitLab：

    sudo gitlab-ctl reconfigure

如果您需要测试新的副本节点，可以将 start_down 设置为 true 并手动启动该节点。在确认新的副本节点在 Redis 集群中正常工作后，将 start_down 设置为 false 并重新配置 GitLab，以确保节点在运行期间按预期启动和重新启动。

控制副本配置

要防止 replicaof 行出现在 Redis 配置文件中：

  1. 编辑 /etc/gitlab/gitlab.rb：

    redis['set_replicaof'] = false

  2. 重新配置 GitLab：

    sudo gitlab-ctl reconfigure

此设置可用于独立于其他 Redis 设置防止 Redis 节点的复制。

故障排除

请参阅 Redis 故障排除指南。

进一步阅读

阅读更多：

  1. 参考架构
  2. 配置数据库
  3. 配置 NFS
  4. 配置负载均衡器