Оригинальный автор, публичный аккаунт [программист чтение], прошу обратить внимание на паблик-аккаунт, просьба указывать источник перепечатываемой статьи.
В предыдущей статье мы узналиRedisДва разных метода персистентности,RedisСервер использует постоянство дляRedisСохраняется в памяти на жесткий диск, когдаRedisПри простое перезагружаемсяRedisсервер, можноRDBфайл илиAOFФайл восстанавливает данные в памяти.
Однако постоянные данные по-прежнему находятся только на одной машине, поэтому при отказе оборудования, например материнской платы илиCPUЕсли он сломан, сервер нельзя перезапустить в это время.Есть ли способ обеспечить безопасность данных при сбое сервера? Или данные можно быстро восстановить? Для этого нам нужно понятьRedisДругой механизм:репликация master-slave.
Что такое master-slave репликация
RedisМеханизм репликации master-slave означает, что подчиненный сервер (slave) является точной копией главного сервера (master) данные, как показано на следующем рисунке:
На картинке выше показанmasterсервер сslaveВ случае с сервером, по сути, одинmasterСервер также может соответствовать несколькимslaveсервер, как показано на следующем рисунке:
Кроме того,slaveСерверы также могут иметь свои собственныеslaveсервер, такой сервер называетсяsub-slave, и этиsub-slaveБлагодаря репликации ведущий-ведомый конечные данные также могут бытьmasterБудьте последовательны, как показано на изображении ниже:
Как и как работает репликация master-slave
RedisРепликация master-slave является асинхронной репликацией, асинхронная делится на два аспекта, один из которыхmasterСервер синхронизирует данные сslaveВремя асинхронно, поэтому главный сервер все еще может получать здесь другие запросы, один из которых заключается в том, что ведомый также асинхронен при получении синхронных данных.
Метод копирования
RedisРепликация master-slave делится на следующие три способа:
Один, когдаmasterсервер сslaveКогда сервер подключен нормально,masterСервер отправит поток команд данных наslaveСервер реплицирует изменения своих собственных данных наslaveсервер.
Во-вторых, по разным причинамmasterсервер сslaveПосле отключения сервераslaveСервер переподключаетсяmasteСервер r попытается повторно получить несинхронизированные данные после отключения, то есть частичной синхронизации или частичной репликации.
3. Если частичная синхронизация (например, начальная синхронизация) невозможна, будет запрошена полная синхронизация.masterСервер будетrdbфайл отправлен наslaveСервер синхронизирует данные, записывает другие записи во время синхронизации и отправляет их вslaveСервер, для достижения цели полной синхронизации этот метод называется полной репликацией.
Принцип работы
masterСервер запишетreplicationIdПсевдослучайная строка, используемая для идентификации текущей версии набора данных, а также для записи смещения текущего набора данных.offset,несмотря наmasterЕсть ли конфигурацияslaveСервер, идентификатор репликации и смещение всегда будут записываться и существовать парами, мы можем просмотреть идентификатор репликации и смещение с помощью следующей команды:
> info repliaction
Выполнение этой команды на главном или подчиненном сервере через redis-cli распечатает информацию, подобную следующей (разные серверы имеют разные данные и разную информацию для печати):
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1
master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee
master_repl_offset:9472
Когда ведущий и ведомый подключены нормально, ведомый использует команду PSYNC для отправки идентификатора репликации и смещения старого мастера, записанного им самим, ведущему, а ведущий вычисляет смещение данных с ведомым и синхронизирует количество смещений. в буфере.Для ведомого устройства данные ведущего и ведомого в это время непротиворечивы.
Если репликация, на которую ссылается ведомое устройство, слишком старая, а разница данных между ведущим и ведомым слишком велика, ведущее и ведомое устройства будут использовать полную репликацию для синхронизации данных.
Настройка репликации master-slave
RedisКонфигурация master-slave очень проста, мы можем использовать два способа настройки сервера master-slave, на этот раз мы сначала предполагаемRedisизmasterАдрес сервера192.168.0.101.
Клиент отправляет команду синхронизации
# 向客户端
saveof 192.168.1.101 6379
Подчиненный сервер настраивает главный сервер
это здесьslaveсервераredis.confпройти черезsaveofпараметры, вы можете указатьmasterсервер следующим образом:
slaveof 192.168.1.101 6379
Благодаря конфигурации двух вышеуказанных методов,masterсервер сslaveСервер готов начать синхронизацию данных.
Мастер требует проверки
Вышеупомянутая конфигурация заключается в том, что главный сервер не имеет установленного пароля.Если главный сервер установил пароль, вы можете подключиться кslave服务器изredis-cliВыполните следующую команду:
# <password>指代实际的密码
config set masterauth <password>
Или настройте следующие параметры в redis.conf подчиненного сервера:
# <password>指代实际的密码
masterauth <password>
Избегайте опорожнения ведомого
раб будет опорожнен? Разве ведомому не нужно синхронизировать данные ведущего? Как можно очистить данные резервной копии?
Когда главный сервер отключает сохраняемость, если он перезапускается автоматически после сбоя, постоянные данные не сохраняются локально, перезапущенные данные памяти Redis пусты, и подчиненный сервер автоматически синхронизирует данные главного сервера.В это время данные подчиненного сервера также будет очищен.
Как избежать опустошения ведомого?
Если позволяют условия (как правило, это возможно), на главном сервере по-прежнему необходимо включить сохраняемость, чтобы при сбое и перезапуске главного устройства данные можно было быстро восстановить, а подчиненные данные синхронизированного главного устройства не были очищены.
Если главный сервер не может включить постоянство, его не следует настраивать на перезапуск главного сервера после сбоя (некоторые машины будут настроены на автоматический перезапуск), а следует обновить подчиненный сервер до главного сервера и продолжать предоставлять услуги внешнему миру.
подчиненный по умолчанию доступен только для чтения
существуетRedis2.6после,slaveРежим только для чтения включен по умолчанию, мы можем передать файл конфигурацииslave-read-onlyПараметр настраивает, следует ли включить режим только для чтения:
# 默认是yes
slave-read-only yes/no
или в клиенте черезconfig setКоманда устанавливает, следует ли включить режим только для чтения:
config set slave-read-only no
Ведомый сервер настроен выше как доступный для записи, но следует отметить, что если ведомый также сконфигурирован со своим собственным ведомым сервером (подчиненный), то подчиненный ведомый будет синхронизировать только данные, синхронизированные с главного сервера, на slave, и будет синхронизировать данные, записанные непосредственно на подчиненный сервер.
Проблема с истечением срока действия ключа при репликации master-slave
мы все знаемRedisможет быть установленkeyсрок годности до ограниченияkeyВ Redis есть два механизма: отложенное удаление и периодическое удаление при истечении срока действия ключа.После настройки репликации master-slave подчиненный сервер не имеет разрешения на обработку ключей с истекшим сроком действия.key, в этом случае для ключа с истекшим сроком действия на мастере он может быть прочитан на подчиненном сервере, поэтому мастер будет накапливать ключ с истекшим сроком действия, после накопления определенной суммы отправить команду del подчиненному устройству для удаления ключа на раб.
еслиslaveОбновление сервера доmasterсервер, он начнет вычислять самостоятельноkeyвремя истечения без прохожденияmasterпомощь сервера.
Роль репликации master-slave
Сохранить копию данных Redis
когда мы просто проходимRDBилиAOFПучокRedisВ конце концов, сохранение данных в памяти является только локальным и не может гарантировать абсолютную безопасность.slaveНа сервере вы можете сохранить еще одну резервную копию данных, чтобы лучше обеспечить безопасность данных.
разделение чтения-записи
После настройки репликации master-slave, еслиmasterНагрузка сервера на чтение и запись слишком высока, и чтение и запись могут быть разделены.masterСервер записывает данные, а при чтении данных обращаетсяslaveсервера, тем самым уменьшаяmasterДавление доступа к серверу.
Высокая доступность и отказоустойчивость
Высокая доступность сервера означает, что сервер может обеспечить бесперебойную работу в течение 7*24 часов.Redisв состоянии пройтиSentinelСистема управляет несколькимиRedisсервер, когдаmasterКогда сервер выходит из строя,SentinealПо определенным правилам система будетslaveОбновление сервера доmasterСервер продолжает предоставлять услуги, реализует отработку отказа и обеспечивает бесперебойную работу служб Redis.
резюме
RedisРепликация master-slave позволяет нам поместитьRedisДанные на сервере синхронизируются с другими серверами, что обеспечивает более надежную гарантию безопасности данных, а также позволяет нашему серверу быстрее переключаться между серверами и продолжать предоставлять внешние услуги в случае сбоя и невозможности перезапуска.
Ваше внимание — самое большое поощрение на моем писательском пути!