Установка и настройка кластера redis в linux

Проверка работы

Мы подключимся к нашему локальному серверу командой redis-cli.

а) при установке на систему:

redis-cli

б) если запустили контейнер:

docker exec -it redis-server redis-cli

* где redis-server — имя контейнера, которое мы задали во время его запуска.

Мы должны увидеть строку ввода команд Redis:

127.0.0.1:6379>

Для проверки подключения к серверу выполним команду:

> ping

В ответ мы должны увидеть:

PONG

Попробуем создать пару ключ — значение. Для этого вводим:

> set test_key «A test value»

Теперь попробуем его получить:

> get test_key

Мы должны получить наше значение:

«A test value»

Также можно получить список всех ключей командой:

> KEYS *

Сервер работает. Выходим из редис-консоли:

> quit

Полный список команд для работы в redis-cli можно найти на официальном сайте.

Установка на DEB дистрибутивы (Ubuntu/Debian)

Сначала выполним обновление пакетов:

# apt update

# apt upgrade

После чего непосредственно выполнив установку Redis сервера:

# apt install redis-server

После завершения установки проверим работу установленного сервиса:

$ redis-cli ping

В случае успешной установки в ответ придет текст — PONG, если сервис не установился или не запустился, на экран будет выведена ошибка, о невозможности подключится к сервису или отсутствии команды redis-cli.

Если Redis сервер установлен и запустился, то он будет ожидать подключение на локальном интерфейсе 127.0.0.1 (localhost), порт стандартный — 6379.

3: Настройка master-сервера Redis

Теперь все готово к настройке ведущего сервера Redis.

Откройте /etc/redis/redis.conf в текстовом редакторе:

Найдите параметр tcp-keepalive и установите значение 60. Так Redis сможет определять сбои сети или сервиса.

Затем найдите директиву requirepass. Выберите сложный пароль и введите его в эту строку. Ранее вы защитили трафик Redis от постороннего вмешательства, а теперь, с помощью директивы requirepass, вы настроили аутентификацию Redis. Redis не ограничивает количество попыток ввода пароля, потому пароль должен быть очень сложным – иначе его могут подобрать с помощью brute force атаки.

Теперь нужно установить несколько опциональных параметров. Эти настройки зависят от целей сервера.

Если вы не хотите, чтобы Redis автоматически сбрасывал старые и менее используемые ключи по мере заполнения, отключите автоматический сброс ключей:

Также вы можете настроить длительное хранение данных. Это позволяет минимизировать потерю данных в случае сбоя системы, но может замедлить производительность.

Сохраните и закройте файл.

Перезапустите сервис Redis.

Теперь master-сервер нужно протестировать.

4. Redis-master-slave репликация + часовой

y http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>le=»margin-bottom:5px;»>Теги:  Redis кластер  Redis Master-Slave репликация

4.1 Мастер-раб репликация

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

4.2 Мастер-подчиненный процесс репликации

1. Подчиненный устанавливает соединение с ведущим и отправляет команду синхронизации.
2. Мастер запустит фоновый процесс, чтобы сохранить снимок базы данных в файл, а коллега начнет собирать новые команды записи и кэшировать их.
3. Закончив сохранение в фоновом режиме, отправьте файл на ведомый
4. раб сохраняет этот файл локально

4.3 Конфигурация репликации главный-подчиненный

Схема репликации мастер-подчиненный

роль	ip	порт
master	192.168.136.175	6379
slave	192.168.136.176	6379
slave	192.168.136.178	6379

Установите Redis

2. Настройте файл redis.conf. Не изменяйте конфигурацию главного устройства, только подчиненного. раб 192.168.136.175 6379

3. Перезапустите три сервера, введите redis-cli на главном компьютере, введите команду info и просмотрите следующую информацию, которая подтверждает успешность конфигурации.

4.4 Страж

При реализации репликации «ведущий-ведомый», если мы хотим контролировать сервер «ведущий-ведомый», то после redis2.6 предоставляется механизм дозорного. После 2.8 часовая функция стабилизировалась.

Смысл стража состоит в том, чтобы контролировать работу redis, его основные функции двояки:

1. Контролируйте базы данных master и slave для нормальной работы.
2. При сбое главной базы данных подчиненная база данных может быть автоматически перенесена в основную базу данных для автоматического переключения.

4.4.1 Этапы внедрения Sentinel:

Запустите sentinel.conf с любого подчиненного сервера (он должен быть запущен на четвертой машине)

1. Скопируйте файл sentinel.conf в / opt / redis / и т. Д. Файл sentinel.conf находится в пакете исходного кода redis

2. Измените файл sentinel.conf

sentinel monitor mymaster 192.168.136.175 6379 1 

sentinel down-after-milliseconds mymaster 10000

sentinel parallel-syncs mymaster 2

sentinel failover-timeout mymaster 30000

3. Запустите три сервера Redis

4. Запустите Sentinel./redis-server /opt/redis/etc/sentinel.conf —sentinel &

Конфигурация завершена! ! !

Просматривать информацию о дозорном мониторинге вы можете на любой машине. ./redis-cli -h 192.168.136.176 -p 26379 info Страж

Завершите работу сервера главного узла (192.168.136.175), и приглашения автоматически будут напечатаны на сервере, настроенном с помощью стража.

Снова включите 175, но узел не переключит главный узел обратно на 175.

Закрыть 176, главный узел переключается обратно на 175

Интеллектуальная рекомендация

19.03.21 Я загрузил комплексные обучающие видеоуроки Photoshop CC 2015 и обучающие видеоуроки по новым функциям PS CC 2015. Я просмотрел несколько видео, но мне кажется, что они в основном объясняют н…

…

проверка данных весеннего mvc Два способа проверки данных Spring MVC: 1.JSR303 2.Hibernate Validator Второй метод является дополнением к первому методу Шаги для проверки данных с использованием Hibern…

Существует два способа вызова между сервисами Springcloud: RestTemplate и Feign. Здесь мы представляем сервисы вызова RestTemplate. 1. Что такое RestTemplate RestTemplate — это структура веб-запросов …

1. Понимать предварительный, средний, последующий порядок и иерархическую последовательность бинарных деревьев; Свяжите язык C со структурой данных двоичного дерева; Освойте с…

Вам также может понравиться

Последнее обучение, как использовать Kaldi, чтобы проснуться без использования WSTF, поэтому вам нужно глубоко пойти в Kaldi для обучения. Временное состояние обучения. Три изображения представляют со…

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

Расширенные статьи серии Zookeeper 1. NIO, ZAB соглашение, 2PC представления концепции 2. Лидер выборов 3. Рукописный распределенный замок, центр настройки ==================================== 1. NIO,…

Посмотрите на конечный эффект первым DemoPreview.gif SETP1 эффект капли воды Первая реакция на эффект капли воды — нарисовать замкнутую кривую. С помощью события MotionEvent измените радиус во время п…

…

Кластер Redis (фокус)

1. Схема архитектуры кластера

Детали архитектуры:

(1) Все узлы Redis взаимосвязаны друг с другом(Механизм PING-PONG), Внутреннее использование двоичного протокола для оптимизации скорости передачи и пропускной способности

(2) Ошибка узла происходит через кластер.Более половины узловЭффективен, когда обнаружение не удается

(3) Клиент напрямую подключен к узлу Redis и не требует промежуточного уровня прокси. Клиенту не нужно подключаться ко всем узлам в кластере, просто подключитесь к любому доступному узлу в кластере.

(4) Redis-cluster отображает все физические узлы в слот , и кластер отвечает за поддержание значения node <-> slot <->

(5) В кластере Redis встроено 16384 хэш-слота. Когда ключ-значение необходимо поместить в кластер Redis, redis сначала использует алгоритм crc16 для вычисления результата по ключу, а затем вычисляет остаток результата до 16384, чтобы каждый ключ Будет соответствовать хэш-слоту с номерами от 0 до 16383, redis отобразит хэш-слот на разные узлы, примерно равные количеству узлов.

2. Кластерное голосование: отказоустойчивость

(1) Все мастера в кластере участвуют в голосовании. Если более половины главных узлов связываются с одним из главных узлов более (время ожидания кластера-узла), главный узел считается неработающим.

(2) Когда весь кластер недоступен (cluster_state: fail)?

• Если какой-либо мастер кластера вешает трубку, а у текущего мастера нет подчиненного, кластер переходит в состояние отказа. Это также можно понимать как переход в состояние сбоя, когда отображение слота кластера не завершено.
• Если более половины мастеров в кластере зависают, независимо от того, есть ли подчиненное устройство, кластер переходит в состояние отказа.

3. Установите рубин

Инструмент управления кластером (redis-trib.rb) написан на языке сценариев ruby.

Та же операция с другими машинами

(1) Установить рубин

(2) Загрузите следующие файлы в систему Linux. (3) Установите интерфейс ruby ​​и redis.

Разрешение ошибки:

(4) Скопируйте файл redis-trib.rb в каталог src пакета redis-3.0.0 в apps /

4. Создайте кластер.

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

(1) Скопируйте машину, удалите, если есть постоянные файлы

(2) Установите параметры кластера

(3) Измените порт

(4) Запустите машину

(5) Создайте кластер

(1) Просмотр информации о кластере

(2) Просмотр узлов кластера

Redis мастер-подчиненная конфигурация

1.5: установить ведущий и ведомый

Измените файл redis.conf, здесь порт 6379 установлен на master, поэтому не нужно ничего делать, просто измените порт 6380 и порт 6381. slaveof 192.168.1.103 6379 Если мастер-редис установил пароль, обязательно добавь свой пароль мастераута ко всем ред-серверу мастер-слэйв conf.redis.

1.7: Подключитесь к главному узлу Redis и проверьте статус главный-подчиненный

# ./redis-cli -p 6379 -h 192.168.1.103 # Подключиться к службе redis 192.168.1.103:6379> Репликация INFO # Просмотр информации о текущем узле # Replication role:master #master connected_slaves: 2 # число подчиненных узлов slave0: ip = 192.168.1.103, порт = 6380, состояние = онлайн, смещение = 1443, лаг = 1 # информация о подчиненном узле slave1: ip = 192.168.1.103, порт = 6381, состояние = онлайн, смещение = 1443, лаг = 1 # информация о подчиненном узле master_repl_offset:1443 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:1442  

3 кластер (Redis-cluster)

Хотя сигнальный кластер ведущий-ведомый может использоваться для обеспечения доступности, данные каждого узла в этой реализации полностью реплицируются, а объем хранилища данных имеет ограничения и ограничен узлом с наименьшим объемом памяти, поэтому рассмотрите возможность использования сегментирования данных. , Чтобы добиться хранилища, это redis-cluster.

Совет: на основе исходной конфигурации главный-подчиненный, продолжите. Во-первых, подчиненное устройство конфигурации порта хоста в режиме главный-подчиненный будет конфликтовать с конфигурацией кластера.

1.3, Master Redis из конфигурации копирования (Выделить)

1, начать три Centos с Redis

2, определить основные отношения, положите два как

3, отредактируйте его от сервера Redis.conf (собственный профиль запуска) с Vim

Команда vim /usr/local/redis/etc/redis.conf.

3.1 SLAVEOF 192.168.0.100 6379 Формат является Host IP-хостом Plaveof

3.2 # Bind127.0.0.1 Привязка выхода из системы, разрешите все IP-соединения для входа в эту службу Redis

3.3 Режим защиты от защиты нет

Примечание. Также необходимо открыть 6379 порт. Брандмауэр, используемый CentOS7, это брандмауэр, даже если брандмауэр выключен.

1, Systemctl Status Firewalld Просмотр статуса брандмауэра

2, Systemctl запускает брандwalld запускает брандмауэр

3, Firewall-CMD —zone = Public —add-port = 6379 / tcp —permanent навсегда открыть 6379 порт

4, брандмауэр-CMD —reload обновить правила брандмауэра брандмауэра

5, Systemctl Restart Firewalld.Service Перезапустите брандмауэр

6, Firewall-Cmd — Query-Port = 6379 / TCP-запрос открыт 6379 порт

7, Systemctl Stop Firewalld выключает брандмауэр

4, проверьте, может ли подчиненный доступ к порту Host 6379

Команда Telnet 192.168.0.104 6379 Тестовый порт

Используйте Ctrl +] Выходное соединение Telnet Counding Exit

Установка, начальная настройка и запуск

Рассмотрим два варианта установки — чистая инсталляция на систему Linux Ubuntu и запуск контейнера из официального докер-образа.

Операционная система Ubuntu

Обновляем список пакетов:

apt-get update

Выполняем установку:

apt-get install redis-server

Открываем конфигурационный файл:

vi /etc/redis/redis.conf

Меняем значение для директивы supervised:

supervised systemd

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

Разрешаем автозапуск сервиса:

systemctl enable redis-server

Перезапускаем redis-server:

systemctl restart redis-server

Наш сервер готов к работе.

Посмотреть версию установленной СУБД можно командой:

redis-server —version

Мы должны увидеть что-то на подобие:

Redis server v=5.0.7 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64 build=636cde3b5c7a3923

* в данном примере установлена версия 5. На момент обновления данной инструкции последней версией была 6.

Docker

Необходимо, чтобы в нашей системе был .

После выполняем загрузку образа Redis:

docker pull redis

Запускаем контейнер:

docker run —name redis-server -d redis

Проверим, что наш контейнер запустился:

docker ps

Мы должны увидеть что-то на подобие:

CONTAINER ID   IMAGE   COMMAND    CREATED    STATUS   PORTS      NAMES
a8c30431268c   redis   «docke…»   4 sec…   Up 3…  6379/tcp   redis-server

* наш сервис запущен на порту 6379; к нему можно обращаться по имени redis-server или ID a8c30431268c.

1.6, Redis Master от репликации

1, мастер может иметь несколько раб

2. В дополнение к нескольким рабам к тому же мастеру, раб также может быть подключен к другим графическим структурам подчиненного формирования.

3, Master-Slave Copy не блокирует мастер, то есть, когда один или несколько раб скопирован путем копирования, мастер может продолжать обрабатывать запрос от клиента.

4, Master-Slave Copy может использоваться для повышения масштабируемости системы, мы можем использовать несколько раб, чтобы нести ответственность за запрос на чтение клиента, вы можете сделать резервирование данных

2.1, redis sentinel механизм

После внедрения Master-Place Copy, если мы хотим отслеживать MASTER с сервера, затем предоставьте механизм «Sentry» после REDIS2.6. Sentinels в версии 2.6 — 1.0 версий, которые нестабильны, будут различные проблемы, а функция Sentinel после версии 2.8 стабильна.

Как предполагает имя, значение Sentinel — это мониторинг системы Redis. Вы можете начать несколько SentiNels для мониторинга текущего состояния базы данных Redis. Его основные функции имеют две точки:

1. Следите за основной базой данных и запустите из базы данных.

2. Когда первичная база данных выходит из строя, он может автоматически переключаться из базы данных в основную базу данных, а автоматическое переключение реализовано.

Модель Sentinel Message

2.2, Реализация шаги для сентинельского механизма

Рабочая конфигурация Sentry (также может быть настроена на первичном сервере)

Примечание: из-за оригиналаslave1、Slave2 будет автоматически избран в качестве основного сервера, чтобы вы хотите настроить (# Bind127.0.0.1. Protected-Mode NO в его файле конфигурации) лучше всего использовать тест порта Telnet + IP +.

1. Копировать файл /us/local/redis/redis-4.0.8/tentinel.conf (файл sentinel.conf) к / usr / local / redis / etc path cr / usr / local / redis / redis-4.0.8 / Sentinel.conf / usr / local / redis / etc /

2. Изменить файл sentinel.conf vim / usr / local / redis / etc / ussminel.conf

1) Dir «/ usr / local / redis / etc» каталог хранения данных

2) Защищенный режим без режима защиты оборота

3) Sentinel Monitor MyMaster192.168.43.201 6379 1 Формат — это количество голосов имени мастера, IP, адреса, номера порта и сбоя.

4) Sentineldown-Asge-Milliseconds MyMaster5000 Timeout 5000 Milliseconds — простоя

5) SentiNelpallel-Syncsmymaster 2 от количества серверов

3, запуск Sentinel Sentinel Command / usr / local / redis / bin / redis-server /usr/local/redis/etc/sentinel.conf —sentinel &

4, проверьте информацию о Sentinel / usr / local / redis / bin / redis-cli -h 192.168.43.64-PR 26379 Info Sentinel

5. Выключите основной сервер, проверьте информацию о кластере / USR / LOCAL / REDIS / BIN / REDIS-CLI.

Можно видеть, что после основного сервера 192.168.43.201 простоя, 192.168.43.64 — новый основной сервер

6, проверьте информацию о оставшихся сервере Redis

192.168.43.64.

Видно, что 192.168.43.64 автоматически изменился на основной сервер.

192.168.43.106.

Видно, что его основное обслуживание стало 192.168.43.64

7, начните первичный сервер снова и просмотрите информацию

Видно, что он стал с сервера, и его основной сервер 192.168.43.64

7: Изменение ролей серверов slave и master

Главной задачей репликации данных является быстрая обработка ошибок с минимальной потерей данных и временем простоя. Потому в случае падения master-сервера Redis его место должен занять slave-сервер.

Повышение slave вручную

Повысить статус slave-сервера можно вручную. Введите команду:

Введите пароль slave-сервера, чтобы пройти аутентификацию:

Создайте новый тестовый ключ, чтобы в дальнейшем проверить настройку:

Эта команда вернёт ошибку, так как по умолчанию ведомые серверы Redis существуют в режиме только для чтения (опция slave-read-only yes).

Чтобы отключить репликацию и повысить сервер до master, нужно изменить значение slaveof на no one:

Снова запросите сведения о репликации:

Как видите, slave-сервер стал master-сервером Redis.

Имейте в виду: конфигурационный файл сервера по-прежнему определяет его как slave. Если вы перезапустите сервис, не откорректировав конфигурационный файл, Redis восстановит репликацию с учётом прежних настроек

Также обратите внимание, что, возможно, в этом файле потребуется повторно указать настройки master-сервера Redis (например, отключить автоматический сброс устаревших данных)

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

Чтобы вручную восстановить исходный master-сервер, перенаправьте на него новый master (и остальные серверы slave, если такие есть) при помощи slaveof:

Запросите тестовый ключ на ведомом сервере:

Для целостности информации все данные сервера slave ресинхронизируются с новым master.

Автоматическое изменение статуса slave-сервера

Автоматическое повышение slave-сервера Redis требует согласования на уровне приложения. Реализация такой настройки зависит от среды приложения, потому составить общий план действий довольно сложно – настройка во многом индивидуальна для каждого сервера.

Рассмотрим наиболее общие этапы настройки автоматического обхода сбоев.

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

• Определите сбой мастера на уровне приложения.
• Перейдите на slave и запустите slaveof no one. Это остановит репликацию и повысит его статус до master.
• Откорректируйте настройки нового сервера master (они должны совпадать с настройками предыдущего master-сервера). В большинстве случаев это можно сделать заранее.
• Перенаправьте трафик приложения на новый master-сервер.
• Если у вас несколько серверов slave, выполните на каждом из них такую команду:

slaveof new_master_ip new_master_port.

Эта команда остановит репликацию, обновит данные ведомых серверов и запустит репликацию с новым master-сервером.

Redis поставляется с часовым механизмом

Часовой механизм (прослушивание) port:26379 Стражная система Redis используется для управления несколькими серверами Redis. Система выполняет следующие три задачи:

• Мониторинг: сторож будет постоянно проверять, правильно ли работают ваш ведущий и ведомый.
• Уведомление: если есть проблема с отслеживаемым Redis, сторож может отправлять уведомления администратору или другим приложениям через API.
• Автоматическое переключение при сбое: если мастер не работает нормально, страж запускает операцию автоматического переключения при сбое, которая обновит одного из подчиненных отказавшего мастера до нового ведущего и позволит другим подчиненным отказавшего мастера Вместо этого скопируйте новый мастер: когда клиент пытается подключиться к отказавшему мастеру, кластер также возвращает клиенту адрес нового мастера, чтобы кластер мог использовать мастер вместо отказавшего мастера.

Sentinel — это распределенная система. Вы можете запускать несколько часовых процессов в одной архитектуре. Эти процессы используют gossipprotocols для получения информации о том, находится ли мастер в автономном режиме, и используютСоглашение о голосовании(протоколы согласования), чтобы решить, следует ли выполнять автоматическое переключение при сбое и какое ведомое устройство выбрать в качестве нового ведущего. Каждый дозорный периодически отправляет сообщения другим стражам, мастерам и рабам, чтобы подтвердить, жив ли противник. Если оппонент обнаружен в указанное время (настраивается) Если в течение времени ответа нет, другая сторона временно считается повешенной (так называемое «субъективное время простоя» Subjective Down, обозначаемое как down). Если большинство часовых в «дозорной группе» сообщают, что мастер не ответил, система считает, что мастер «полностью мертв» (то есть: объективно вниз, объектив вниз), (Сокращенно для краткости), с помощью определенного алгоритма голосования, выберите один из оставшихся подчиненных узлов, которые необходимо повысить до основного, а затем автоматически измените соответствующую конфигурацию. Хотя sentinel выпускается как отдельный исполняемый файл redis-sentinel, он на самом делеПросто сервер Redis работает в специальном режимеВы можете запустить sentinel при запуске обычного сервера Redis, указав параметр —sentinel. Некоторые идеи дозорного дизайна очень похожи на zookeeper

Моделируемый сценарий простоя Master 128

128 простоев, 130 выбран в качестве основного сервера, 130 могут установить ключевой тест:

вид

продолжайте слушатьКогда все серверы не работают, используйте keepalived, автоматический перезапуск, оповещение по электронной почте

Отношения между двумя

Главный сервер обычно предоставляет услуги записи, а подчиненный сервер предоставляет услуги только для чтения.

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

Если один из подчиненных серверов зависает, это мало влияет на систему, и есть другие подчиненные серверы, которые предоставляют услуги только для чтения. Но если главный сервер зависнет, вся система не сможет получать новые команды записи. Если вы не перезапустите главный сервер вручную в это время, система не сможет предоставлять обычные услуги. Однако, как разработчик, 724 не может защитить сервер, поэтому есть ли способ автоматически перезапустить главный сервер после того, как главный сервер не работает?

Ответ положительный. Служба, развернутая с помощью docker swarm, автоматически перезапустится, если она зависнет.

Так что, если сервис не развернут с помощью docker swarm? После того, как главный сервер зависает, если один из подчиненных серверов становится главным сервером, просто выполните операции записи. На самом деле такой план есть. Это делает часовой Redis.

Сторожевой охранник

Обычно есть два способа запустить Sentry:

• redis-sentinel
• redis-server /path/to/sentinel.conf —sentinel

В этой статье используется второй метод развертывания.

Сначала измените файл конфигурации, обратитесь к полному списку опций.sentinel.conf, Требуются как минимум четыре следующих параметра:

Подготовьте три таких документа:

• sentinelA1.conf
• sentinelA2.conf
• sentinelA3.conf

Затем напишите файл развертывания sentinelA.yml:

Используйте рой, чтобы развернуть часового:

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

На данный момент серверная система Redis состоит из одного главного сервера + трех подчиненных серверов + трех часовых.

Чтобы проверить, может ли аварийное переключение быть успешно выполнено под управлением дозорного после того, как главный сервер не работает, служба главного сервера теперь удалена:

Наблюдая за журналом любой службы дозорного, можно обнаружить, что дозорный наблюдал нижнюю линию главного сервера, выбрал подчиненный сервер, чтобы стать новым главным сервером, и подключил другие подчиненные серверы к новому главному серверу. Наконец, используйте роль для просмотра идентификаторов каждого подчиненного сервера, одного главного и двух подчиненных. Проверьте значение ключа «/», все равно «лучше». Это показывает, что дозорный играет роль автоматического переноса неисправности на один из подчиненных серверов после зависания основного сервера.

Два, установка

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

Или напрямую Baidu Redis 5.0 linux и другие ключевые слова, вы также можете связаться с Baidu.

2.1. Настроить yum

а) Отключите брандмауэр

vi /etc/selinux/config

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

#     enforcing — SELinux security policy is enforced.

#     permissive — SELinux prints warnings instead of enforcing.

#     disabled — No SELinux policy is loaded.

SELINUX=disabled

# SELINUXTYPE= can take one of these two values:

#     targeted — Targeted processes are protected,

#     mls — Multi Level Security protection.

SELINUXTYPE=targeted

setenforce 0

service iptables stop

chkconfig iptables off

б) Три сервера настроены с помощью yum

mount /dev/sr0 /mnt/

cd /etc/yum.repos.d/

mv redhat.repo redhat.repo.bak

mv rhel-source.repo rhel-source.repo.bak

vi /etc/yum.repos.d/rhel-debuginfo.repo

name=Red Hat Enterprise Linux $releasever — $basearch — Debug

baseurl=file:///mnt/

enabled=1 

gpgcheck=0   

yum -y install make gcc*

2.2. Конфигурация параметров

mkdir -p /redis5.0

Загрузите распакованный пакет в /redis5.0

tar -zxvf redis-5.0.0.tar.gz

Параметры, которые необходимо изменить и аннотировать, следующие:

Master:

cd /redis5.0/redis-5.0.0

save 900 1

#save 300 10

#save 60 10000

bind 172.6.10.80 

daemonize yes

loglevel warning

timeout 60

logfile «6379.log»

dbfilename dump6379.rdb

maxmemory-policy volatile-ttl

auto-aof-rewrite-min-size 10GB

masterauth redis — пароль главной базы данных (этот компьютер не может быть настроен)

Slave1:

cd /redis5.0/redis-5.0.0

save 900 1

#save 300 10

#save 60 10000

bind 172.6.10.81

daemonize yes

loglevel warning

logfile «6380.log»

dbfilename dump6380.rdb

pidfile /var/run/redis_6380.pid

port 6380

timeout 60

maxmemory-policy volatile-ttl

auto-aof-rewrite-min-size 10GB

slaveof 172.16.10.80 6379

masterauth redis — пароль основной библиотеки

Salve2:

cd /redis5.0/redis-5.0.0

save 900 1

#save 300 10

#save 60 10000

bind 172.6.10.82

daemonize yes

loglevel warning

port 6381

timeout 60

dbfilename dump6381.rdb

logfile «6381.log»

pidfile /var/run/redis_6381.pid

maxmemory-policy volatile-ttl

auto-aof-rewrite-min-size 10GB

slaveof 172.16.10.80 6379

masterauth redis — пароль основной библиотеки

2.3. Установка

cd /redis5.0/redis-5.0.0

make

make install

Установка завершена.

Начните следующим образом:

redis-server /redis5.0/redis-5.0.0/redis6379.conf

redis-server /redis5.0/redis-5.0.0/redis6380.conf

redis-server /redis5.0/redis-5.0.0/redis6381.conf

Поскольку параметры были изменены, измените пароль позже:

config set requirepass «redis»

И напишите файл конфигурации:

Например, для закрытия запроса требуется пароль, чтобы указать, что изменение выполнено успешно.

Аналогичным образом измените следующие два сервера:

Конфигурация пароля для репликации master-slave:

Просмотр информации о роли хоста:

Посмотреть конфигурацию ведомого:

Просмотрите конфигурацию второго ведомого устройства:

Видно, что статус синхронизации нормальный.

2: Управление клиентами

Клиент – это любая машина или программное обеспечение, которое подключается к серверу для доступа к сервису. Redis поставляется с несколькими командами, которые помогают отслеживать и управлять клиентскими подключениями.

Команда client list возвращает набор удобочитаемой информации о текущих клиентских подключениях:

Вот что значат эти поля:

• id: уникальный 64-битный ID клиента.
• name: имя клиентского соединения, которое определяется командой client setname.
• addr: адрес и порт, по которому подключается клиент.
• fd: файловый дескриптор, что отвечает за сокет, по которому подключается клиент.
• age: общая продолжительность клиентского соединения (в секундах).
• flags: набор из одного или нескольких односимвольных флагов, которые предоставляют более детальную информацию о клиентах (см. документацию команды client list).
• db: текущий идентификационный номер базы данных, к которому подключен клиент (от 0 до 15).
• sub: количество каналов, на которые подписан клиент.
• psub: количество клиентских подписок, соответствующих шаблону.
• mutli: количество команд, которые клиент поставил в очередь в транзакции (покажет -1, если клиент не начал транзакцию, или 0, если он только начал транзакцию и не поставил в очередь никаких команд).
• qbuf: длина буфера запроса клиента, где 0 означает, что ожидающих запросов нет.
• qbuf-free: количество свободного места в клиентском буфере запросов, где 0 означает, что буфер запросов заполнен.
• obl: длина выходного буфера клиента.
• oll: длина выходного списка клиента (ответы помещаются в очередь, когда буфер заполнен).
• omem: память, используемая выходным буфером клиента.
• events: события файлового дескриптора клиента (где r значит «readable», w значит «writable»).
• cmd: последняя команда, запущенная клиентом.

Установка имен клиентов полезна для отладки утечек соединения в любом приложении, использующем Redis. Каждое новое соединение изначально не имеет имени, но команда client setname может присвоить имя текущему соединению клиента. На длину имен клиентов нет никаких ограничений, хотя Redis обычно ограничивает длину строки до 512 МБ

Обратите внимание, имена клиентов не могут содержать пробелы:

Чтобы узнать имя клиентского соединения, используйте команду client getname:

Чтобы узнать идентификатор подключения клиента, используйте команду client id:

Идентификаторы клиентов Redis никогда не повторяются и являются инкрементными. То есть, если идентификатор первого клиента больше, чем второго, то первый был установлен позднее.