Redis 故障排查

要让 HA (高可用) 配置正常工作，必须妥善处理其中的诸多组件。

在进行以下故障排查之前，请先检查您的防火墙规则：

• Redis 机器
  • 接受 6379 端口的 TCP 连接
  • 通过 6379 端口的 TCP 连接到其他 Redis 机器
• Sentinel 机器
  • 接受 26379 端口的 TCP 连接
  • 通过 26379 端口的 TCP 连接到其他 Sentinel 机器
  • 通过 6379 端口的 TCP 连接到 Redis 机器

基本的 Redis 活动检查

首先，通过基本的 Redis 活动检查来开始 Redis 故障排查：

1. 在您的 GitLab 服务器上打开一个终端。
2. 运行 gitlab-redis-cli --stat 并观察其运行时的输出。
3. 前往您的 GitLab 界面，浏览几个页面。任何页面都可以，例如群组或项目概览、议题 (issue) 或仓库中的文件。
4. 再次检查 stat 输出，并验证在您浏览时，keys、clients、requests 和 connections 的值是否在增加。如果数字在增加，说明基本的 Redis 功能正在工作，并且 GitLab 可以连接到它。

排查 Redis 复制问题

您可以使用 redis-cli 应用连接到每个服务器，并发送如下所示的 info replication 命令，以此来检查一切是否正常。

/opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication

当连接到 Primary Redis 时，您会看到已连接的 replica (副本) 数量，以及每个副本的连接详细信息列表：

# Replication
role:master
connected_replicas:1
replica0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
master_repl_offset:208037658
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:206989083
repl_backlog_histlen:1048576

当连接到 replica (副本) 时，您会看到主节点连接的详细信息，以及其状态是 up (上线) 还是 down (下线)：

# Replication
role:replica
master_host:10.133.1.58
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
replica_repl_offset:208096498
replica_priority:100
replica_read_only:1
connected_replicas:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Redis 实例 CPU 使用率过高

默认情况下，GitLab 使用超过 600 个 Sidekiq 队列，每个队列都作为一个 Redis 列表存储。每个 Sidekiq 线程都会发出一个 BRPOP 命令，该命令包含一个长字符串中列出的所有队列。 随着队列数量和 BRPOP 调用频率的增加，Redis 的 CPU 使用率也会随之增长。如果您的 GitLab 实例有许多 Sidekiq 进程，这可能会导致 Redis 的 CPU 使用率接近 100%。高 CPU 使用率会显著降低 GitLab 的性能。

要减少 Sidekiq 导致的 Redis CPU 使用率，您可以：

• 使用 路由规则 (routing rules) 来减少 Sidekiq 队列的数量。
• 如果您使用的是 GitLab 16.6 及更早版本，请增加 SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 环境变量 的值以改善 Redis 的 CPU 使用率。 在 GitLab 16.7 及更高版本中，默认值为 5，这应该足够了。

SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 选项可以减少断开连接和重新连接所产生的开销，但会增加 Sidekiq 的关闭延迟。

排查 Sentinel 问题

如果您遇到类似 Redis::CannotConnectError: No sentinels available. 的错误，可能是您的配置文件有问题，也可能与 此 issue 有关。

您必须确保在 redis['master_name'] 和 redis['master_password'] 中定义的值与您为 sentinel 节点定义的值相同。

Redis 连接器 redis-rb 与 sentinel 协同工作的方式有点不太直观。我们尝试在 Linux 软件包中隐藏其复杂性，但它仍然需要一些额外的配置。

为确保您的配置正确：

1. 通过 SSH 登录到您的 GitLab 应用服务器

2. 进入 Rails 控制台：

   # For Omnibus installations
   sudo gitlab-rails console
   
   # For source installations
   sudo -u git rails console -e production

3. 在控制台中运行：

   redis = Gitlab::Redis::SharedState.redis
   redis.info

   保持此屏幕开启，然后按照下述步骤触发故障转移 (failover)。

4. 要在主 Redis 上触发故障转移，请通过 SSH 登录到 Redis 服务器并运行：

   # port must match your primary redis port, and the sleep time must be a few seconds bigger than defined one
    redis-cli -h localhost -p 6379 DEBUG sleep 20

   此操作会影响服务，并会导致实例宕机最多 20 秒。如果成功，实例之后应该会恢复。

5. 然后，回到第一步的 Rails 控制台，运行：

   redis.info

   在几秒钟的延迟（故障转移/重新连接时间）后，您应该会看到一个不同的端口。

排查自编译安装中非捆绑 Redis 的问题

如果您在 GitLab 中遇到类似 Redis::CannotConnectError: No sentinels available. 的错误，可能是您的配置文件有问题，也可能与 此上游 issue 有关。

您必须确保 resque.yml 和 sentinel.conf 已正确配置，否则 redis-rb 将无法正常工作。

在 (sentinel.conf) 中定义的 master-group-name (gitlab-redis) 必须用作 GitLab (resque.yml) 中的主机名：

# sentinel.conf:
sentinel monitor gitlab-redis 10.0.0.1 6379 2
sentinel down-after-milliseconds gitlab-redis 10000
sentinel config-epoch gitlab-redis 0
sentinel leader-epoch gitlab-redis 0

# resque.yaml
production:
  url: redis://:myredispassword@gitlab-redis/
  sentinels:
    -
      host: 10.0.0.1
      port: 26379  # point to sentinel, not to redis port
    -
      host: 10.0.0.2
      port: 26379  # point to sentinel, not to redis port
    -
      host: 10.0.0.3
      port: 26379  # point to sentinel, not to redis port

如有疑问，请阅读 Redis Sentinel 官方文档。