Redisのトラブルシューティング

HAセットアップが期待通りに動作するためには、注意しなければならない可動部分がたくさんあります。

以下のトラブルシューティングを進める前に、ファイアウォールのルールを確認してください：

  • Redisマシン
    • でTCP接続を受け付けます。6379
    • でTCP経由で他のRedisマシンに接続。6379
  • センチネルマシン
    • でTCP接続を受け付けます。26379
    • でTCP経由で他のSentinelマシンに接続。26379
    • でTCP経由でRedisマシンに接続。6379

基本的なRedisのアクティビティチェック

基本的なRedisのアクティビティチェックからRedisのトラブルシューティングを開始します：

  1. GitLab サーバーでターミナルを開きます。
  2. gitlab-redis-cli --stat を実行し、実行中の出力を観察してください。
  3. GitLab UI にアクセスし、いくつかのページをブラウズします。グループやプロジェクトの概要、イシュー、リポジトリ内のファイルなど、どのページでもかまいません。
  4. stat の出力をもう一度確認し、keys 、clients 、requests、connections の値がブラウズするにつれて増えていることを確認します。数値が上がっていれば、基本的なRedisの機能は動作しており、GitLabはRedisに接続することができます。

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

Sentinelのトラブルシューティング

このようなエラーが表示された場合：Redis::CannotConnectError: No sentinels available.設定ファイルに何か問題があるか、このイシューに関連している可能性があります。

redis['master_name'] 、redis['master_password'] 、センチネルノードに定義した値と同じ値を定義していることを確認してください。

Redis connectorredis-rb が sentinel で動作する方法は、少し直感的ではありません。Linuxパッケージでは複雑さを隠そうとしていますが、それでもいくつかの余分な設定が必要です。

設定が正しいことを確認するために

  1. GitLabアプリケーションサーバーにSSH接続してください。

  2. Railsコンソールに入ります：

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

  3. コンソールで実行します：

    redis = Redis.new(Gitlab::Redis::SharedState.params)
redis.info

    この画面を開いたまま、以下の手順に従ってフェイルオーバーのトリガーを実行します。

  4. プライマリのRedisでフェイルオーバーをトリガーするには、RedisサーバーにSSH接続して実行します：

    # 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
    caution
    このアクションはサービスに影響し、インスタンスを最大20秒間ダウンさせます。成功すればその後回復します。

  5. 次に、最初のステップのRailsコンソールに戻って実行します：

    redis.info

    数秒の遅延（フェイルオーバー/再接続時間）の後、別のポートが表示されるはずです。

セルフコンパイルでインストールしたバンドルされていないRedisのトラブルシューティング

GitLabでRedis::CannotConnectError: No sentinels available. のようなエラーが表示される場合は、設定ファイルに何か問題があるか、このアップストリームの問題に関連している可能性があります。

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のドキュメントを読んでください。