Redis 故障排查 | 极狐GitLab

基本 Redis 活动检查
Redis 复制故障排除
Redis 实例上的高 CPU 使用率
Sentinel 故障排除
使用自编译安装故障排除未捆绑的 Redis

Tier: 基础版, 专业版, 旗舰版
Offering: 私有化部署

为了让高可用性设置按预期工作，需要仔细处理许多活动部分。

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

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

基本 Redis 活动检查

从基本的 Redis 活动检查开始进行 Redis 故障排除：

在您的极狐GitLab 服务器上打开终端。
运行 gitlab-redis-cli --stat，并在运行时观察输出。
转到您的极狐GitLab UI 并浏览一些页面。任何页面都可以，例如群组或项目概览、议题或存储库中的文件。
再次检查 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 时，您会看到连接的 replicas 数量，以及每个连接的详细信息列表：

# 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 使用率，您可以：

使用路由规则来减少 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. 的错误，可能是您的配置文件有问题。

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

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

为了确保您的配置正确：

SSH 进入您的极狐GitLab 应用程序服务器

进入 Rails 控制台：

# 对于 Omnibus 安装
sudo gitlab-rails console

# 对于源代码安装
sudo -u git rails console -e production

在控制台中运行：
```
redis = Gitlab::Redis::SharedState.redis
redis.info
```
保持此屏幕打开，并继续触发故障转移，如下所述。
要在主 Redis 上触发故障转移，请 SSH 进入 Redis 服务器并运行：
```
# 端口必须与您的主 redis 端口匹配，睡眠时间必须比定义的时间长几秒钟
 redis-cli -h localhost -p 6379 DEBUG sleep 20
```
{{< alert type=”warning” >}}

此操作会影响服务，并将实例关闭最多 20 秒。如果成功，它应该在此之后恢复。

{{< /alert >}}
然后回到第一步中的 Rails 控制台，运行：
```
redis.info
```
您应该在几秒钟的延迟后看到不同的端口（故障转移/重新连接时间）。

使用自编译安装故障排除未捆绑的 Redis

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

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

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

# 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  # 指向 sentinel，而不是 redis 端口
    -
      host: 10.0.0.2
      port: 26379  # 指向 sentinel，而不是 redis 端口
    -
      host: 10.0.0.3
      port: 26379  # 指向 sentinel，而不是 redis 端口