Redis — это хранилище данных типа ключ - значение в памяти, известное своей гибкостью, производительностью, широким набором поддерживаемых языков и встроенными функциями, включая репликацию. Репликация — это практика регулярного копирования данных из одной базы в другую для создания копии, которая всегда остается точным дубликатом основной версии. Одним из стандартных вариантов использования репликации в Redis является миграция существующего хранилища данных на новый сервер в случае масштабирования инфраструктуры для повышения производительности.
В этом обучающем руководстве описан процесс использования встроенных в Redis функций репликации для миграции данных с одного сервера Ubuntu 18.04 («источник») на другой («цель»). Этот процесс подразумевает внесение нескольких изменений в конфигурацию для каждого сервера, настройку целевого сервера для работы в виде копии источника, а затем возврат копии к начальному серверу после завершения миграции.
Для данного обучающего руководства вам потребуется следующее:
ufw
. Для настройки этого окружения необходимо следовать указаниям обучающего руководства по начальной настройке сервера Ubuntu 18.04 для обоих серверов.Этот опциональный шаг подразумевает загрузку в ваш экземпляр источника Redis примера данных, чтобы вы могли поэкспериментировать с миграцией данных в целевой экземпляр. Если у вас уже есть данные, которые вы хотите переместить, перейдите к шагу 2, в котором описан процесс создания резервной копии.
Для начала подключитесь к серверу Ubuntu, который вы будете использовать в качестве экземпляр источника Redis, работая с вашим пользователем без прав root: Для начала подключитесь к серверу Ubuntu, который вы будете использовать в качестве исходного экземпляра Redis, который используется на вашем компьютере без прав root:
- ssh sammy@source_server_ip
Затем выполните следующую команду для доступа к вашему серверу Redis: Затем выполните следующую команду для доступа к вашему серверу Redis:
- redis-cli
Если вы настроили для вашего сервера аутентификацию по паролю, запустите команду auth
, за которой следует ваш пароль Redis:
- auth source_redis_password
Далее запустите следующие команды. В результате будет создан ряд ключей, содержащих несколько строк, хэш, список и набор:
- mset string1 "Redis" string2 "is" string3 "fun!"
- hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
- rpush list1 "Redis" "is" "feature-rich!"
- sadd set1 "Redis" "is" "free!"
Кроме того, запустите следующие команды expire
, чтобы предоставить несколько из этих ключей с задержкой. В результате они станут волатильными, то есть Redis будет удалять их по истечении указанного времени (в данном случае 7500
секунд).
- expire string2 7500
- expire hash1 7500
- expire set1 7500
Теперь у нас есть несколько примеров данных, которые мы можем экспортировать в целевой экземпляр Redis. Оставьте запрос redis-cli
открытым на время, пока мы будем запускать несколько команд из него на следующем шаге, чтобы создать резервную копию этих данных.
Каждый раз, когда вы планируете перенести данные с одного сервера на другой, существует риск того, что что-то может пойти не так, а вы в результате потеряете данные. Хотя этот риск невелик, мы будем использовать команду Redis bgsave
для создания резервной копии вашей базы данных источника Redis на случай возникновения ошибки в процессе репликации.
Откройте интерфейс командной строки Redis, если вы этого еще не сделали:
- redis-cli
Если вы настроили для вашего сервера аутентификацию по паролю, запустите команду auth
, за которой следует ваш пароль Redis:
- auth password
Далее запустите команду bgsave
. В результате будет создан снимок текущего набора данных, после чего этот снимок будет экспортирован в файл дампа, хранящийся в рабочем каталоге Redis:
- bgsave
Примечание: вы можете сделать снимок вашей базы данных Redis с помощью команд save
или bgsave
. Мы используем команду bgsave
, так как команда save
запускается синхронно, а значит будет блокировать действия других клиентов, подключенных к базе данных. По этой причине документация команды save
рекомендует не запускать ее в производственной среде практически ни при каких условиях.
Вместо этого предлагается использовать команду bgsave
, которая запускается асинхронно. Это приведет к тому, что Redis будет делить работу с базой данных на два процесса: родительский процесс будет продолжать обслуживать клиентов, а дочерний процесс сохранит эту базу перед выходом:
Обратите внимание, что если клиенты добавляют или изменяют данные во время работы команды bgsave
, эти изменения не отражаются в нашем снимке.
После этого вы можете закрыть подключение к вашему экземпляру Redis, запустив команду exit
:
- exit
Если вам потребуется эти данные в будущем, вы сможете найти их в файле дампа данных в рабочем каталоге вашего экземпляра Redis. Вспомните, как согласно предварительным требованиям по установке Redis вы настроили использование /var/lib/redis
в качестве рабочего каталога.
Выведите список содержимого рабочего каталога Redis, чтобы подтвердить, что в нем содержится файл дампа данных:
- sudo ls /var/lib/redis
Если дамп файл был экспортирован корректно, вы увидите его в выводе этой команды. По умолчанию этот файл имеет имя dump.rdb
:
Outputdump.rdb
После подтверждения корректного резервного копирования данных следует настроить сервер источника Redis для приема внешних подключений и возможности выполнения репликации.
По умолчанию Redis не настроен на прослушивание внешних подключений, то есть любые настроенные вами реплики не смогут синхронизироваться с вашим экземпляром источника, пока вы не обновите конфигурацию. Сейчас мы обновим файл конфигурации экземпляра источника, чтобы разрешить внешние подключения, а также установим пароль, который будет использоваться целевым экземпляром для аутентификации после запуска репликации. Затем мы добавим правило для брандмауэра, чтобы разрешить подключение к порту, на котором запущен Redis.
Откройте файл конфигурации экземпляра источника Redis в предпочитаемом вами текстовом редакторе. Мы будем использовать nano
:
- sudo nano /etc/redis/redis.conf
Перейдите в строку, которая начинается с директивы bind
. По умолчанию она будет выглядеть следующим образом:
. . .
bind 127.0.0.1
. . .
Эта директива привязывает Redis к 127.0.0.1
, кольцевому IPv4-адресу, представляющему localhost
. Это означает, что этот экземпляр Redis настроен только для прослушивания подключений, поступающих с того же сервера, где он установлен. Чтобы разрешить вашему экземпляру принимать любое подключение, которое поступает на его публичный IP-адрес, например, подключение из целевого экземпляра, добавьте IP-адрес сервера вашего источника Redis после 127.0.0.1
. Обратите внимание, что вам не нужно добавлять запятые после 127.0.0.1
:
. . .
bind 127.0.0.1 source_server_IP
. . .
Далее, если вы еще не сделали этого, воспользуйтесь директивой requirepass
для настройки пароля, который должен вводить пользователь, прежде чем он сможет взаимодействовать с данными экземпляра источника. Разкомментируйте директиву и установите сложный пароль или фразу-пароль:
. . .
requirepass source_redis_password
. . .
Обязательно запишите пароль, потому что он потребуется вам при настройке целевого сервера.
После этого вы можете сохранить и закрыть файл конфигурации Redis. Если вы использовали nano
, нажмите CTRL+X
, Y
, затем ENTER
.
Затем перезапустите службу Redis, чтобы эти изменения вступили в силу:
- sudo systemctl restart redis
Это все, что вам требуется сделать для настройки Redis, но если вы настроили брандмауэр на вашем сервере, он будет продолжать блокировать любые попытки подключения вашего целевого сервера к источнику. Если вы настроили брандмауэр с помощью ufw
, вы можете обновить его, чтобы разрешить подключение к порту, на котором запущен Redis с помощью следующей команды. Обратите внимание, что Redis настроен для использования порта 6379
по умолчанию:
- sudo ufw allow 6379
После внесения этого последнего изменения настройку вашего сервера источника Redis можно считать выполненной. Теперь вы можете перейти к настройке целевого экземпляра Redis, который будет использоваться в качестве копии источника.
К этому вы настроили экземпляр источника Redis для принятия внешних подключений. Однако, поскольку вы закрыли доступ к источнику, разкомментировав директиву requirepass
, ваш целевой экземпляр не сможет копировать данные, хранящиеся в источнике. Теперь вы должны настроить целевой экземпляр Redis, чтобы он мог выполнять аутентификацию при подключении к источнику для осуществления репликации.
Начнем с подключения к серверу цели Redis с помощью вашего пользователя без прав root:
- ssh sammy@target_server_ip
Затем откройте файл конфигурации Redis вашего целевого сервера:
- sudo nano /etc/redis/redis.conf
Если вы еще не сделали этого, вам нужно настроить пароль для экземпляра цели Redis с помощью директивы requirepass
:
. . .
requirepass target_redis_password
. . .
Затем разкомментируйте директиву masterauth
и настройте для нее пароль аутентификации экземпляра источника Redis. С помощью этого ваш целевой сервер сможет выполнять аутентификацию в экземпляре источника после обеспечения возможности репликации.
. . .
masterauth source_redis_password
. . .
Наконец, если у вас есть клиенты, осуществляющие запись в экземпляр источника, вы можете настроить для них запись также и в целевой экземпляр. Таким образом, если клиент записывает данные после того, как вы перевели цель на позицию основного источника, они не будут потеряны.
Для этого вам потребуется изменить директиву replica-read-only
. По умолчанию для нее установлено значение yes
, что означает, что она настроена для создания копии “только для чтения”, в которую клиенты не смогут добавлять данные. Установите для этой директивы значение no
, чтобы у клиентов появилась возможность записывать данные:
. . .
replica-read-only no
. . .
Это все изменения, которые вам нужно внести в файл конфигурации цели, поэтому вы можете сохранить и закрыть его.
Затем перезапустите службу Redis, чтобы эти изменения вступили в силу:
- sudo systemctl restart redis
После перезагрузки службы Redis ваш целевой сервер будет готов к тому, чтобы стать копией источника. Чтобы сделать это, вам нужно будет запустить всего одну команду, что мы сделаем в ближайшее время.
Примечание: если у вас есть какие-либо клиенты, записывающие данные в экземпляр источника Redis, сейчас лучший момент, чтобы настроить для них запись и в ваш целевой экземпляр.
К этому моменту вы настроили для экземпляра источника Redis возможность подключения с целевого сервера, а также настроили для целевого экземпляра Redis аутентификацию в источнике в виде копии. После выполнения этих действий вы можете превратить ваш целевой экземпляр в копию источника.
Начнем с открытия интерфейса командной строки Redis на целевом сервере Redis:
- redis-cli
Запустите команду auth
для аутентификации подключения:
- auth password
Затем превратите целевой экземпляр в копию источника с помощью команды replicaof
. Обязательно замените source_server_ip
на публичный IP-адрес вашего экземпляра источника, а source_port
на порт, используемый Redis в вашем экземпляре источника:
- replicaof source_server_ip source_port
Из запроса запустите следующую команду scan
. Она возвращает все ключи, которые хранятся в копии:
- scan 0
Если репликация работает ожидаемым образом, вы увидите все ключи из экземпляра источника, хранящиеся в копии. Если вы загрузили в источник данные из примера в шаге 1, вывод команды scan
будет выглядеть примерно следующим образом:
Output1) "0"
2) 1) "string3"
2) "string1"
3) "set1"
4) "string2"
5) "hash1"
6) "list1"
Примечание: необходимо помнить, что эта команда может возвращать ключи в другом порядке, отличном от представленного в примере.
Однако, если эта команда не возвращает те же ключи, которые хранятся в экземпляре источника Redis, в одном из файлов конфигурации вашего сервера может быть ошибка, которая не дает целевой базе данных подключиться к источнику. В этом случае закройте подключение к целевому экземпляру Redis и еще раз проверьте, что вы внесли изменения в файлы конфигурации на вашем сервере источника и цели Redis корректно.
Пока ваше подключение открыто, вы можете также подтвердить, что ключи, для которых вы задали истекший срок действия, остаются волатильными. Чтобы сделать это, запустив команду ttl
с одним из этих ключей в качестве аргумента:
- ttl hash1
Она возвращает количество секунд до того, как ключ будет удален:
Output5430
Убедившись, что данные в вашем экземпляре источника были корректно синхронизированы с целью, вы можете сделать цель основным экземпляром, запустив команду replicaof
еще раз. На этот раз вместо того, чтобы добавлять к replicaof
IP-адрес и порт, добавьте no one
. Это приведет к тому, что целевой экземпляр остановит синхронизацию с источником немедленно:
- replicaof no one
Чтобы подтвердить, что данные, скопированные из источника, сохраняются в цели, перезапустите команду scan
, которую вы запускали ранее:
scan 0
Вы должны увидеть те же самые ключи в выводе этой команде, которые вы видели после запуска scan
, когда цель выполняла репликацию источника:
Output1) "0"
2) 1) "string3"
2) "string1"
3) "set1"
4) "string2"
5) "hash1"
6) "list1"
Вы успешно выполнили миграцию всех данных из экземпляра источника Redis в целевой экземпляр. Если у вас есть какие-либо клиенты, которые до сих пор записывают данные в экземпляр источника, сейчас оптимальное время, чтобы настроить для них запись только в целевой экземпляр.
Помимо репликации, существует несколько методов миграции данных из одного экземпляра Redis в другой экземпляр, но репликация обладает преимуществами, требуя относительно небольшого числа изменений конфигурации, а также только одной команды для запуска или остановки.
Если вы хотите узнать больше о работе с Redis, мы рекомендуем ознакомиться с серией Управление базой данных Redis. Также, если вы хотите переместить ваши данные Redis в экземпляр Redis, управляемый DigitalOcean, воспользуйтесь указаниями нашего руководства.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.