Alauda Cache Service for Redis OSS
  • Русский

    • Настройка

    Настройка кластера аварийного восстановления включает две части: включение конфигурации аварийного восстановления для экземпляра Redis и установление соединения между целевым и исходным экземплярами.

    Описание ролей кластера

    В кластере аварийного восстановления роль каждого экземпляра Redis не фиксирована; он может быть как источником, так и целью. Цель не ограничивает запись данных, но данные, записанные в цель, будут перезаписаны данными, синхронизированными с источника, или вызовут сбой синхронизации из-за конфликтов типов данных.

    Содержание

    Исходная сторонаИспользование LoadBalancer в качестве адреса доступа для исходного ProxyЦелевая сторона

    Исходная сторона

    Сначала необходимо создать экземпляр Redis.

    CLI
    Веб-консоль

    Включение аварийного восстановления

    # Включить ActiveRedis
$ kubectl -n default patch redis s6 --type=merge --patch='{"spec": {"activeRedis":{"serviceID":0 }}}'

    Использование LoadBalancer в качестве адреса доступа для исходного Proxy

    После включения поддержки аварийного восстановления для экземпляра, Proxy аварийного восстановления по умолчанию предоставляет адрес доступа NodePort. Один адрес доступа на основе NodePort не является высокодоступным. В производственной среде можно использовать адрес LoadBalancer для доступа к Proxy.

    CLI
    # Включить ActiveRedis с LoadBalancer в качестве типа доступа Proxy
$ kubectl -n default patch redis s6 --type=merge --patch='{"spec": {"activeRedis":{"proxy": {"service": {"type": "LoadBalancer"}}}}}'

    Каждый экземпляр аварийного восстановления создаст Proxy Service с именем в формате: activeredis-proxy-<instance-name>.

    Для Sentinel экземпляров имя экземпляра должно иметь префикс rfr-

    Целевая сторона

    CLI
    Веб-консоль

    Включение аварийного восстановления

    # Включить ActiveRedis
$ kubectl -n default patch redis s6-dest --type=merge --patch='{"spec": {"activeRedis":{"serviceID":0 }}}'
    WARNING

    Диапазон serviceID — [0-15]. В одном кластере аварийного восстановления serviceID не должен повторяться.

    Создание секрета с паролем пользователя default исходного экземпляра

    $ kubectl -n default create secret generic s6-src-auth-cred --from-literal=password=abc@123

    Настройка соединения аварийного восстановления

    # создать activeredisconnections
$ cat << EOF | kubectl -n default create -f -
apiVersion: redis.middleware.alauda.io/v1alpha1
kind: ActiveRedisConnection
metadata:
name: conn-s6-dest-to-s6-src
spec:
addresses:
- 192.168.1.10:30010
instance: s6-dest
secretName: s6-src-auth-cred
EOF

    Не забудьте заменить адрес источника и секрет.

    Проверка статуса соединения аварийного восстановления

    $ kubectl -n default get activeredisconnections conn-s6-dest-to-s6-src -o yaml
apiVersion: redis.middleware.alauda.io/v1alpha1
kind: ActiveRedisConnection
metadata:
annotations:
  cpaas.io/creator: admin
  cpaas.io/updated-at: "2025-08-26T10:16:49Z"
creationTimestamp: "2025-08-26T10:16:49Z"
generation: 1
labels:
  cpaas.io/activeredis: s6-dest-activeredis
  cpaas.io/activeredis-instance: s6-dest
name: conn-s6-dest-to-s6-src
namespace: default
resourceVersion: "18872971"
uid: 283ac8fa-d693-46ff-989f-68d018888584
spec:
addresses:
- 192.168.1.10:30010
instance: s6-dest
pause: false
secretName: s6-src-auth-cred
status:
instance: s6-dest
shards:
- index: 0
  offset: "0"
  opId: "0"
  status: Connected
  syncStatus: PartialSync
status: Healthy
upstreamPeer:
  service_id: 0
  service_metadata:
    instance: default/s6-src

    Здесь status.shards[0].status указывает статус соединения шарда, а status.shards[0].syncStatus — статус синхронизации данных. Статус синхронизации может быть PartialSync (инкрементальная синхронизация Oplog) или FullSync (синхронизация RDB).

    В нативном режиме Redis Sentinel отсутствует понятие шардов. Здесь мастер-слейв Sentinel абстрагируется как shard 0 для совместимости с той же структурой данных, что и в режиме кластера Redis.