репликация master-slave

Серия Redis

Принцип кэширования и дизайн серии Redis

Быстрый старт серии Redis

Структура данных серии Redis

Механизм сохранения Redis серии Redis

Репликация Master-Slave серии Redis

Режим Sentinel серии Redis

основное введение

Redis поддерживает функцию репликации master-slave.Вы можете включить функцию репликации, выполнив slaveof (replicaof после версии Redis5) или установив slaveof в файле конфигурации (replicaof после версии Redis5).

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

Один хозяин, много рабов

Базовая конфигурация ведущий-ведомый

Основная конфигурация Redis

Основная конфигурация Redis в основном не нуждается в изменении, ключевой частью является конфигурация из Redis.

Настроить из Redis

1. Скопируйте файл redis.conf

2. Связанная модификация конфигурации

# salve的端口号
port 6380 

#把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid 

logfile "6380.log"  

#指定数据存放目录
dir /usr/local/redis‐5.0.3/data/6380 

#需要注释掉bind
#bind127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

3. Настройте репликацию master-slave

#从本机master6379的redis实例复制数据，Redis5.0之前使用slaveof
replicaof 192.168.0.60 6379

#配置从节点只读
replica‐read‐only yes

4. Запустите подчиненный узел

redis‐server redis.conf

5. Подключитесь к ведомому узлу

redis‐cli ‐p 6380

6. Проверьте, может ли экземпляр 6380 своевременно синхронизировать недавно измененные данные при записи данных в экземпляр 6379.

docker run  --name redis-6381 -v /Users/yujiale/docker/redis/conf/redis6381.conf:/etc/redis/redis.conf -v /Users/yujiale/docker/redis/conf/sentinel6381.conf:/etc/redis/sentine.conf -v /Users/yujiale/docker/redis/data6381:/data --network localNetwork --ip 172.172.0.14 -p 16381:6379 -d redis:6.2.6 redis-server /etc/redis/redis.conf --appendonly yes

Роль конфигурации master-slave

разделение чтения-записи

Один ведущий и несколько ведомых, синхронизация ведущий-ведомый
Мастер отвечает за запись, а слейв отвечает за чтение.
Улучшить производительность и пропускную способность Redis
Проблема согласованности данных ведущий-ведомый

аварийное восстановление данных

Ведомый является резервной копией мастера
Мастер не работает, ведомый доступен для чтения, но не для записи
По умолчанию, после того, как хост не работает, ведомое устройство не может быть использовано хостом.
Sentinel может реализовать переключение ведущий-ведомый и добиться высокой доступности

Как работает Redis master-slave

Полная репликация master-slave репликация

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

блок-схема

1. Установите длинное соединение Socker с основным Redis

Работорговец устанавливает сокетное соединение с мастером

обработчик событий файла, связанный с ведомым устройством

Процессор получает файлы RDB (полная репликация) и получает команды записи, распространяемые мастером (инкрементная репликация).

После того, как главный сервер принимает сокет-соединение подчиненного сервера, он создает соответствующее состояние клиента. Это эквивалентно подчиненному серверу, являющемуся клиентской частью главного сервера.

отправить команду пинга
- Работорговец отправляет команду ping мастеру
  - 1. Обнаружение статуса чтения и записи сокета
  - 2. Проверьте, может ли Мастер нормально обрабатывать
- Ответ Мастера:
  - 1. Отправьте «понг», чтобы указать нормальный
  - 2. Возвращается ошибка, указывающая на ненормальность Мастера.
  - 3, тайм-аут, указывающий тайм-аут сети

АСД

После нормального подключения ведущего и ведомого выполните проверку разрешений.

Мастер не устанавливает пароль (requirepass="") и никогда не должен устанавливать пароль (masterauth="")

Мастер устанавливает пароль (requirepass!=""), а ведомый должен установить пароль (masterauth=значение requirepass мастера)

или отправив пароль мастеру с помощью команды auth

2. Основной Redis получает команду PSYNC

После того, как основной Redis получит команду PSYNC, выполнение команды bgsave создаст последний снимок rdb.

3. Главный Redis отправляет снимок rdb подчиненному Redis.

Когда главный Redis отправляет моментальные снимки rdb подчиненному Redis, главный будет продолжать получать запросы от клиентов и кэшировать эти запросы, которые могут изменить набор данных в памяти, и сохранять их в буферном кеше relp.

Фаза синхронного моментального снимка: ведущий создает и отправляет RDB моментального снимка подчиненному устройству, а подчиненное устройство загружает и анализирует моментальный снимок. В то же время мастер сохраняет новую команду записи, сгенерированную на этом этапе, в буфер.

4. От узла получен снимок rdb

После получения снапшота rdb с ноды очистите старые данные и загрузите файл rdb

5. Главный Redis отправляет файл кэша буфера подчиненному Redis.

Фаза буфера синхронной записи: Ведущее устройство синхронизирует команды операции записи, хранящиеся в буфере, с Ведомым устройством.

6. Получение файлов буферного кеша от узлов

Получите файл буферного кеша от узла и загрузите файл буферного кеша в память

7. Мастер Redis постоянно отправляет команды подчиненным узлам через длинное соединение Socker.

Получите команду, отправленную основным Redis от Redis, и выполните текущую команду

Обзор

Если вы настраиваете ведомое устройство для ведущего, независимо от того, подключается ли ведомое устройство к ведущему в первый раз, оно отправит мастеру команду PSYNC для запроса репликации данных. После того, как мастер получит команду PSYNC, он сохранит данные в фоновом режиме и сгенерирует последний файл моментального снимка rdb через bgsave.В течение периода сохранения мастер будет продолжать получать запросы от клиента и кэшировать эти запросы, которые могут изменить набор данных в памяти. Когда сохранение завершено, мастер отправит набор данных файла rdb подчиненному устройству, а подчиненное устройство сохранит полученные данные для создания rdb, а затем загрузит их в память. Затем мастер отправляет подчиненному команду, ранее кэшированную в памяти. Когда соединение между ведущим и ведомым по какой-либо причине отключено, ведомое устройство может автоматически повторно подключить ведущее устройство.Если ведущее устройство получает несколько запросов на одновременные соединения ведомого устройства, оно будет сохраняться только один раз, а не одно соединение один раз, а затем отправить это постоянные данные нескольким одновременно подключенным ведомым устройствам.

Частичная репликация master-slave репликации

Общий процесс аналогичен полной копии, поэтому я не буду слишком много объяснять.

Кратко

Когда ведущий и ведомый отключаются и снова подключаются, все данные обычно реплицируются. Однако, начиная с redis 2.8, redis использует команду PSYNC, которая может поддерживать частичную репликацию данных, для синхронизации данных с ведущим устройством.Подчиненное устройство и главное устройство могут выполнять частичную репликацию данных только после отключения и повторного подключения сетевого соединения (возобновление с точки останова). ). Мастер создаст кеш-очередь для копирования данных в свою память, чтобы кэшировать данные за самый последний период времени.Мастер и все его ведомые устройства поддерживают смещение нижнего индекса скопированных данных и идентификатор процесса ведущего.Поэтому, когда сетевое подключение disabled После этого ведомый запросит у ведущего продолжить незавершенную репликацию, начиная с записанного индекса данных. Если идентификатор главного процесса изменится или смещение нижнего индекса данных подчиненного узла станет слишком старым и больше не находится в очереди кэша главного, будет выполнена полная репликация данных. Блок-схема репликации ведущий-ведомый (частичная репликация, возобновление точки останова):

Инкрементная синхронизация репликации master-slave

Инкрементная синхронизация Redis в основном относится к процессу синхронизации операции записи главного устройства с подчиненным, когда подчиненное устройство начинает нормально работать после завершения инициализации.
Обычно каждый раз, когда мастер выполняет команду записи, он отправляет эту же команду записи подчиненному устройству, а затем подчиненное устройство получает и выполняет ее.

Обнаружение пульса репликации master-slave

1. Определите статус подключения ведущего и ведомого

Определение состояния сетевого подключения главного и подчиненных серверов. Отправив команду репликации INFO на главный сервер, можно просмотреть список подчиненных серверов и увидеть, сколько секунд прошло с момента отправки последней команды главному. Значение запаздывания должно колебаться между 0 и 1. Если оно превышает 1, соединение между ведущим и ведомым неисправно.

2. Оказать помощь в реализации мин-рабов

Redis можно настроить таким образом, чтобы мастер не выполнял команды записи в небезопасных условиях ) Вышеупомянутая конфигурация означает: когда количество подчиненных серверов меньше 3 или значение задержки (лага) трех подчиненных серверов больше или равно 10 секундам, главный сервер откажется выполнять команду записи. Значение задержки здесь является значением задержки вышеприведенной команды INFOreplication.

3. Обнаружение потери команды

Если команда записи, переданная главным сервером подчиненному серверу, будет потеряна на полпути из-за сбоя сети, то когда подчиненный сервер отправит команду REPLCONF ACK на главный сервер, главный сервер обнаружит, что текущее смещение репликации подчиненного сервера меньше, чем его собственное смещение репликации. Затем главный сервер найдет недостающие данные с подчиненного сервера в буфере невыполненной репликации в соответствии со смещением репликации, предоставленным подчиненным сервером, и повторно отправит данные подчиненному серверу. (Переиздание) Сеть постоянно синхронизируется по нарастающей: сеть отключается, при подключении снова

Как узнать, полная или частичная репликация

После того, как клиент отправит saveof, мастер-узел определит, является ли это первой репликацией. Если это так, он выполнит полную репликацию. Если это не определено смещением смещения runid, он выполнит частичную репликацию. В противном случае будет выполнена полная репликация. выполнено.